# 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-, Fach- und Betriebsentscheidungen festgezogen werden.

## Zusammenfassung Fuer Die Projektsteuerung

Aktuell ist die Roadmap als Themenkarte brauchbar, aber noch nicht belastbar
fuer eine breite Parallelisierung mehrerer Entwicklungsteams.

Belastbar vorbereitet:
- Content-MVP fuer Hinweise und FAQ
- Grundlegende Payment-Konfiguration auf Tenant-Ebene
- Survey-Admin-MVP als fachliches Folgepaket

Noch nicht belastbar vorbereitet:
- Identity-Strategie und Benutzerabgleich
- Rollen- und Rechte-Matrix
- Audit-/Storno-Modell fuer Buchungen
- Support-Request-Workflow
- Nichtfunktionale Anforderungen, Test- und Abnahmekriterien

## Stand Der Bisherigen Entscheidungen

### Vorlaeufig Geklaerte Leitplanken

- Self-Service-Striche sollen erhalten bleiben und tenantweit schaltbar sein.
- Einzahlungen sollen im Zielsystem stornierbar sein; Stricheintraege sollen
  durch Verantwortliche loeschbar bleiben.
- Tenant-Admins sollen Inhalte, Zahlungsarten und Surveys verwalten koennen.
- Zahlungsarten sollen pro Tenant mindestens Bar, Ueberweisung und PayPal
  unterstuetzen.
- Survey-Ergebnisse sollen erst nach Freigabe fuer Mitglieder sichtbar werden.
- FAQ- und Kommunikationstexte sollen als Standardvorlage plus Tenant-Override
  modelliert werden.
- Supportanfragen sollen zwischen Benutzer, Tenant-Verantwortlichen und
  Plattform-Administration routebar sein.

### Noch Offene Produktentscheidungen

- Konkrete Rechte-Matrix pro Rolle und Objekt finalisieren.
- Konkrete Parameter und Freigabelogik fuer Jahresauswertungen und Boni.

## Harte Blocker Vor Breiter Umsetzung

### 1. Identity-Strategie

Status:
- [X] Zielbild festgelegt
- [ ] Detailkonzept vor Implementierung spezifizieren

Offen:
- lokale DB-Anmeldung im System
- zusaetzliche ADFS-/OIDC-Anmeldung
- E-Mail-basiertes Mapping zwischen externer Identitaet und internem Benutzer

Warum blocker:
- Das aktuelle SaaS-Geruest ist OIDC-orientiert.
- Login, Tenant-Zuordnung, Benutzerabgleich und Rollenvergabe haengen direkt an
  dieser Entscheidung.
- Das Zielbild ist festgelegt, aber das Detailkonzept fuer Fallback, Mapping und
  Erstlogin fehlt noch.

Mindestinhalt der Entscheidung:
- lokale Anmeldung immer verfuegbar
- ADFS/OIDC als einzige zusaetzliche externe Anmeldung
- Mapping zwischen externer Identitaet und internem Benutzer per E-Mail
- Regeln fuer Erstlogin, Reaktivierung und Dubletten

Empfehlung:
- Lokale Anmeldung bleibt verpflichtend verfuegbar.
- ADFS/OIDC wird als einzige zusaetzliche externe Anmeldung vorgesehen.
- Beim Erstlogin per ADFS/OIDC erfolgt das Mapping primaer ueber E-Mail.
- Bei Dubletten oder unklaren Zuordnungen wird ein Admin-Klaerfall erzeugt.

### 2. Rollenmatrix

Status:
- [~] Rollen grundsaetzlich festgelegt
- [ ] Rechte-Matrix vor Implementierung spezifizieren

Offen:
- Welche Rechte gelten pro Rolle und Objekt?

Warum blocker:
- Zahlungsfreigaben, Kommunikation, Surveys, Exporte und Korrekturen haengen
  direkt von Berechtigungen ab.
- "Tenant Admin hat alles" reicht nicht als umsetzbare Rechtebeschreibung.

Mindestinhalt der Entscheidung:
- Rollenliste mit `platform_admin`, `tenant_admin`, `finance_admin`,
  `support_contact`, `survey_manager`, `member`
- Rechte-Matrix pro Aktion und Objekt
- Tenant-Grenzen und Admin-Override
- Delegation von Spezialrollen

Empfohlene Rechte-Matrix:

