clemensandClaude Sonnet 5
92e124753f
csvupload.php verarbeitete CSV-Zeilen bisher sofort beim Upload, ohne Vorschau, ohne Zugriffskontrolle (nur CSRF) und schrieb ausschliesslich in die global unscoped kl_Einzahlungen-Tabelle. - Neue Tabellen payment_import_batches/payment_import_rows protokollieren jeden Import: Datei, Pruefsumme, jede Zeile mit Rohwerten, erkanntem Mitglied, Status und erzeugter Ledger-Zeile. - Zweistufiger Ablauf: Hochladen zeigt nur eine Vorschau (matched/ duplicate/unmatched/invalid), erst "Import bestaetigen" bucht. - Zuordnung per paypal_name oder display_name (tenant-scoped), Dubletten- pruefung gegen bestehende nicht-stornierte Ledger-Zahlungen. - Buchung folgt dem etablierten Zweig-Muster: Default-Mandant per Dual-Write nach kl_Einzahlungen plus Spiegelung, alle anderen Mandanten direkt ueber ledger_record_payment(). - Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback). - Live getestet: Treffer, unbekannter Name, ungueltiger Betrag korrekt klassifiziert; Import bestaetigt mit korrektem Dual-Write; erneuter Upload derselben Datei erkennt die Zeile korrekt als Dublette. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
# M6 Import, Export und Mail
|
||
|
||
Stand: 2026-07-15
|
||
|
||
M6 macht die Admin-/Treasurer-Flows produktionsreif: CSV-Import,
|
||
PDF-/Listenexport, Mailversand und Jahresprozesse laufen tenant-sicher
|
||
gegen das neue Modell statt gegen Legacy-Tabellen direkt.
|
||
|
||
## CSV-Import
|
||
|
||
Umgesetzte Dateien:
|
||
|
||
```text
|
||
database/migrations/0008_saas_payment_imports.sql
|
||
app/imports.php
|
||
csvupload.php
|
||
```
|
||
|
||
Ziel: Zahlungsimport mit echter Vorschau, Dublettenprüfung und Audit-Trail,
|
||
statt sofortiger Verarbeitung ohne Bestätigungsschritt wie im Legacy-Stand.
|
||
|
||
Umfang:
|
||
|
||
- Neue Tabellen `payment_import_batches` und `payment_import_rows` (siehe
|
||
Kernschema im Umstrukturierungsplan) protokollieren jeden Import: Datei,
|
||
Prüfsumme, Zeitpunkt, jede einzelne Zeile mit Rohwerten, erkanntem
|
||
Mitglied, Status und – nach Bestätigung – der erzeugten Ledger-Zeile.
|
||
- Zweistufiger Ablauf: Hochladen erzeugt eine Vorschau (`status = previewed`)
|
||
ohne jede Buchung; erst der zweite Schritt „Import bestätigen“ committet
|
||
die als `matched` erkannten Zeilen (`status = committed`).
|
||
- Zeilen werden klassifiziert: `matched` (wird gebucht), `duplicate`
|
||
(gleicher Teilnehmer, gleicher Betrag, gleicher Tag existiert bereits als
|
||
nicht-stornierte Ledger-Zahlung), `unmatched` (kein Mitglied per
|
||
`paypal_name` oder `display_name` gefunden), `invalid` (Betrag oder Datum
|
||
nicht parsebar).
|
||
- Zuordnungsregel entspricht der Legacy-Logik: Name aus der CSV wird gegen
|
||
`paypal_name` oder `display_name` verglichen (case-insensitiv).
|
||
- Buchung folgt demselben Zweig-Muster wie die übrige Sammelerfassung: Für
|
||
Teilnehmer mit `legacy_mitarbeiter_id` (Default-Mandant) wird zusätzlich
|
||
eine `kl_Einzahlungen`-Zeile geschrieben und gespiegelt; alle anderen
|
||
Mandanten werden direkt über `ledger_record_payment()` gebucht.
|
||
- Zugriffskontrolle ergänzt: Die Seite hatte zuvor gar keine Prüfung außer
|
||
CSRF. Jetzt gilt dieselbe Rollen-/Legacy-Fallback-Logik wie bei
|
||
`einzahlung.php` (`owner`, `admin`, `treasurer`).
|
||
- Upload-Härtung aus M2 (Größen-/Typprüfung, Speicherung außerhalb des
|
||
direkt erreichbaren Codes unter `var/uploads`, Löschung nach Verarbeitung)
|
||
bleibt erhalten.
|
||
|
||
Live gegen die Dev-Datenbank getestet: Upload mit drei Testzeilen (Treffer,
|
||
unbekannter Name, ungültiger Betrag), Vorschau-Klassifizierung geprüft,
|
||
Import bestätigt (Dual-Write und Ledger-Spiegelung korrekt), erneuter Upload
|
||
derselben Datei erkennt die bereits importierte Zeile korrekt als Dublette.
|
||
Testdaten anschließend entfernt.
|
||
|
||
## Prüfstatus
|
||
|
||
- Golden Master: grün mit 104 Assertions.
|
||
- M4 Ledger-Migration: grün mit 73 Assertions.
|
||
- M4 Ledger-Service: grün mit 115 Assertions.
|
||
- HTTP-Smoke: grün mit 23 geprüften Seiten.
|