# 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.
- Fuer Entwicklungsarbeit reicht dieser Katalog allein nicht aus; die
  ergaenzenden Leitplanken und Mindestanforderungen in diesem Dokument sind vor
  paralleler Umsetzung mitzupflegen.

## 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 AD und ADFS soll hinzugefuegt werden.
- Eine Azure-AD-Variante ist ebenfalls als moegliche Tenant-Integration zu
  pruefen.

### 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 soll die Moeglichkeit geben, dass Benutzer Anfragen an die
  Verantwortlichen der Kaffeeliste des jeweiligen Kunden senden koennen.
- Es soll die Moeglichkeit geben, dass Verantwortliche der Kaffeeliste Anfragen
  an die zentrale Administration stellen koennen.

### 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 moeglich sein, dass Verantwortliche der Kaffeeliste Umfragen
  einrichten koennen.
- Verantwortliche der Kaffeeliste sollen Umfragen vollumfaenglich verwalten und
  auswerten koennen.

### 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 soll die Moeglichkeit geben, einen Jahresbonus oder eine
  Sonderausschuettung anhand der im Jahr verbrauchten Striche zu verteilen.
-

## 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?
- [X] Soll die Zahlung ueber ein konfigurierbares Zahlungsmodul mit mehreren
  Zahlarten laufen?
- [X] Brauchen Korrekturen kuenftig Storno- und Loeschregeln?
- [X] Umfrageergebnisse werden nach Freigabe durch Tenant-Verantwortliche oder
  Survey-Verantwortliche sichtbar.
- [X] `mailausgebe.php` spielt fuer die neue Webseite keine Rolle.
- [X] Jahresauswertungen sollen als bedarfsorientierter Prozess moeglich sein.
- [ ] 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 koennen. Bar,
  Ueberweisung und PayPal sollen auswaehlbar sein.
- Bei PayPal koennen Benachrichtigungen an ein tenantbezogenes Postfach gesendet
  werden. Ein Catch-all-Postfach fuer automatisierte Auswertung ist als spaeteres
  Integrationspaket vorgesehen.
- Die Umfrageergebnisse sollen nach Freigabe des Verantwortlichen auch die
  Benutzer sehen koennen.
- `mailausgebe.php` wird fuer die neue Webseite nicht uebernommen.
- Jahresauswertungen sollen bei Bedarf durch Verantwortliche ausgeloest werden
  koennen, inklusive moeglicher fixer oder flexibler Boni.
- FAQ und Mailtexte muessen durch die Verantwortlichen der Kaffeeliste angepasst
  werden koennen; zusaetzlich soll es eine Standardvorlage geben.
- Welche weiteren Profilfelder benoetigt werden, muss tenantweit noch ermittelt
  werden.

## Ergaenzte Leitplanken Fuer Das SaaS-Zielbild

Diese Leitplanken verdichten die bisher bekannten Antworten aus Katalog,
Roadmap und Review. Sie ersetzen noch keine Detailkonzepte, schaffen aber eine
stabilere Basis fuer die Fachspezifikation.

### Bereits Vorlaeufig Geklaert

- Self-Service-Stricheintrag soll erhalten bleiben, aber tenantbezogen
  aktivierbar sein.
- Einzahlungen sollen stornierbar sein; Stricheintraege sollen durch
  Verantwortliche loeschbar sein.
- Tenant-Admins sollen ihre Inhalte fuer Hinweise, FAQ, Umfragen und
  Zahlungsarten selbst pflegen koennen.
- Zahlungsarten sollen pro Tenant konfigurierbar sein: mindestens Bar,
  Ueberweisung und PayPal.
- Umfrageergebnisse sollen fuer Benutzer erst nach expliziter Freigabe sichtbar
  werden.
- FAQ- und Kommunikationstexte sollen als Standardvorlagen verfuegbar sein und
  tenantseitig ueberschrieben werden koennen.
- Supportanfragen sollen je nach Richtung an Tenant-Verantwortliche oder
  Plattform-Administration geroutet werden.
- Anmeldung soll immer lokal im System moeglich sein und zusaetzlich per
  ADFS/OIDC erfolgen koennen.