| Rolle | Benutzer / Identitaet | Rollenverwaltung | Buchungen / Einzahlungen | Support | Surveys | Content / FAQ | Reporting / Export |
| --- | --- | --- | --- | --- | --- | --- | --- |
| `platform_admin` | global verwalten, Tenant-Identity einrichten | global | global | global | global | global | global |
| `tenant_admin` | tenantweit alles | tenantweit alles | anlegen, bearbeiten, Einzahlungen stornieren, Striche loeschen | Vorgaenge sehen und bearbeiten | anlegen, freigeben, auswerten | pflegen | tenantweit exportieren und auswerten |
| `finance_admin` | Benutzerdaten nur fuer Buchungskontext lesen | nein | Einzahlungen buchen und stornieren, Striche loeschen, Salden korrigieren | lesen | lesen | lesen | Finanz- und Buchungsreports exportieren |
| `support_contact` | Benutzerdaten nur im Supportkontext lesen | nein | nein | Supportvorgaenge sehen, bearbeiten, schliessen | nein | lesen | supportbezogene Auswertungen lesen |
| `survey_manager` | Benutzerdaten nur minimal lesen, falls fuer Surveys noetig | nein | nein | nein | Umfragen anlegen, freigeben, auswerten, veroeffentlichen | lesen | Survey-Reports exportieren |
| `member` | eigenes Profil lesen und pflegen, Login lokal oder via `ADFS/OIDC` | nein | eigene Eintraege sehen, Self-Service nur wenn freigeschaltet | eigene Anfragen stellen und Status sehen | teilnehmen, freigegebene Ergebnisse sehen | lesen | eigene bzw. freigegebene Auswertungen lesen |

Hinweise:
- `tenant_admin` hat im eigenen Tenant Vollzugriff.
- Spezialrollen erhalten nur die fuer ihr Modul noetigen Rechte.
- `platform_admin` darf tenantuebergreifend administrieren.
- Einzahlungen koennen nur durch Verantwortliche storniert werden.
- Stricheintraege koennen nur durch Verantwortliche geloescht werden.

### 3. Zahlungsmodell

Status:
- [~] Teilweise geklaert
- [ ] Vor Implementierung zu vervollstaendigen

Bereits geklaert:
- Zahlungsarten pro Tenant sind gewollt.
- Bar, Ueberweisung und PayPal sollen Teil des MVPs sein.
- Catch-all-Mailbox soll als eigenes Folgepaket abgegrenzt werden.
- Payment-Reconciliation ist nicht Teil des MVPs und folgt als eigenes Paket
  nach stabiler manueller Buchung.

Noch offen:
- Welche Zahlungsdaten pro Tenant gepflegt werden muessen.
- Welche Hinweise und Pflichtfelder pro Zahlungsart sichtbar sind.
- Welche manuellen Klaerfaelle vorgesehen sind.

Warum blocker:
- Das aktuelle `payment_entries`-Modell reicht fuer einfache Buchungen, aber
  nicht fuer belastbaren Abgleich, Fehlerfaelle und spaetere Automatisierung.

Empfehlung:
- Im MVP nur Konfiguration und manuelle Buchung umsetzen.
- Fuer spaetere Reconciliation bereits Statusfelder wie `neu`, `gematcht`,
  `pruefen`, `storniert` vorbereiten.
- Mailbox-Import und automatisches Matching bleiben Folgepakete.


### 4. Kommunikationsmodell

Status:
- [X] Zielbild fachlich festgelegt
- [ ] Workflow und Statusmodell vor Implementierung spezifizieren

Bereits geklaert:
- Anfragen sollen an Tenant-Verantwortliche bzw. Tenant-Admins gehen.
- Die Plattform-Administration ist die zentrale Verwaltung aller Tenants.
- Support soll direkt als vollstaendiges Vorgangssystem starten.

Noch offen:
- Status, Eskalation, Routing und Bearbeitungsregeln.
- Sichtbarkeit fuer Benutzer, Tenant-Admins und Plattform-Admins.

Warum blocker:
- Aktuell existiert nur `support_email`, aber kein belastbares Workflow- oder
  Routingmodell.

### 5. Survey-Modell

Status:
- [~] Teilweise geklaert
- [ ] Vor Implementierung zu vervollstaendigen

Bereits geklaert:
- Tenant-seitige Erstellung und Verwaltung ist gewollt.
- Mitglieder sollen Ergebnisse erst nach Freigabe sehen.
- Fuer Mitglieder werden veroeffentlichte Snapshots empfohlen, keine
  Live-Ergebnisse.

Noch offen:
- Wer Surveys genau anlegen, aktivieren und freigeben darf.
- Wie Fragetypen und Antwortoptionen modelliert werden.
- Welche Auswertungen im MVP benoetigt werden.

Warum blocker:
- Das Grundschema existiert, aber Freigabe, Multiple Choice und Auswertung sind
  noch nicht ausreichend modelliert.

Empfehlung:
- Fachseite arbeitet auf Live-Daten.
- Fuer Benutzer wird bei Freigabe ein stabiler Snapshot veroeffentlicht.
- Snapshot-Versionen muessen nachvollziehbar gespeichert werden.

### 6. Audit Und Storno

Status:
- [~] Fachliche Leitplanke geklaert
- [ ] Regelwerk vor Implementierung spezifizieren

Bereits geklaert:
- Einzahlungen sollen stornierbar sein.
- Stricheintraege sollen loeschbar sein.
- Korrekturen duerfen nur durch Verantwortliche erfolgen.

Noch offen:
- Ob Freigaben oder Begruendungen erforderlich sind.
- Wie Referenzen auf Ursprungseintraege, Auditfelder und Historie aussehen.
- Wie Importe und Jahresabschluss mit Korrekturen umgehen.

