From a4de7030e0e82002c1d67807a38eb765f73f39b8 Mon Sep 17 00:00:00 2001 From: Clemens Creutzburg Date: Mon, 30 Mar 2026 08:45:17 +0200 Subject: [PATCH] Planung der neuen Anwendung --- .gitignore | 1 + docs/legacy-feature-catalog.md | 303 ++++++++++++++++++++++ docs/legacy-implementation-roadmap.md | 360 ++++++++++++++++++++++++++ 3 files changed, 664 insertions(+) create mode 100644 .gitignore create mode 100644 docs/legacy-feature-catalog.md create mode 100644 docs/legacy-implementation-roadmap.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..58c25a8 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.vscode/sftp.json diff --git a/docs/legacy-feature-catalog.md b/docs/legacy-feature-catalog.md new file mode 100644 index 0000000..326ab49 --- /dev/null +++ b/docs/legacy-feature-catalog.md @@ -0,0 +1,303 @@ +# Legacy Funktionskatalog Fuer Projektplanung + +Diese Datei bereitet den Funktionsumfang unter `legacy-app/` so auf, dass er +als Grundlage fuer Projektplanung, Scope-Entscheidungen und spaetere +Umsetzungspakete genutzt werden kann. + +## Verwendung + +- Nutze die Checklisten als fachliches Inventar. +- Ergaenze neue Punkte direkt unter `Manuelle Ergaenzungen`. +- Markiere unter `Ziel fuer SaaS` spaeter, was uebernommen, veraendert oder + verworfen werden soll. +- Die Inhalte stammen aus einer Codeanalyse der Legacy-Seiten und muessen bei + Bedarf um fachliche Regeln aus FAQ, E-Mails und Betriebswissen ergaenzt + werden. + +## Empfohlene Planungsmodule + +| Modul | Legacy-Quellen | Kernziel | +| --- | --- | --- | +| Benutzerkonto und Dashboard | `legacy-app/index.php`, `legacy-app/namenanpassen.php` | Persoenliche Uebersicht, Self-Service, Profilpflege | +| Ledger und Zahlungen | `legacy-app/index.php`, `legacy-app/stricheintragen.php`, `legacy-app/einzahlung.php`, `legacy-app/letzteneintraege.php` | Striche, Einzahlungen, Saldo, Korrekturen | +| Mitglieder und Rechte | `legacy-app/mitarbeiterverwalten.php`, `legacy-app/functions.php`, `legacy-app/functionsLDAP.php` | Benutzerverwaltung, Rollen, Zugang | +| Reporting und Export | `legacy-app/kaffeeliste.php`, `legacy-app/teilnehmerauswertung.php`, `legacy-app/exportKaffeeliste.php` | Gesamtlisten, Detailauswertungen, PDF | +| Kommunikation | `legacy-app/hinweise.php`, `legacy-app/mailversenden.php`, `legacy-app/mailausgebe.php`, `legacy-app/faq.php`, `legacy-app/jahresauswertung.php` | Hinweise, Serienmails, Sonderkommunikation | +| Importe und Sonderprozesse | `legacy-app/csvupload.php`, `legacy-app/jahresauswertung.php` | CSV-Abgleich, Jahresabschlusslogik | +| Feedback und Surveys | `legacy-app/umfrage.php`, `legacy-app/umfrageergebnisse.php` | Umfragen, Ergebnisdarstellung | + +## Funktionsbereiche + +### 1. Benutzer-Self-Service + +Legacy-Quellen: +- `legacy-app/index.php` +- `legacy-app/namenanpassen.php` +- `legacy-app/faq.php` + +Funktionen: +- [X] Persoenliches Dashboard mit aktuellem Stand +- [X] Jahresuebersicht fuer Ausgaben, Striche und Einzahlungen +- [X] Anzeige letzter Einzahlungen +- [X] Anzeige letzter Striche +- [X] Self-Service-Stricheintrag fuer 1 oder 2 Striche, wenn freigeschaltet +- [X] Direkte PayPal-Links fuer feste Betraege und offenen Saldo +- [X] Eigene Namensanpassung +- [X] FAQ und Regelwerk fuer Nutzer + +Risiken und Hinweise: +- Self-Service-Stricherfassung ist fachlich eng mit `kl_config.strichperweb` + verbunden. +- Die Zahlungslogik ist kein echter Payment-Workflow, sondern Linksteuerung. +- Teile der fachlichen Regeln liegen nur in Fliesstexten. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [ ] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- +- + +### 2. Operative Buchung und Kassenfuehrung + +Legacy-Quellen: +- `legacy-app/stricheintragen.php` +- `legacy-app/einzahlung.php` +- `legacy-app/letzteneintraege.php` +- `legacy-app/csvupload.php` + +Funktionen: +- [X] Sammelerfassung von Strichen fuer viele Mitarbeitende +- [X] Sammelerfassung von Einzahlungen fuer viele Mitarbeitende +- [X] Filterlogik fuer Vorderseite, Rueckseite oder alle Mitarbeitenden +- [X] Anpassbarer Kosten-pro-Strich-Wert beim Eintragen +- [X] Loeschung letzter Einzahlungsbuchungen +- [X] Loeschung letzter Strichbuchungen +- [X] CSV-Upload fuer externe Einzahlungseingaenge +- [X] Dublettenpruefung beim CSV-Import +- [X] Namensabgleich ueber Name oder `paypalname` +- [X] Import-Auswertung pro Datensatz + +Risiken und Hinweise: +- `legacy-app/stricheintragen.php` hat keine sichtbare Admin-Pruefung im Code. +- `legacy-app/einzahlung.php` hat ebenfalls keine sichtbare Admin-Pruefung im + Code. +- In `legacy-app/einzahlung.php` wirkt die Filterlogik inkonsistent, weil + `action` und `aktion` gemischt werden. +- Korrekturen erfolgen per Loeschung statt per Audit- oder Stornologik. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [ ] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- +- + +### 3. Uebersichten, Reporting und Export + +Legacy-Quellen: +- `legacy-app/kaffeeliste.php` +- `legacy-app/teilnehmerauswertung.php` +- `legacy-app/exportKaffeeliste.php` + +Funktionen: +- [X] Gesamtuebersicht aller aktiven Mitarbeitenden +- [X] Anzeige von Saldo, Gesamtausgabe, Gesamtstrichen, Gesamteinzahlungen +- [X] Drilldown auf Teilnehmendendetails +- [X] Detailansicht mit Jahreswerten und Transaktionshistorie +- [X] PDF-Export der Kaffeeliste +- [X] Vorderseiten-/Rueckseitenlogik fuer Druckprozess +- [ ] Wasserzeichen und farbliche Markierungen im Export +- [X] PayPal-Aktionslinks in der Teilnehmerdetailansicht + +Risiken und Hinweise: +- Die Reportinglogik ist mehrfach dupliziert. +- `legacy-app/exportKaffeeliste.php` hat keine sichtbare Zugriffspruefung. +- Fachliche Schwellenwerte sind fest im Code hinterlegt. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [X] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- +- + +### 4. Mitglieder, Rollen und Berechtigungen + +Legacy-Quellen: +- `legacy-app/mitarbeiterverwalten.php` +- `legacy-app/functions.php` +- `legacy-app/functionsLDAP.php` +- `legacy-app/config.php` + +Funktionen: +- [X] Mitglied anlegen +- [X] Mitglied bearbeiten +- [X] Mitglied aktivieren oder deaktivieren +- [X] Admin-Flag setzen oder entfernen +- [X] Zugriff fuer aktive Nutzer pruefen +- [X] Zugriff fuer Admins pruefen +- [ ] Benutzer ueber Windows-Login und LDAP-Merkmale identifizieren +- [ ] Verknuepfung zwischen technischer Identitaet und `kl_Mitarbeiter` + +Risiken und Hinweise: +- Keine sichtbare Dublettenpruefung fuer Benutzerstammdaten. +- Rollenmodell ist sehr knapp: aktiv oder admin. +- Authentifizierung und Autorisierung sind technisch eng vermischt. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [ ] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- die Authentifizierung an einem AD und ADFS sollen hinzugefügt werden. +- + +### 5. Kommunikation, Hinweise und Benachrichtigungen + +Legacy-Quellen: +- `legacy-app/hinweise.php` +- `legacy-app/header.php` +- `legacy-app/mailversenden.php` +- `legacy-app/mailausgebe.php` +- `legacy-app/faq.php` +- `legacy-app/jahresauswertung.php` + +Funktionen: +- [X] Globale Hinweisbanner mit Gueltigkeitsdatum +- [X] Adminpflege fuer Hinweise +- [X] Serienmail mit individuellem Kontostand +- [X] Unterschiedliche Mailtexte fuer Guthaben und Schulden +- [X] Ausgabe einer Mailadressliste +- [X] FAQ als Hilfe- und Regelwerk +- [X] Sondermailing im Jahresabschlussprozess + +Risiken und Hinweise: +- `legacy-app/mailversenden.php` startet beim Aufruf sofort den Versand. +- `legacy-app/mailversenden.php` hat keine sichtbare Admin-Pruefung. +- `legacy-app/mailausgebe.php` ist fachlich und datenschutzseitig zu pruefen. +- Hinweise koennen angelegt und geloescht, aber nicht bearbeitet werden. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [ ] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- Es solle die möglichkeit geben auch Anfragen von dem Benutzern an den Verantwortlichen der Kaffeeliste des jeweiligen Kunden zusenden. +- Es soll die möglichkeit geben das der Verwortliche der Kaffeeliste auch Anfragen an die zentrale Administration stellen kann. + +### 6. Feedback und Umfragen + +Legacy-Quellen: +- `legacy-app/umfrage.php` +- `legacy-app/umfrageergebnisse.php` + +Funktionen: +- [X] Einmalige Umfrageteilnahme pro normalisierter E-Mail +- [X] Ratings, Mehrfachauswahl und Freitextantworten +- [X] Validierung unvollstaendiger Eingaben +- [X] Speicherung strukturierter Antworten +- [X] Ergebnisdarstellung mit Durchschnittswerten und Haeufigkeiten +- [X] Anzeige letzter Freitextantworten + +Risiken und Hinweise: +- Die Umfrage ist aktuell per Flag deaktiviert. +- Fragebogen und Antwortoptionen sind fest im Code definiert. +- Ergebniszugriff ist nicht klar auf Admins begrenzt. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [X] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- Es soll möglich sein, das die Verantwortlichen der Kaffeeliste Umfrage einrichten können. Die Verantwortlichen der Kaffeeliste sollten die Umfrange vollumfänglich verwalten und auswerten können. +- + +### 7. Sonderprozesse und Jahresabschluss + +Legacy-Quellen: +- `legacy-app/jahresauswertung.php` + +Funktionen: +- [X] Ermittlung von Jahresstrichen aller aktiven Mitglieder +- [X] Proportionale Verteilung einer festen Strichmenge +- [X] Umbuchung der daraus entstehenden Werte als Einzahlung +- [X] Versand einer Begleitmail + +Risiken und Hinweise: +- Hoher Seiteneffekt beim blossen Aufruf. +- Parameter wie Strichmenge und Preis sind hartcodiert. +- Die Datei enthaelt Sonderlogik ausserhalb des normalen App-Rahmens. + +Ziel fuer SaaS: +- [X] Uebernehmen +- [X] Vereinfachen +- [X] Neu denken +- [ ] Entfaellt + +Manuelle Ergaenzungen: +- Es sollt die möglichkeit geben eine Jahresbonus z.B. anhand der im Jahr verbrauchten Strichen zu verteilen an die Mitglieder +- + +## Seiteninventar + +| Datei | Zweck | Wichtige Funktionen | Risiko fuer Neuentwicklung | +| --- | --- | --- | --- | +| `legacy-app/index.php` | Nutzer-Dashboard | Saldo, Jahreswerte, letzte Buchungen, Self-Service-Striche, PayPal-Links | Fachlogik direkt in Seite, kaum zentralisiert | +| `legacy-app/namenanpassen.php` | Anzeigename pflegen | Eigene Namensaenderung, Admin-Auswahl anderer Nutzer | Profilmodell sehr schmal | +| `legacy-app/faq.php` | Hilfe und Regeln | FAQ, Prozesswissen, Kontaktinformationen | Geschaeftsregeln liegen nur in Textform vor | +| `legacy-app/stricheintragen.php` | Massenbuchung Striche | Front-/Rueckseitenfilter, Kosten pro Strich, Bulk-Erfassung | Sichtbar fehlender Adminschutz | +| `legacy-app/einzahlung.php` | Massenbuchung Einzahlungen | Bulk-Erfassung, letzte Eintraege, CSV-Upload-Verlinkung | Mischfehler `action` vs. `aktion`, sichtbar fehlender Adminschutz | +| `legacy-app/letzteneintraege.php` | Korrektur letzter Buchungen | Letzte 100 Einzahlungen, letzte 100 Verbraeuche, Loeschen | Keine Auditspur | +| `legacy-app/csvupload.php` | CSV-Import | Datei-Upload, Dublettenpruefung, Ergebnisreport | Implizites Dateiformat, Freitext-Matching | +| `legacy-app/kaffeeliste.php` | Gesamtuebersicht | Summenliste, Drilldown, Export, Mailstart | Reporting schwer wiederverwendbar | +| `legacy-app/teilnehmerauswertung.php` | Personendetailansicht | Jahreswerte, Historie, PayPal-Links | Doppelte Logik, teils unparametrisierte SQL | +| `legacy-app/exportKaffeeliste.php` | PDF-Ausdruck | PDF, Wasserzeichen, Farbmarkierungen, Papierlogik | Layout und Fachlogik stark vermischt | +| `legacy-app/mitarbeiterverwalten.php` | Stammdatenverwaltung | Anlegen, Bearbeiten, Aktivieren, Deaktivieren, Admin-Flag | Kaum Validierung, einfaches Rollenmodell | +| `legacy-app/hinweise.php` | Hinweisverwaltung | Hinweis anlegen, listen, loeschen | Kein Bearbeiten, Loeschen per GET | +| `legacy-app/mailversenden.php` | Serienmail | Stand berechnen und direkt versenden | Aufruf triggert sofort Versand | +| `legacy-app/mailausgebe.php` | Adressliste | Semikolon-Liste aktiver E-Mails | Datenschutz und Berechtigung pruefen | +| `legacy-app/umfrage.php` | Umfrageerfassung | Einmalige Teilnahme, Validierung, Antwortspeicherung | Fragebogen fest im Code | +| `legacy-app/umfrageergebnisse.php` | Umfrageauswertung | Aggregationen, Haeufigkeiten, Freitextlisten | Ergebniszugriff fachlich unklar | +| `legacy-app/jahresauswertung.php` | Jahresabschluss-Sonderprozess | Verteilung, Einzahlung, Mail | Sehr hoher fachlicher und technischer Sonderfall | + +## Offene Entscheidungen Fuer Die Planung + +- [X] Soll die Vorderseiten-/Rueckseitenlogik aus dem Papierprozess erhalten + bleiben? +- [X] Soll Self-Service-Stricherfassung erhalten bleiben? +- [ ] Soll die Zahlung weiter ueber reine PayPal-Links laufen? +- [X] Brauchen Loeschungen kuenftig Storno- und Audit-Logik? +- [ ] Wer darf Umfrageergebnisse sehen? +- [ ] Ist `mailausgebe.php` fachlich gewollt oder nur Hilfsfunktion? +- [ ] Ist `jahresauswertung.php` ein wiederkehrender Prozess? +- [ ] Welche Fachregeln aus FAQ und Mailtexten muessen als echte Anforderungen + uebernommen werden? +- [ ] Welche Zusatzfelder braucht das kuenftige Benutzerprofil, z. B. + `paypalname`? +- [ ] Welche Aktionen brauchen kuenftig Vorschau, Freigabe oder Testmodus? + +## Notizen + +- Die Zahlung soll der Verantwortliche der Kaffeeliste einstellen können. Bar, Überweisung und Paypal sollen auswählbar sein. Bei Paypal können die E-Mails von Paypal an ein bestimmtes Postfach gesendet werden. Dieses wird von der Seite regelmäßig aus gelesen werden. Dabei soll ein catch-all Postfach gearbeitet werden. Die Empfängeradresse legt die jeweilige Kaffeeliste fest. Der Empfänger ist der Name. +- Die Umfrageergebnisse sollten nach Freigabe des Verantwortlichen auch die Benutzer sehen können. +- mailausgabe.php ist vermutlich nur eine Hilfsfunktion. +- jahresauswertung.php soll im Rahmen der gesamtdarstellung und die Jahes sonderausschüttung benötigt wurden sein. +- die FAQ und Mailtexte müssen durch die Verantwortlichen der Kaffeeliste angepasst werden können, es soll aber eine StandardVorlage geben +- Welche Feld noch benötigt, muss ermittelt werden. +- \ No newline at end of file diff --git a/docs/legacy-implementation-roadmap.md b/docs/legacy-implementation-roadmap.md new file mode 100644 index 0000000..3340821 --- /dev/null +++ b/docs/legacy-implementation-roadmap.md @@ -0,0 +1,360 @@ +# Legacy Zu SaaS Umsetzungsfahrplan + +Diese Datei verdichtet die Review des Funktionskatalogs zu einem +umsetzungsorientierten Fahrplan. Ziel ist es, nur solche Themen parallel +anzugehen, die bereits fachlich und technisch sauber geschnitten sind. + +## Review Ergebnis + +Der Katalog in `docs/legacy-feature-catalog.md` ist als Planungsgrundlage gut, +aber noch nicht komplett implementierungsreif. Mehrere Themen sind im +`saas-app`-Geruest bereits vorbereitet, allerdings oft nur als Datenmodell oder +Demo-Service. Vor einer breiten Parallelumsetzung muessen deshalb zuerst einige +Architektur- und Fachentscheidungen festgezogen werden. + +## Harte Blocker Vor Breiter Umsetzung + +### 1. Identity-Strategie + +Offen: +- OIDC-first mit ADFS als OIDC-Provider +- oder direkter AD-/LDAP-Abgleich + +Warum blocker: +- Das aktuelle SaaS-Geruest ist OIDC-orientiert. +- Der Katalog nennt AD und ADFS, beschreibt aber die Zielarchitektur nicht + praezise genug. + +Benötigte Entscheidung: +- [X] Zielpfad fuer Anmeldung und Benutzerabgleich festlegen + +Der Verantwortliche für die jeweilige Kaffeeliste sollt auswählen könne, ob per ADFS oder LDAP Anbindung oder Azure AD Abfrage eingerichtet werden kann. + +### 2. Rollenmatrix + +Offen: +- Welche Rollen gibt es ausser `platform_admin`, `tenant_admin`, `member`? +- Braucht es z. B. `finance_admin`, `support_contact`, `survey_manager`? + +Warum blocker: +- Zahlungsfreigaben, Kommunikationswege und Survey-Rechte haengen direkt von + Rollen ab. + +Benötigte Entscheidung: +- [X] Rollenmodell und Rechte pro Rolle festlegen + +Ja es sollte Rollen und Rechte pro Rolle geben. Tenant Admin soll immer alle Recht haben + + +### 3. Zahlungsmodell + +Offen: +- Pro Tenant aktivierbare Zahlungsarten +- Bankdaten +- PayPal-Empfaenger +- Catch-all-Mailbox und Zahlungsabgleich + +Warum blocker: +- Das aktuelle `payment_entries`-Modell ist fuer einfache Buchungen gut, aber + noch nicht fuer automatischen Abgleich oder Mailbox-Importe. + +Benötigte Entscheidung: +- [Ja umsetzen] Zahlungsarten pro Tenant definieren +- [Ja umsetzen] Reconciliation-Modell definieren +- [Ja umsetzen] Mailbox-Import als eigenes Folgepaket abgrenzen + + + +### 4. Kommunikationsmodell + +Offen: +- Soll eine Anfrage nur per Mail weitergeleitet werden? +- Oder als Vorgang im System bestehen bleiben? +- Wer ist die zentrale Administration fachlich genau? + +Warum blocker: +- Aktuell existiert nur `support_email`, aber kein Vorgangs- oder Routingmodell. + +Benötigte Entscheidung: +- [Ja] Support-Request-Workflow definieren + +Die Anfragen information soll an den Verantwortlichen der Anfragen bzw. den Tenant Admin gehen. +Die Zentrale Administration ist die Verwaltung aller Tenant + +### 5. Survey-Modell + +Offen: +- Wer darf Surveys anlegen? +- Wie werden Antwortoptionen modelliert? +- Wann sind Ergebnisse fuer Benutzer sichtbar? +- Live-Ansicht oder freigegebener Snapshot? + +Warum blocker: +- Das Grundschema existiert, aber Freigabe, Multiple Choice und Auswertung sind + noch nicht ausreichend modelliert. + +Benötigte Entscheidung: +- [ ] Survey-MVP fachlich festziehen + +Ermöglich eine Standardgerüst für Umfragen. Die Umfragen sollten von der jeweiligen Rolle oder dem Tenant Administrator vollständig verwaltet werden können. + +### 6. Audit Und Storno + +Offen: +- Darf weiterhin direkt geloescht werden? +- Oder braucht es kuenftig Storno, Historie und Freigaben? + +Warum blocker: +- Legacy arbeitet vielfach mit direkter Loeschung; das ist fuer SaaS und + Nachvollziehbarkeit meist zu schwach. + +Benötigte Entscheidung: +- [X] Korrekturmodell fuer Buchungen definieren +Nein es sollte nicht gelöscht werden können es soll Storne und Historie geben. + +## Bereits Tragfaehige Grundlagen Im SaaS-Geruest + +Vorhanden: +- Mandantenmodell +- tenantbezogene Einstellungen +- OIDC-Provider- und Identity-Tabellen +- Rollen- und Tenant-User-Grundmodell +- Ledger-, Payment-, Content-, Survey-, Import- und Export-Tabellen +- Feature-Gating fuer mehrere Module + +Einordnung: +- Das Geruest ist gut genug, um fokussierte MVPs umzusetzen. +- Es ist nicht gut genug, um alle Themen parallel ohne weitere + Fachspezifikation produktiv zu bauen. + +## Empfohlene Reihenfolge Fuer Spezialistenpakete + +### Paket 1. Identity Baseline + +Ziel: +- Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen + +Scope: +- OIDC-/ADFS-Entscheid dokumentieren +- Provider-Konfiguration pro Tenant +- Benutzeridentitaeten sauber mappen + +Ergebnis: +- Eine stabile Basis fuer alle spaeteren Rollen- und Zugriffsthemen + +Status: +- [ ] Noch nicht spezifiziert +- [ ] Danach implementierbar + +### Paket 2. Rollen Und Verantwortlichkeiten + +Ziel: +- Fachrollen fuer Tenant-Betrieb sauber schneiden + +Scope: +- Plattform-Admin +- Tenant-Admin +- Mitglied +- optional Finance, Support, Survey-Manager + +Ergebnis: +- Klare Berechtigungsbasis fuer Payments, Support und Surveys + +Status: +- [ ] Noch nicht spezifiziert +- [ ] Danach implementierbar + +### Paket 3. Content MVP + +Ziel: +- Hinweise und FAQ durch Tenant-Admins pflegbar machen + +Scope: +- CRUD fuer Hinweise +- CRUD fuer FAQ +- aktiv/inaktiv +- Sortierung +- Sichtbarkeit bis Datum +- optionale Standardvorlage als Startbestand + +Ergebnis: +- Erstes direkt nutzbares Fachmodul mit bereits passendem Datenmodell + +Status: +- [X] Fachlich fast schnittreif +- [ ] Kann frueh implementiert werden + +### Paket 4. Support Requests MVP + +Ziel: +- Anfragen Benutzer -> Kaffeelistenverantwortliche +- Anfragen Verantwortliche -> zentrale Administration + +Scope: +- `support_requests` +- Richtung +- Kategorie +- Nachricht +- Absender +- Ziel +- Status +- Zeitstempel + +Ergebnis: +- Ein nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung + +Status: +- [ ] Vorher Workflow-Entscheid noetig +- [ ] Danach implementierbar + +### Paket 5. Payment Configuration MVP + +Ziel: +- Tenant-spezifische Zahlungsarten und Zahlungsdaten + +Scope: +- Bar +- Ueberweisung +- PayPal +- aktivierte Methoden +- Hinweise fuer Benutzer +- tenantbezogene Zahlungsparameter + +Ergebnis: +- Saubere Grundlage fuer spaetere Automatisierung + +Status: +- [ ] Vorher Fachmodell vervollstaendigen +- [ ] Danach implementierbar + +### Paket 6. Ledger Audit Und Korrekturen + +Ziel: +- Buchungen sicher korrigieren statt direkt loeschen + +Scope: +- Storno statt Hard Delete +- Auditfelder +- Referenzen auf Ursprungseintraege +- Begruendung oder Freigabeoption + +Ergebnis: +- Nachvollziehbares Buchungsmodell + +Status: +- [ ] Vorher Korrekturregeln definieren +- [ ] Danach implementierbar + +### Paket 7. Survey Admin MVP + +Ziel: +- Tenant-seitige Survey-Erstellung und Verwaltung + +Scope: +- Survey anlegen +- Fragen anlegen +- Aktivierungszeitraum +- Ergebnisfreigabe +- Auswertung fuer Tenant-Admins + +Ergebnis: +- Nutzbares Survey-Modul fuer den operativen Betrieb + +Status: +- [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen +- [ ] Danach implementierbar + +### Paket 8. Survey Publishing Fuer Benutzer + +Ziel: +- Benutzer duerfen freigegebene Ergebnisse sehen + +Scope: +- Freigabeflag +- Benutzeransicht +- Aggregationen +- optionale Snapshot-Logik + +Ergebnis: +- Kontrollierte Transparenz statt unklarer Sichtbarkeit + +Status: +- [ ] Abhaengig von Paket 7 + +### Paket 9. Payment Reconciliation + +Ziel: +- Zahlungen aus externen Quellen belastbar abgleichen + +Scope: +- Status +- externe Referenz +- Quelle +- Matching +- manuelle Klaerung +- Audit + +Ergebnis: +- Technische Basis fuer Import- und Mailbox-Automatisierung + +Status: +- [ ] Abhaengig von Paket 5 + +### Paket 10. Catch-All Mailbox Integration + +Ziel: +- Zahlungsbenachrichtigungen automatisiert einlesen und zuordnen + +Scope: +- Eingangskanal +- Parser +- Sicherheitsregeln +- Matching-Regeln +- Klaerungsfaelle + +Ergebnis: +- Eigenstaendige Integrationsstrecke, nicht Teil eines kleinen MVPs + +Status: +- [ ] Abhaengig von Paket 9 + +## Was Jetzt Schon Sicher Parallelisierbar Ist + +Diese Themen koennen nach kurzer Feinspezifikation gut durch getrennte +Spezialisten umgesetzt werden: + +- Content-MVP +- Rollenmatrix und Rechtekonzept +- Tenant Payment Configuration +- Support-Requests Datenmodell +- Survey-Admin-Konzept + +Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden: + +- Catch-all-Mailbox fuer PayPal +- finale Identity-Integration ohne Architekturentscheid +- Survey-Publishing fuer Benutzer ohne Freigabemodell +- Audit-/Storno-Implementierung ohne fachliche Korrekturregeln + +## Konkrete Naechste Entscheidungsliste + +- [ ] OIDC mit ADFS als Zielpfad bestaetigen oder AD-/LDAP-Abgleich bevorzugen +- [ ] Rollenmatrix festlegen +- [ ] Support Requests als Mailweiterleitung oder Vorgangssystem definieren +- [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen +- [ ] Survey-Freigabemodell fuer Benutzer festlegen +- [ ] Storno/Audit statt direkter Loeschung bestaetigen +- [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen + +## Empfehlung + +Wenn du sofort in Umsetzung gehen willst, ist die sauberste Reihenfolge: + +1. Content-MVP +2. Rollenmatrix +3. Payment Configuration MVP +4. Support Requests MVP +5. Survey Admin MVP + +Erst danach sollten wir Payment-Reconciliation, Mailbox-Import und komplexere +Identity-Integrationen parallelisieren.