- `mailausgebe.php` wird nicht als Produktfunktion fuer die neue Webseite
  uebernommen.

### Noch Fachlich Zu Praezisieren

- Wie Erstlogin, Fallback und Dubletten bei lokaler Anmeldung plus ADFS/OIDC
  behandelt werden.
- Welche Spezialrollen neben `tenant_admin` und `member` benoetigt werden und
  welche Rechte diese konkret haben.
- Ob Zahlungsabgleiche per PayPal-Mailbox Teil des MVPs sind oder ein spaeteres
  Integrationspaket bilden.
- Wie Jahresauswertungen und moegliche Bonus-/Sonderausschuettungen fachlich
  parametrisiert werden.
- Welche zusaetzlichen Profilfelder kuenftig tenantweit oder pro Benutzer
  gepflegt werden muessen.

### Empfohlene Detailentscheidungen

- Identity: lokale Anmeldung immer aktiv, ADFS/OIDC als einzige zusaetzliche
  externe Anmeldung, E-Mail-Mapping als Standard, Admin-Klaerfall bei
  Dubletten.
- Payment: Reconciliation und Mailbox-Abgleich nicht im MVP, aber mit
  vorbereiteten Statusfeldern fuer spaetere Erweiterung.
- Surveys: Mitglieder sehen freigegebene Snapshots statt Live-Daten.
- Jahresauswertung: bedarfsorientierter Admin-Prozess mit Vorschau, Freigabe
  und parametrisierbarer Bonuslogik.
- Profilfelder: tenantweit konfigurierbare Zusatzfelder; `paypalname` ist
  Startkandidat fuer Matching.
- Schutzmechanismen: Vorschau und Testmodus fuer riskante Sammelaktionen im MVP,
  Vier-Augen-Freigabe fuer Jahresauswertung, Massenmail, Import und
  Sammel-Storno; die Vier-Augen-Freigabe muss tenantweit deaktivierbar sein.


## Mindestanforderungen Fuer Entwicklungsreife

Die folgenden Punkte fehlen in der Legacy-Ableitung noch oder sind nur implizit
enthalten. Sie sollten vor paralleler Umsetzung je Modul ergaenzt werden.

### Funktionale Mindesttiefe

- Pro Modul eine kurze Fachspezifikation mit Ausloeser, Vorbedingungen,
  Nachbedingungen und Fehlerfaellen.
- Pro Modul Akzeptanzkriterien fuer den MVP.
- Pro Workflow ein Statusmodell, mindestens fuer Support Requests, Surveys,
  Zahlungsabgleich und Buchungskorrekturen.
- Pro Integrationspunkt eine Beschreibung des Eingangsformats, der
  Fehlerbehandlung und der manuellen Klaerfaelle.

### Rollen Und Rechte

- Rechte-Matrix pro Rolle und Aktion, z. B. lesen, anlegen, freigeben,
  korrigieren, exportieren, versenden.
- Klarstellung, welche Rechte `tenant_admin` immer besitzt und welche
  Spezialrollen delegierbar sind.
- Tenant-Grenzen fuer Zugriffe, Exporte und Supportvorgaenge.
- Trennung zwischen Authentifizierung, Autorisierung und Benutzerabgleich.

### Daten Und Historie

- Felddefinitionen fuer Zahlungsdaten, Benutzerprofile, Support Requests,
  Surveys und Exportparameter.
- Regeln fuer Storno, Referenzen auf Ursprungseintraege und unveraenderliche
  Audit-Historie.
- Aufbewahrung, Archivierung und Sichtbarkeit historischer Daten.
- Dubletten- und Matching-Regeln fuer CSV-Importe und Mailbox-Abgleiche.

### Betrieb, Sicherheit Und Compliance

- Datenschutz- und Berechtigungskonzept fuer Mailadressen, Exporte und
  Kontostandskommunikation.
- Logging, Monitoring und Benachrichtigung bei fehlerhaften Importen,
  Massenaktionen und Integrationsfehlern.
- Backup-/Restore-Anforderungen fuer tenantkritische Daten.
- Schutzmechanismen fuer risikoreiche Aktionen wie Serienmail, Jahresabschluss
  und Sammelbuchungen, z. B. Vorschau, Testmodus, Vier-Augen-Freigabe.