Warum blocker:
- Legacy arbeitet vielfach mit direkter Loeschung; fuer SaaS und Nachvollzieh-
  barkeit ist das zu schwach.

## Nichtfunktionale Mindestanforderungen

Diese Anforderungen muessen vor oder spaetestens waehrend Paket-Spezifikation
explizit beschrieben werden. Sie fehlen aktuell noch in den Legacy-Dokumenten.

- Datenschutz und Berechtigungskonzept fuer Kontostaende, Mailadressen,
  Exporte und Supportinhalte
- Logging und Audit fuer Massenaktionen, Exporte, Freigaben und Integrationen
- Monitoring und Fehlerbenachrichtigung fuer Importe, Mailversand und
  Hintergrundprozesse
- Backup/Restore fuer tenantkritische Stammdaten und Bewegungsdaten
- Schutzmechanismen fuer risikoreiche Aktionen: Vorschau, Testmodus,
  Vier-Augen-Freigabe, Idempotenz
- Test- und Abnahmekriterien fuer alle MVP-Pakete

Empfehlung:
- Vorschau und Testmodus sind Mindestanforderung fuer riskante Sammelaktionen
  bereits im MVP.
- Vier-Augen-Freigabe ist fuer Jahresauswertung, Massenmail, Importlaeufe und
  gebuendelte Stornoaktionen vorzusehen.
- Die Vier-Augen-Freigabe muss tenantweit konfigurierbar und deaktivierbar
  sein.

## 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 Projektphasen

### Phase 0. Architektur- und Fachentscheidungen

Ziel:
- Blocker aufloesen, damit nachfolgende Pakete sauber geschnitten sind.

Enthaelt:
- Identity-Zielbild
- Rollen- und Rechte-Matrix
- Audit-/Storno-Regeln
- Support-Workflow
- Survey-Freigabemodell
- Mindestanforderungen fuer Betrieb, Sicherheit und Tests

Ergebnis:
- Verbindliche Leitplanken fuer Umsetzung und Abnahme

### Phase 1. Basis Und Content MVP

Ziel:
- Schnell ein erstes nutzbares Modul liefern und gleichzeitig die
  Tenant-Grundlagen stabilisieren.

Enthaelt:
- Content-MVP fuer Hinweise und FAQ
- Standardvorlagen mit Tenant-Override
- erste Rollenpruefungen auf Basis der festgelegten Matrix
- `mailausgebe.php` nicht als Produktfunktion uebernehmen

Ergebnis:
- Erstes produktiv brauchbares Fachmodul mit klarer Zustands- und Rechtebasis

### Phase 2. Operatives Ledger

Ziel:
- Buchungen, Einzahlungen und Korrekturen revisionsfaehig machen.

Enthaelt:
- operative Strich- und Einzahlungserfassung
- Audit-/Storno-Modell
- Basis fuer spaetere Importe und Zahlungsabgleiche

Ergebnis:
- Nachvollziehbare Buchungslogik statt Legacy-Loeschverhalten

### Phase 3. Kommunikation Und Self-Service

Ziel:
- Nutzernahe Prozesse und Supportwege in den regulaeren App-Rahmen ueberfuehren.

Enthaelt:
- Support Requests MVP
- Self-Service-Elemente rund um Dashboard und Anfragen
- sichere Serienmail- und Kommunikationsprozesse

Ergebnis:
- Nachvollziehbarer Kommunikationsprozess statt unkontrollierter Einzeltools

### Phase 4. Surveys

Ziel:
- Tenant-faehige Survey-Erstellung, Auswertung und kontrollierte Freigabe.

Enthaelt:
- Survey Admin MVP
- Survey Publishing fuer Benutzer
- Rollen- und Sichtbarkeitsregeln

Ergebnis:
- Nutzbares Survey-Modul fuer operativen Betrieb und spaetere Erweiterungen

### Phase 5. Automatisierung Und Integrationen

Ziel:
- Auf den stabilen MVP-Modulen aufsetzen und Integrationen sicher erweitern.

Enthaelt:
- Payment Reconciliation
- Catch-all Mailbox Integration
- weitergehende Identity-Integrationen je Tenant

Ergebnis:
- Kontrollierte Automatisierung statt zu frueher Integrationskomplexitaet

## Empfohlene Reihenfolge Fuer Spezialistenpakete

### Paket 1. Identity Baseline

Ziel:
- Zielarchitektur fuer Login und Identitaetsverknuepfung festziehen

Scope:
- Zielpfad dokumentieren
- Provider-Konfiguration pro Tenant
- Benutzeridentitaeten sauber mappen
- Regeln fuer Erstlogin und Dubletten

Ergebnis:
- Stabile Basis fuer 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
- optionale Spezialrollen wie Finance, Support, Survey-Manager
- Rechte-Matrix pro Aktion und Objekt

Ergebnis:
- Klare Berechtigungsbasis fuer Payments, Support, Surveys und Exporte

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
- Standardvorlage plus Tenant-Override

Ergebnis:
- Erstes direkt nutzbares Fachmodul mit passendem Datenmodell

Status:
- [X] Fachlich fast schnittreif
- [ ] Kann frueh implementiert werden

### Paket 4. Support Requests MVP

Ziel:
- Anfragen Benutzer -> Kaffeelistenverantwortliche
- Anfragen Verantwortliche -> Plattform-Administration

Scope:
- `support_requests`
- Richtung
- Kategorie
- Nachricht
- Absender
- Ziel
- Status
- Zeitstempel
- Routing- und Eskalationsregeln

Ergebnis:
- Nachvollziehbarer Kommunikationsprozess statt nackter Mailweiterleitung

Status:
- [X] Zielbild entschieden
- [ ] Workflow und Statusmodell spezifizieren

### Paket 5. Payment Configuration MVP

Ziel:
- Tenant-spezifische Zahlungsarten und Zahlungsdaten

Scope:
- Bar
- Ueberweisung
- PayPal
- aktivierte Methoden
- Hinweise fuer Benutzer
- tenantbezogene Zahlungsparameter
- Vorbereitung fuer spaetere Reconciliation

Ergebnis:
- Saubere Grundlage fuer spaetere Automatisierung

Status:
- [~] Teilweise geklaert
- [ ] Vorher Fachmodell vervollstaendigen

### Paket 6. Ledger Audit Und Korrekturen

Ziel:
- Buchungen sicher korrigieren statt direkt loeschen

Scope:
- Storno fuer Einzahlungen
- Loeschung fuer Stricheintraege
- Auditfelder
- Referenzen auf Ursprungseintraege
- Begruendung oder Freigabeoption
- Regeln fuer Import- und Jahresabschlusskorrekturen

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
- Rollen fuer Erstellung und Freigabe

Ergebnis:
- Nutzbares Survey-Modul fuer den operativen Betrieb

Status:
- [~] Teilweise geklaert
- [ ] Vorher Antwortoptionen und Freigabemodell ergaenzen

### 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 als Spezifikationspaket
- Tenant Payment Configuration als Fachmodell
- Support-Requests Datenmodell als Vorarbeit
- Survey-Admin-Konzept als Spezifikationspaket

Diese Themen sollten noch nicht in Produktcode parallel umgesetzt werden:

- Catch-all-Mailbox fuer PayPal
- finale Identity-Integration ohne Detailkonzept fuer Mapping und Fallback
- Survey-Publishing fuer Benutzer ohne Freigabemodell
- Audit-/Storno-Implementierung ohne fachliche Korrekturregeln
- Serienmail- oder Jahresabschlussfunktionen ohne Schutzmechanismen und Testmodus

## Konkrete Naechste Entscheidungsliste

### Entscheidungen Mit Hoher Prioritaet

- [ ] Rechte-Matrix finalisieren
- [ ] Support-Status, Routing und Eskalationsregeln festlegen
- [ ] Storno-/Loeschregeln fuer Buchungen finalisieren
- [ ] Identity-Detailregeln fuer Erstlogin, Fallback und Dubletten festlegen

### Entscheidungen Mit Mittlerer Prioritaet

- [ ] FAQ/Mailtexte als Standardvorlage mit Tenant-Override bestaetigen
- [X] Survey-Freigabemodell fuer Benutzer als Snapshot-Veroeffentlichung
  vorsehen
- [X] Payment Configuration MVP ohne Reconciliation, aber mit technischer
  Vorbereitung festlegen

### Entscheidungen Mit Nachgelagerter Prioritaet

- [ ] Catch-all-Mailbox ausdruecklich als spaeteres Integrationspaket bestaetigen
- [ ] Jahresauswertung und Bonuslogik als konfigurierbaren Prozess spezifizieren
- [ ] Zusatzfelder im Benutzerprofil tenantweit festlegen

## Empfehlung

Wenn du sofort in Umsetzung gehen willst, ist die sauberste Reihenfolge:

1. Phase 0 als kurzer Spezifikations- und Entscheidungs-Sprint
2. Content-MVP als erstes lieferbares Fachpaket
3. Rollenmatrix und Payment Configuration als Basis fuer weitere Module
4. Support Requests MVP und Ledger Audit/Korrekturen
5. Survey Admin MVP und danach Survey Publishing
6. Erst danach Payment-Reconciliation, Mailbox-Import und komplexere
   Identity-Integrationen

## Ticket-Struktur Fuer Phase 0

Ziel:
- Alle verbleibenden Detailregeln so festziehen, dass danach produktive
  Implementierung ohne Grundsatzdiskussion starten kann.

Empfohlene Epics:

### Epic P0-1. Identity Und Benutzerabgleich

Tickets:
- P0-1.1 Erstlogin-Flow fuer lokale Anmeldung und ADFS/OIDC beschreiben
- P0-1.2 E-Mail-Mapping, Dublettenfall und Admin-Klaerprozess definieren
- P0-1.3 Reaktivierung, Benutzerzusammenfuehrung und Fehlerfaelle festlegen

Ergebnis:
- Umsetzbare Identity-Spezifikation fuer Authentifizierung und Mapping

### Epic P0-2. Rollen Und Rechte