### Testbarkeit Und Abnahme

- Mindestabdeckung fuer Unit-, Integrations- und End-to-End-Tests.
- Testdaten und Referenzfaelle fuer typische Tenant-Szenarien.
- Abnahmefaelle fuer Rollen, Storno, Zahlungsabgleich, Supportrouting und
  Survey-Freigabe.
- Definition of Done je Paket inklusive Doku, Monitoring und Betriebsfreigabe.

## Empfohlene Modulspezifikation Vor Umsetzung

Bevor ein Team ein Paket umsetzt, sollte fuer das jeweilige Modul mindestens
dieser kurze Steckbrief vorliegen:

| Punkt | Erwartete Aussage |
| --- | --- |
| Ziel | Welches Fachproblem loest das Modul im MVP? |
| Rollen | Wer darf lesen, pflegen, freigeben, exportieren oder korrigieren? |
| Kernworkflow | Welche Schritte durchlaeuft ein Vorgang von Start bis Abschluss? |
| Daten | Welche Stammdaten, Bewegungsdaten und Referenzen werden benoetigt? |
| Fehlerfaelle | Welche Validierungs-, Import- und Berechtigungsfehler gibt es? |
| Historie | Welche Aktionen muessen nachvollziehbar protokolliert werden? |
| Akzeptanz | Woran erkennen Fachseite und Entwicklung, dass der MVP fertig ist? |

## Entscheidungsbedarf Fuer Die Naechste Runde

Diese Entscheidungen sind aus heutiger Sicht die wichtigsten, bevor mehrere
Teams parallel in Produktcode arbeiten:

1. Identity-Zielbild: ein bevorzugter Standardpfad oder tenantweise frei
   verfuegbare lokale Anmeldung plus zusaetzliches ADFS/OIDC mit E-Mail-Mapping.
2. Rollenmodell: finale Rollenliste plus Rechte-Matrix mit Admin-Override.
3. Supportmodell: Vorgangssystem mit Status, Routing und Sichtbarkeit.
4. Zahlungs-MVP: nur Konfiguration und manuelle Buchung oder bereits mit
   Reconciliation-Vorbereitung.
5. Survey-Freigabe: wer freigibt, welche Ergebnisse sichtbar werden und ob live
   oder per Snapshot veroeffentlicht wird.
6. Jahresauswertung: bedarfsorientierter Fachprozess mit welchen Parametern und
   Freigaben.


### Konkrete Festlegungen Aus Der Review

- Anmeldung funktioniert immer per lokaler Systemanmeldung und zusaetzlich per
  ADFS/OIDC.
- Rollen `finance_admin`, `support_contact` und `survey_manager` sollen als
  Spezialrollen vorgesehen werden.
- Supportanfragen sollen in der Anwendung als Vorgang mit Status sichtbar sein;
  Empfaenger sind Tenant-Verantwortliche oder Support-Verantwortliche.
- Zahlungsabgleiche per PayPal-Mailbox sind nicht Teil des MVPs.
- Reconciliation wird als Folgepaket geplant, aber im Datenmodell vorbereitet.
- `mailausgebe.php` wird nicht uebernommen, ausser eine andere Produktfunktion
  braucht diese Ausgabe technisch intern.
- Zusaetzliche Profilfelder sollen tenantweit definiert werden; ein Kandidat ist
  `paypalname` fuer Matching-Zwecke.
- Survey-Freigaben erfolgen durch Tenant-Verantwortliche oder
  Survey-Verantwortliche. Diese steuern Freischaltung, Ende und
  Veroeffentlichung.
- Fuer Benutzer werden freigegebene Snapshot-Staende veroeffentlicht.
- Es gibt keinen fixen Jahresabschluss; stattdessen soll eine bedarfsorientierte
  Jahresauswertung mit fixer oder flexibler Bonusverteilung moeglich sein.
- Vorschau und Testmodus sollen fuer risikoreiche Sammelaktionen Teil des MVPs
  sein; Vier-Augen-Freigabe fuer besonders kritische Aktionen folgt ebenfalls
  dem Zielbild und muss tenantweit deaktivierbar sein.