Tickets:
- P0-2.1 Rechte-Matrix pro Rolle und Objekt finalisieren
- P0-2.2 Tenant-Grenzen und Admin-Override dokumentieren
- P0-2.3 Spezialrollen `finance_admin`, `support_contact`, `survey_manager`
  gegen Fachprozesse pruefen und bestaetigen

Ergebnis:
- Belastbare Rechtebasis fuer alle MVP-Module

### Epic P0-3. Support-Workflow

Tickets:
- P0-3.1 Statusmodell fuer Supportvorgaenge definieren
- P0-3.2 Routing fuer Benutzer, Support-Verantwortliche, Tenant-Admins und
  Plattform-Administration festlegen
- P0-3.3 Sichtbarkeit, Eskalation und Abschlussregeln festziehen

Ergebnis:
- Vollstaendiges Vorgangsmodell fuer Support Requests

### Epic P0-4. Buchungskorrekturen Und Schutzmechanismen

Tickets:
- P0-4.1 Regeln fuer Storno von Einzahlungen definieren
- P0-4.2 Regeln fuer Loeschung von Stricheintraegen definieren
- P0-4.3 Begruendung, Auditspur und Historie fuer Korrekturen beschreiben
- P0-4.4 Vorschau, Testmodus und tenantweit deaktivierbare Vier-Augen-Freigabe
  fuer kritische Aktionen festlegen

Ergebnis:
- Verbindliches Regelwerk fuer sichere Korrekturen und risikoreiche Aktionen

### Epic P0-5. Survey-Freigabe Und Jahresauswertung

Tickets:
- P0-5.1 Survey-Freigabeprozess mit Snapshot-Veroeffentlichung definieren
- P0-5.2 Rollen fuer Survey-Erstellung, Freigabe und Veroeffentlichung
  bestaetigen
- P0-5.3 Jahresauswertung mit Parametern, Vorschau und Freigabe spezifizieren
- P0-5.4 Bonuslogik fuer fixe und flexible Auszahlungen fachlich schneiden

Ergebnis:
- Nutzbare Fachspezifikation fuer Surveys und Jahresauswertung

### Epic P0-6. Zahlungsmodell Und Profilfelder

Tickets:
- P0-6.1 Tenant-Zahlungsdaten und Pflichtfelder pro Zahlungsart definieren
- P0-6.2 Manuelle Klaerfaelle fuer Buchungen und spaetere Reconciliation
  beschreiben
- P0-6.3 Tenantweite Zusatzfelder wie `paypalname` fachlich festlegen

Ergebnis:
- Saubere Daten- und Konfigurationsbasis fuer Payment und Profile

## Ticket-Struktur Fuer Das MVP

Ziel:
- Aus den Phase-0-Ergebnissen ein erstes nutzbares Produkt mit stabilem
  Tenant-Betrieb bauen.

Empfohlene Epics:

### Epic MVP-1. Identity Baseline

Tickets:
- MVP-1.1 Lokale Anmeldung produktiv umsetzen
- MVP-1.2 ADFS/OIDC als zusaetzlichen Login integrieren
- MVP-1.3 E-Mail-Mapping und Admin-Klaerfall implementieren
- MVP-1.4 Benutzerabgleich, Reaktivierung und Fehlermeldungen absichern

Abhaengigkeit:
- Phase 0 Epic P0-1

### Epic MVP-2. Rollen Und Tenant-Administration

Tickets:
- MVP-2.1 Rollenmodell im System anlegen
- MVP-2.2 Rechtepruefung pro Modul umsetzen
- MVP-2.3 Tenant-Admin- und Spezialrollenverwaltung bereitstellen

Abhaengigkeit:
- Phase 0 Epic P0-2

### Epic MVP-3. Content Und FAQ

Tickets:
- MVP-3.1 Hinweisverwaltung mit CRUD, Aktivierung und Sichtbarkeit umsetzen
- MVP-3.2 FAQ-Verwaltung mit Standardvorlage und Tenant-Override umsetzen
- MVP-3.3 Frontend-Ausspielung fuer Hinweise und FAQ anbinden

Abhaengigkeit:
- Phase 0 Epic P0-2

### Epic MVP-4. Payment Configuration Und Manuelle Buchung

Tickets:
- MVP-4.1 Zahlungsarten pro Tenant konfigurieren
- MVP-4.2 Zahlungsdaten und Hinweise pro Zahlungsart pflegen
- MVP-4.3 Manuelle Einzahlungsbuchung und Self-Service-Anzeige umsetzen
- MVP-4.4 Datenmodell fuer spaetere Reconciliation vorbereiten

Abhaengigkeit:
- Phase 0 Epic P0-6

### Epic MVP-5. Ledger Korrekturen

Tickets:
- MVP-5.1 Storno fuer Einzahlungen implementieren
- MVP-5.2 Loeschung fuer Stricheintraege implementieren
- MVP-5.3 Auditspur, Begruendung und Historie fuer Korrekturen umsetzen

Abhaengigkeit:
- Phase 0 Epic P0-4

### Epic MVP-6. Support Requests

Tickets:
- MVP-6.1 Supportvorgaenge als Datenmodell und UI anlegen
- MVP-6.2 Statuswechsel, Routing und Sichtbarkeit implementieren
- MVP-6.3 Benutzeransicht fuer eigene Vorgaenge umsetzen
- MVP-6.4 Bearbeitungsansicht fuer Verantwortliche und Support-Kontakte
  umsetzen

Abhaengigkeit:
- Phase 0 Epic P0-3

### Epic MVP-7. Survey Admin Und Publishing

Tickets:
- MVP-7.1 Survey-Erstellung und Fragenverwaltung umsetzen
- MVP-7.2 Freigabeprozess fuer Tenant- und Survey-Verantwortliche umsetzen
- MVP-7.3 Snapshot-Veroeffentlichung fuer Benutzer implementieren
- MVP-7.4 Grundauswertung fuer Tenant-Admins bereitstellen

Abhaengigkeit:
- Phase 0 Epic P0-5

### Epic MVP-8. Schutzmechanismen Und Betriebsfaehigkeit

Tickets:
- MVP-8.1 Vorschau und Testmodus fuer kritische Sammelaktionen umsetzen
- MVP-8.2 Tenantweite Konfiguration fuer Vier-Augen-Freigabe umsetzen
- MVP-8.3 Logging, Audit und Fehlerbenachrichtigung fuer kritische Prozesse
  umsetzen
- MVP-8.4 Abnahmefaelle und Testdaten fuer Kernworkflows anlegen

Abhaengigkeit:
- Phase 0 Epic P0-4

## Empfohlene Reihenfolge Der MVP-Epics

1. MVP-1 Identity Baseline
2. MVP-2 Rollen Und Tenant-Administration
3. MVP-3 Content Und FAQ
4. MVP-4 Payment Configuration Und Manuelle Buchung
5. MVP-5 Ledger Korrekturen
6. MVP-6 Support Requests
7. MVP-7 Survey Admin Und Publishing
8. MVP-8 Schutzmechanismen Und Betriebsfaehigkeit

## Backlog-Format Fuer Tickets

Dieses Format kann direkt fuer Jira, GitHub Issues oder ein internes
Projektboard verwendet werden.

| Feld | Beschreibung |
| --- | --- |
| Ticket-ID | Eindeutige Kennung, z. B. `P0-1.1` oder `MVP-4.2` |
| Titel | Kurzer, umsetzungsorientierter Ticketname |
| Prioritaet | `hoch`, `mittel`, `niedrig` |
| Ziel | Welches Problem oder Ergebnis das Ticket adressiert |
| Beschreibung | Konkreter Umsetzungsumfang |
| Akzeptanzkriterien | Pruefbare Bedingungen fuer Abnahme |
| Abhaengigkeiten | Vorbedingungen oder vorherige Tickets |

## PRD-Backlog Fuer Phase 0

### P0-1.1 Erstlogin-Flow Fuer Lokale Anmeldung Und ADFS/OIDC

Prioritaet:
- hoch

Ziel:
- Den verbindlichen Anmelde- und Erstlogin-Prozess beschreiben.

Beschreibung:
- Beschreibt lokale Anmeldung, zusaetzliche ADFS/OIDC-Anmeldung und die
  Benutzerfuehrung beim ersten externen Login.

Akzeptanzkriterien:
- Lokale Anmeldung und ADFS/OIDC sind als erlaubte Login-Wege beschrieben.
- Erstlogin-Schritte fuer neue und bestehende Benutzer sind dokumentiert.
- Fehler- und Sonderfaelle sind benannt.

Abhaengigkeiten:
- keine

### P0-1.2 E-Mail-Mapping Und Dubletten-Klaerfall

Prioritaet:
- hoch

Ziel:
- Den Abgleich externer Identitaeten mit internen Benutzern festlegen.

Beschreibung:
- Definiert E-Mail als primaeren Matching-Schluessel und beschreibt
  Dubletten- oder Konfliktfaelle samt Admin-Klaerprozess.

Akzeptanzkriterien:
- Matching-Regel per E-Mail ist eindeutig dokumentiert.
- Dublettenfall fuehrt in einen definierten Admin-Klaerprozess.
- Reaktivierung bestehender Konten ist beschrieben.

Abhaengigkeiten:
- P0-1.1

### P0-2.1 Rechte-Matrix Pro Rolle Und Objekt Finalisieren

Prioritaet:
- hoch

Ziel:
- Eine abnahmefaehige Rechtebasis fuer alle MVP-Module schaffen.

Beschreibung:
- Finalisiert die Rollen `platform_admin`, `tenant_admin`, `finance_admin`,
  `support_contact`, `survey_manager`, `member` gegen alle relevanten Module.

Akzeptanzkriterien:
- Jede Rolle hat dokumentierte Rechte pro Modul.
- Tenant-Grenzen und Admin-Override sind beschrieben.
- Sonderfaelle fuer Storno, Loeschung und Freigabe sind enthalten.

Abhaengigkeiten:
- keine

### P0-3.1 Support-Statusmodell Und Routing Festlegen

Prioritaet:
- hoch

Ziel:
- Das Vorgangssystem fuer Support fachlich fertig schneiden.

Beschreibung:
- Definiert Statuswerte, Routing, Sichtbarkeit, Verantwortlichkeiten und
  Eskalation fuer Support Requests.

Akzeptanzkriterien:
- Statusmodell ist dokumentiert.
- Benutzer-, Support- und Admin-Sichtbarkeit ist beschrieben.
- Routing zu Tenant-Verantwortlichen und Plattform-Administration ist klar.

Abhaengigkeiten:
- P0-2.1

### P0-4.1 Regeln Fuer Storno, Loeschung Und Audit

Prioritaet:
- hoch

Ziel:
- Korrekturen an Buchungen fachlich und revisionssicher festlegen.

Beschreibung:
- Legt fest, dass Einzahlungen stornierbar und Stricheintraege loeschbar sind,
  jeweils nur durch Verantwortliche, inklusive Auditspur und Begruendung.

Akzeptanzkriterien:
- Storno-Regel fuer Einzahlungen ist dokumentiert.
- Loeschregel fuer Stricheintraege ist dokumentiert.
- Audit- und Historienanforderungen sind beschrieben.

Abhaengigkeiten:
- P0-2.1

### P0-4.2 Schutzmechanismen Fuer Kritische Aktionen

Prioritaet:
- hoch

Ziel:
- Risikoarme Ausfuehrung kritischer Sammelaktionen sicherstellen.

Beschreibung:
- Beschreibt Vorschau, Testmodus und tenantweit deaktivierbare
  Vier-Augen-Freigabe fuer kritische Aktionen.

Akzeptanzkriterien:
- Kritische Aktionen sind benannt.
- Vorschau/Testmodus-Regeln sind dokumentiert.
- Vier-Augen-Freigabe ist als tenantweite Option beschrieben.

Abhaengigkeiten:
- keine

### P0-5.1 Survey-Freigabe Und Snapshot-Veroeffentlichung

Prioritaet:
- mittel

Ziel:
- Die Freigabe und Sichtbarkeit von Umfrageergebnissen verbindlich festlegen.

Beschreibung:
- Beschreibt Rollen, Freigabeschritte und Snapshot-Veroeffentlichung fuer
  Survey-Ergebnisse.

Akzeptanzkriterien:
- Freigabe-Rollen sind benannt.
- Snapshot-Mechanik fuer Benutzer ist beschrieben.
- Ende und Veroeffentlichung einer Umfrage sind geregelt.

Abhaengigkeiten:
- P0-2.1

### P0-5.2 Jahresauswertung Und Bonuslogik Spezifizieren

Prioritaet:
- mittel

Ziel:
- Den bedarfsorientierten Jahresauswertungsprozess fachlich festlegen.

Beschreibung:
- Beschreibt Parameter wie Jahr, Bonusart, Betrag/Formel, Vorschau und
  Freigabeprozess.

Akzeptanzkriterien:
- Parameterliste ist dokumentiert.
- Vorschau- und Freigabeschritt sind festgelegt.
- Fixe und flexible Bonuslogik sind fachlich beschrieben.

Abhaengigkeiten:
- P0-4.2

### P0-6.1 Zahlungsdaten, Pflichtfelder Und Profilfelder Festlegen

Prioritaet:
- mittel

Ziel:
- Konfigurations- und Stammdaten fuer Payment und Matching definieren.

Beschreibung:
- Legt Pflichtfelder pro Zahlungsart und tenantweite Zusatzfelder wie
  `paypalname` fest.

Akzeptanzkriterien:
- Pflichtfelder je Zahlungsart sind dokumentiert.
- Zusatzfelder sind tenantweit definiert.
- Matching-relevante Felder sind gekennzeichnet.

Abhaengigkeiten:
- P0-1.2

## PRD-Backlog Fuer Das MVP

### MVP-1.1 Lokale Anmeldung Implementieren

Prioritaet:
- hoch

Ziel:
- Die lokale Systemanmeldung produktiv bereitstellen.

Beschreibung:
- Implementiert Login, Fehlerbehandlung und Benutzerfuehrung fuer lokale
  Konten.

Akzeptanzkriterien:
- Benutzer koennen sich lokal anmelden.
- Fehlerfaelle werden verstaendlich angezeigt.
- Login ist tenantfaehig eingebunden.

Abhaengigkeiten:
- P0-1.1

### MVP-1.2 ADFS/OIDC-Login Und E-Mail-Mapping

Prioritaet:
- hoch

Ziel:
- Externen Login entsprechend dem Zielbild produktiv aktivieren.

Beschreibung:
- Implementiert ADFS/OIDC, E-Mail-Mapping und Admin-Klaerfall bei Konflikten.

Akzeptanzkriterien:
- Login via ADFS/OIDC funktioniert.
- E-Mail-Mapping wird korrekt angewendet.
- Konfliktfaelle werden in einen Admin-Klaerprozess geleitet.

Abhaengigkeiten:
- P0-1.2
- MVP-1.1

### MVP-2.1 Rollenmodell Und Rechtepruefung Umsetzen

Prioritaet:
- hoch

Ziel:
- Das fachlich definierte Rollenmodell im System verankern.

Beschreibung:
- Implementiert Rollen, Modulrechte und Tenant-Grenzen.

Akzeptanzkriterien:
- Alle definierten Rollen sind im System vorhanden.
- Rechtepruefung greift pro Modul.
- Tenant-Admin hat Vollzugriff im eigenen Tenant.

Abhaengigkeiten:
- P0-2.1

### MVP-3.1 Hinweise Und FAQ Verwalten

Prioritaet:
- mittel

Ziel:
- Ein erstes produktiv nutzbares Content-Modul bereitstellen.

Beschreibung:
- Implementiert CRUD fuer Hinweise und FAQ inklusive Tenant-Override.

Akzeptanzkriterien:
- Hinweise koennen angelegt, bearbeitet und deaktiviert werden.
- FAQ koennen gepflegt werden.
- Standardvorlagen koennen tenantseitig ueberschrieben werden.

Abhaengigkeiten:
- MVP-2.1

### MVP-4.1 Zahlungsarten Und Zahlungsdaten Pro Tenant

Prioritaet:
- hoch

Ziel:
- Tenant-spezifische Zahlungsarten produktiv verwaltbar machen.

Beschreibung:
- Implementiert Bar, Ueberweisung und PayPal als konfigurierbare Zahlungsarten
  inklusive Pflichtfeldern und Hinweisen.

Akzeptanzkriterien:
- Zahlungsarten sind tenantweit konfigurierbar.
- Pflichtfelder werden validiert.
- Zahlungsinformationen werden im Frontend korrekt angezeigt.

Abhaengigkeiten:
- P0-6.1
- MVP-2.1

### MVP-4.2 Manuelle Einzahlungsbuchung Und Reconciliation-Vorbereitung

Prioritaet:
- hoch

Ziel:
- Manuelle Zahlungsbuchung stabil umsetzen und spaetere Reconciliation
  vorbereiten.

Beschreibung:
- Implementiert manuelle Buchung und bereitet Statusfelder fuer spaetere
  Reconciliation vor.

Akzeptanzkriterien:
- Einzahlungen koennen manuell gebucht werden.
- Buchungsstatus fuer spaetere Erweiterung ist im Modell vorhanden.
- Kein automatischer Mailbox-Import ist Teil des MVPs.

Abhaengigkeiten:
- MVP-4.1

### MVP-5.1 Einzahlungs-Storno Und Strich-Loeschung

Prioritaet:
- hoch

Ziel:
- Korrekturen gemaess Fachregel umsetzen.

Beschreibung:
- Implementiert Storno fuer Einzahlungen und Loeschung fuer Stricheintraege
  inklusive Auditspur.

Akzeptanzkriterien:
- Nur berechtigte Rollen duerfen korrigieren.
- Einzahlungen werden als Storno gefuehrt.
- Stricheintraege werden nachvollziehbar geloescht.

Abhaengigkeiten:
- P0-4.1
- MVP-2.1

### MVP-6.1 Supportvorgaenge Mit Status Und Routing

Prioritaet:
- hoch

Ziel:
- Support direkt als vollstaendiges Vorgangssystem bereitstellen.

Beschreibung:
- Implementiert Datenmodell, Statuswechsel, Routing und Ansichten fuer Benutzer
  und Verantwortliche.

Akzeptanzkriterien:
- Benutzer koennen Vorgaenge anlegen und verfolgen.
- Verantwortliche koennen Vorgaenge bearbeiten.
- Routing und Sichtbarkeit folgen dem Phase-0-Modell.

Abhaengigkeiten:
- P0-3.1
- MVP-2.1

### MVP-7.1 Survey-Verwaltung Und Snapshot-Publishing

Prioritaet:
- mittel

Ziel:
- Surveys fuer Tenant-Betrieb und Benutzerveroeffentlichung bereitstellen.

Beschreibung:
- Implementiert Survey-Erstellung, Freigabe und Snapshot-Ausgabe fuer Benutzer.

Akzeptanzkriterien:
- Surveys koennen angelegt und freigegeben werden.
- Benutzer sehen nur freigegebene Snapshots.
- Tenant-Admins und Survey-Manager koennen Ergebnisse auswerten.

Abhaengigkeiten:
- P0-5.1
- MVP-2.1

### MVP-8.1 Vorschau, Testmodus Und Vier-Augen-Konfiguration

Prioritaet:
- hoch

Ziel:
- Kritische Aktionen sicher und tenantkonfigurierbar ausfuehren.

Beschreibung:
- Implementiert Vorschau, Testmodus und die tenantweite Konfiguration der
  Vier-Augen-Freigabe.

Akzeptanzkriterien:
- Kritische Aktionen bieten Vorschau oder Testmodus.
- Vier-Augen-Freigabe ist pro Tenant aktivier- und deaktivierbar.
- Kritische Aktionen werden sauber protokolliert.

Abhaengigkeiten:
- P0-4.2
- MVP-2.1
