Onboarding über Fragenkataloge — ein Katalog je Altformular, eine Bestätigung je Katalog
Zielgruppen: Business/Management (Kernaussage, Ablauf) · IT-Dev/Architektur (Modell, Abgrenzung) · Compliance. Status: Konzept (Issue #703, MED-D-703) — noch nichts gebaut; offene Punkte #704 (Textfreigabe) und #707 (apoBank). True North: beantwortet #1 („Was fehlt?" — je Katalog sichtbar), #2 („Was ist fällig?" — Nachweis-Ablauf als Aufgabe) und #3 („Lückenlos dokumentiert?" — Fassung je Unterschrift). Auslöser: Nutzer: Onboarding vereinfachen — bisher Beratung im Büro, Formulare gemeinsam ausgefüllt und unterschrieben.
1. Kernaussage (BLUF)
Jedes Altformular wird als Fragenkatalog (FK) abgebildet. Der Kunde beantwortet die Kataloge online, jedes Attribut nur einmal (Delta), liefert die geforderten Nachweise (einmal, katalogübergreifend) und bestätigt/unterschreibt je Katalog. Kataloge hängen am Beratungsangebot: Das Standard-Onboarding ist ein fester Satz, der Berater wählt weitere Kataloge hinzu. Die Einzelformulare bleiben als Ausgabe erhalten.
2. Bausteine
| ID | Baustein | Inhalt |
|---|---|---|
| OB-F1 | Fragenkatalog | Fragen (Weltmodell-Attribut · Rolle Kunde/Berater · Bedingung) · Nachweis-Anforderungen · Ausgabeform · Bestätigungstext |
| OB-F2 | Zuordnung zum Beratungsangebot | Je Angebot eine Katalogliste; Standard-Onboarding fix, Berater ergänzt |
| OB-F3 | Delta in der Abfrage | Ein Attribut wird einmal gefragt, auch wenn mehrere Kataloge es brauchen; Bekanntes erscheint vorbelegt zum Prüfen |
| OB-F4 | Bestätigung je Katalog | Zeigt alle Werte des Katalogs (auch nicht erneut gefragte) — dedupliziert wird nur die Abfrage, nie die Bestätigung |
| OB-F5 | Nachweise katalogübergreifend | Am Kunden, nicht am Katalog; ein Upload erfüllt alle fordernden Kataloge |
| OB-F6 | Wiederholungsgruppen | Mehrere Einträge einzeln dargestellt, z. B. je Lastschriftmandat (privat/Praxis, wiederkehrend/einmalig) oder je Kind |
| OB-F7 | Textbausteine | Standardformulierungen/Bestätigungen als versionierte Plattform-Texte mit Platzhaltern (z. B. Vollmacht Steuerberaterauskunft); Pflege in der Verwaltung, Startvorlagen werden aus den vorhandenen PDF übernommen |
| OB-F8 | Katalog fragt nur Platzhalter | Beim Baustein-Katalog entfällt weitere Kundenangabe; gefragt wird nur, was der Text braucht (z. B. Kontaktsteuerberater) |
| OB-F9 | Kontaktsteuerberater | Getrennt erfasst: privat und je Praxis (er kann abweichen). Beim Erfassen wird die Übernahme der Daten eines bereits erfassten Steuerberaters angeboten (Vorbelegung, nie stille Übernahme); Bausteine nutzen den passenden Kontext |
| OB-F10 | Ablauf-Aufgabe | Nachweise mit Ablaufdatum (z. B. Ausweis): 1 Monat vorher Aufgabe (Wiedervorlage) |
| OB-F11 | Signatur | Ein DocuSign-Vorgang je Katalog mit einem Dokument; jeder Katalog einzeln abschließbar |
| OB-F12 | Fallback eigenhändige Unterschrift | Wo die Gegenpartei keine elektronische Unterschrift akzeptiert (z. B. apoBank, #707): befülltes PDF zum Ausdruck → handschriftlich unterschreiben → Scan/Upload als Rücklauf; Status „Original erwartet" bis zum bestätigten Eingang |
| OB-F13 | Abschnittsfreigabe | Prüfung der Online-Antworten durch den Berater je Abschnitt („alles i. O." mit einem Klick); Ablehnung einzelner Felder bleibt Ausnahme mit Grund (MED-D-89) |
Drei Ausgabearten je Katalog: Hausformular (PDF-Vorlage) · Fremdformular (nur Feldmapping, z. B. apoBank) · Textbaustein (Plattform-Text).
3. Standard-Onboarding (aus der Checkliste „Allgemeine Kundenunterlagen")
| Katalog | Inhalt (Quelle) | Nachweise |
|---|---|---|
| FK-1 Kundendaten | Allgemein · Privat · Familienstand · Kinder (Gruppe) · Praxis · Tätigkeitsform · Steuernummer · Steuer-ID (Eingaben) | Personalausweis (Vorder-/Rückseite), Meldebescheinigung |
| FK-2 Lastschrift | Einwilligung Lastschriftverfahren (mit Widerrufsbelehrung) · SEPA-Mandat je Konto | — |
| FK-3 apoBank | Fremdformular, Felder gesetzt (15 beschreibbare Felder mit generischen Namen fill_n → Mapping manuell) | je nach Formular |
| FK-4 Vollmachten | Textbausteine (Vollmacht medidentas, Steuerberaterauskunft, pma) — Platzhalter: Kontaktsteuerberater | gebaut mit Beispieltexten (2026-10-18): vollmacht_medidentas, vollmacht_steuerberater, pma_vollmacht; Wortlaut offen, Texte in der Verwaltung editierbar (Onboarding-Texte-Freigabe.md) |
Der Berater kann weitere Kataloge wählen (z. B. Beratungsprotokoll, Immobilienfinanzierung mit Rechnern für Wohnfläche/umbauten Raum). Die Formel-Logik der Rechenblätter wird dann als Berechnungs-Feld im Katalog abgebildet.
4. Abgrenzung / Anschluss an Bestehendes
- Annahme (ungeprüft): Die Bausteine lassen sich auf Feld-Engine,
FormularVorgang, Fremdformular-Feldmapping (MED-D-235/248) und Unterlagen-Vorlagen je Produkt (MED-D-630) aufsetzen. Der Abgleich mit dem Code steht aus und ist der erste Schritt der Umsetzung. - Der Rückläufer-Regelkreis (MED-D-89: Sichtung → Feedback → Korrektur) gilt weiter; Standard ist die Abschnittsfreigabe (OB-F13, OB-Q5 entschieden), die Feld-für-Feld-Sichtung bleibt als Ausnahmepfad.
- Weltmodell (G-8): neue Attribute (z. B. Kontaktsteuerberater) kommen zuerst ins Data Dictionary.
4a. "Warum fragen wir das?" je Feld (MED-D-425, gebaut)
Jedes Kunden-Feld der Kataloge hat eine kurze Begründung (G-3, zugleich Zweckbindung G-5/G-6). Ablauf:
- Entwürfe von Medidentas, Prüfung und Freigabe durch den Betrieb je Fragebogen (Verwaltung → "Warum fragen wir das?"). Ohne Freigabe sieht der Kunde keine Texte; die Freigabe gilt nur für genau diese Fassung (Hash), jede Änderung braucht eine neue.
- Die Texte gehören nicht zur Katalog-Fassung: der Kunde bestätigt sie nicht, eine Textänderung sperrt keine offenen Vorgänge.
- Grundlage der Entwürfe: dokumentierte Zwecke (Data Dictionary, #666, #715, #779) und die Ausgabe des Katalogs; wo kein Zweck dokumentiert ist, ist der Text eine Formulierung zur Prüfung, keine Rechtsauskunft.
- Teil (b) von #425 (auswertungsgetriebener Ausfüllgrad) ist als #831 abgespalten, s. 4b.
4b. Auswertungs-Stand je Fragebogen (MED-D-831, #831)
Kernaussage: Kunde und Berater sehen nicht nur, wie viel ausgefüllt ist, sondern welche Unterlage die Angaben schon ermöglichen und was ihr fehlt (True North 1 und 2). Der Bedarf wird abgeleitet, nicht gepflegt (G-2).
| Auswertung je Katalog | Braucht | Quelle im Code |
|---|---|---|
| Eigene Unterlage „… erstellen" | sichtbare Kunden-Pflichtfelder · Platzhalter des Textbausteins · Felder des Fremd-PDFs (pdfMapping) | domain/katalog-auswertung.ts |
| Andere Unterlage „… vorausfüllen" | die Felder dieses Katalogs, deren Weltmodell-Attribut ein anderer Katalog (Pflicht/pdfMapping) oder eine DocuSign-Vorlage (Weg B) braucht | dito |
- Rechnung an einer Stelle:
bewerteAuswertungeninshared/feld-kern/auswertung.tsläuft im Browser (live beim Ausfüllen) und im Worker (Kunden-Detail). Ausgeblendete Felder zählen nicht; als "weiß ich nicht"/"wird nachgeliefert" markierte Felder gelten als offen; vorbelegte Werte (Stammdaten, andere Kataloge) zählen als vorhanden. - Anzeige: Kundenseite
md-auswertung-stand("1 von 3 Unterlagen ist mit Ihren Angaben schon möglich", aufklappbar mit "es fehlt: …"); Kunden-Detail → Fragebögen: "Unterlagen möglich: 1 von 3 (offen: …)". Nichts wird gespeichert. - Dentmarking nutzt denselben Kern (je Kennzahl eine Auswertung), s.
docs/spezialtools/Dentmarking.mdDM-9 h). - Bewusst nicht (MED-D-831-2): Ausfüllformular, Onboarding-Stammdaten, Dexman-Monatsmeldung — dort wäre die "Auswertung" nur "Pflichtangaben vollständig", das zeigen die bestehenden Fortschrittsanzeigen schon.
5. Compliance (DE/AT/CH)
| ID | Thema |
|---|---|
| OB-F-DS | Datenschutzhinweise einmal je Kunde quittiert, nicht je Katalog |
| OB-F-WID | Widerrufsbelehrung muss auf dauerhaftem Datenträger zugehen; Teil von Bestätigung FK-2 und abgelegter Fassung |
| OB-F-DRITT | Datenweitergabe an Dritte (Abrechnungsdienstleister) als eigene, sichtbare Einwilligung — nicht in Sammelbestätigung verstecken |
| OB-F-NACHW | Je Nachweis Zweck, Rechtsgrundlage und Aufbewahrung begründen (G-6); ob Ausweiskopie zwingend ist, fachlich/rechtlich klären |
| OB-F-TEXT | Bausteintexte sind Rechtstexte → fachliche/juristische Freigabe vor Live; je Unterschrift Fassung (Version + Hash) speichern (G-4) |
| OB-F-STB | Vollmacht Steuerberaterauskunft berührt Dritte; vom Steuerberater nur Name und Anschrift speichern (G-6); Widerruf/Geltungsdauer im Text |
| OB-F-STID | Steuer-ID, Familienstand, Kinder (nur Vorname und Geburtsmonat/-jahr; Zweck Beratung und Prognose) werden als Stammdaten gespeichert (Nutzerentscheidung 2026-10-14; ändert die bewusste Datensparsamkeit aus MED-D-284). Zweck, Rechtsgrundlage und Aufbewahrung sind zu dokumentieren — Pflicht vor Live (#715); Kinder sind Daten Minderjähriger. Der Schutz-Test gegen ein Steuer-ID-Ziel (stammdaten-uebernahme.test.ts) wurde mit S0b-1 angepasst |
| OB-F-LINK | Der Katalog-Link /oeffentlich/katalog/:token ist eine weitere öffentliche, token-basierte Kundenstrecke (im vorhandenen /oeffentlich*-Access-Bypass; Golden-Rule-Ausnahme wie die vier bestehenden). Wer den Link hat, sieht und ändert die Angaben (RISK-39). Begrenzt (Nutzervorgabe): Link 14 Tage absolut gültig (kein gleitendes Fenster), Erneuern durch den Berater rotiert den Token (der alte Link ist sofort tot), abgelaufen → 410 ohne Daten, Altbestand ohne Ablauf gilt als abgelaufen, nach Bestätigung/Signatur nur noch Status (keine Felder/Antworten). Offen: Rate-Limiting/Turnstile; Ablauf der übrigen öffentlichen Strecken (#739) |
| OB-F-SIG | Signatur-Niveau (SES/AES/QES) je Katalog festlegen (OP-SIGN-1): Fragenkatalog.signaturNiveau. Achtung: ohne Angabe greift die Niveau-Matrix nach Dokument-Bezeichnung (niveauFuer) — dort führt ‚Vollmacht‘ zu QES; für die Vollmacht-Kataloge (FK-4) ist das Niveau bewusst zu entscheiden |
| OB-F-BANK | Akzeptanz einer DocuSign-Unterschrift auf dem apoBank-Formular unbelegt (#707); Fallback = Ausdruck mit eigenhändiger Unterschrift (OB-F12) |
6. Entscheidungen (Nutzer, 2026-10-14)
Nachweise katalogübergreifend am Kunden · Steuernummer/Steuer-ID = Eingaben · Nachweis-Ablauf = Aufgabe 1 Monat vorher · ein DocuSign-Vorgang je Katalog (V1) · Vollmachten = Textbausteine der Plattform, befüllt über den Kontaktsteuerberater · Textpflege in der Verwaltung, Vorlagen aus den PDF übernommen (OB-Q12) · Kontaktsteuerberater privat getrennt und je Praxis erfasst, Datenübernahme wird angeboten (OB-Q13, „möglicherweise" verschieden) · Abschnittsfreigabe als Standard-Prüfung (OB-Q5) · apoBank: Fallback Ausdruck mit eigenhändiger Unterschrift (OB-Q6).
7. Offen
- #704 (OB-Q12): Wer gibt die Standardtexte juristisch frei? Status je Text: Onboarding-Texte-Freigabe.md. Konkret zu prüfen: Einwilligung Lastschriftverfahren inkl. Widerrufsbelehrung · SEPA-Mandat/Einzugsermächtigung · Datenschutzhinweise Kundendaten · Datenschutz/unverschlüsselte Übertragung (Beratungsprotokoll) · Wahrheitsversicherung Rechenblätter; Vollmachtstexte liegen noch nicht vor.
- Rechenregeln der Rechenblätter (neu, S1): Wie sich 3 %-Abzug, Balkon-/Dachschrägen-Anrechnung (50 %) und Faktoren des umbauten Raums kombinieren, ist fachlich zu bestätigen; der Test-Ausdruck im Feld-Kern ist eine Annahme und nicht freigegeben.
- #707 (OB-Q6): Akzeptanz der apoBank (DocuSign vs. Original); Fallback ist beschlossen.
8. Nicht gelesen (Transparenz)
Von den Eingabedokumenten wurden nur Anfangsteile ausgewertet: Makler-Alleinauftrag (Seiten 1–3 von 11),
Beratungsvereinbarung PVA (Seiten 1–3 von 9), Datenschutzhinweise im Erfassungsbogen (ab Seite 5), Inhalt des
apoBank-Formulars (nur Feldliste). Die Vollmacht-Formulare lagen nicht vor; ihre Texte werden bei der Umsetzung aus den PDF übernommen. Abkürzungen EDUE, pma, con.fee
sind aus den Quellen übernommen und hier nicht aufgelöst.
9. Code-Abgleich (Stand 2026-10-14, Stichproben nachgeprüft)
| Baustein | Befund im Code | Urteil |
|---|---|---|
| Feld-Engine | Feld/FormularSchema in server/src/domain/feld.ts, Client-Engine PubFeldEngine in client/src/app/pub-bausteine.ts. Keine Bedingungen, Wiederholungsgruppen, Rolle Kunde/Berater, Berechnungsfelder | erweitern |
| Vorgang-Store | formular_vorgang (Migration v57), Status nur entwurf · eingereicht · korrektur; schemaRef wird nur gegen Ausfüll-Vorlagen aufgelöst; letzte Migration v68 | erweitern |
| Fremdformular | Weg A (AcroForm-Mapping fremdformular_mapping, Feld-Editor) trägt ein apoBank-PDF mit fill_n; Weg B (DocuSign-Template) braucht Attributschlüssel als tabLabel | wiederverwenden (Weg A) |
| Weltmodell | WELTMODELL_ATTRIBUTE (18 Attribute) ohne Kinder, Familienstand, Steuernummer, Steuer-ID, Kontaktsteuerberater; daneben getrennte Schlüsselräume (STAMMDATEN_FELDER, STAMM_ZIELE, KundenFeld) | vereinheitlichen |
| Nachweise | Dokument.gueltigBis vorhanden; Wiedervorlage entsteht am Ablaufdatum, nicht 1 Monat vorher; Nachweis am Kunden katalogübergreifend fehlt; unterlagen_vorlage ist je Produkt | erweitern |
| Signatur | SignaturProvider: ein Dokument je Vorgang/Envelope — passt zu „ein Vorgang je Katalog"; Webhook-Write-back vorhanden; Bindung an Katalog-Fassung (Version+Hash) fehlt | wiederverwenden + erweitern |
| Textbausteine | Hausformulare fest im Code (dokumentvorlagen.ts), keine Platzhalter, keine versionierten Texte, keine Verwaltung | fehlt |
| Steuerberater | nur 4 flache Spalten am Mandanten (model.ts:65-68), keine Entität, keine Trennung privat/Praxis | fehlt |
| Sichtung | „Abschnitts-Freigabe" gibt es, akzeptiert aber alle offenen Felder des Vorgangs; Feld.abschnitt ungenutzt | erweitern |
| Fragenkatalog, Delta, Bestätigung je Katalog, Fallback eigenhändig | nichts vorhanden | fehlt |
Träger der Kundenansicht: formular-public (nutzt die Engine schon, mit Korrektur-Schleife); onboarding-public
wird danach abgelöst; der Dentmarking-Fragebogen bleibt bewusst eigenständig (MED-D-300).
10. Slice-Plan (Vorschlag)
Jeder Slice ist einzeln auslieferbar, dormant/flag-gesichert, mit Tests auf allen betroffenen Wegen (Vitest · gemockte E2E · Full-Stack-E2E) und Weltmodell-Eintrag vor dem Code (G-8).
| Slice | Inhalt | Aufwand (grob) |
|---|---|---|
| S0 | Data Dictionary: neue Attribute (Kinder, Familienstand, Steuernummer, Steuer-ID, Kontaktsteuerberater) + ein gemeinsamer Attribut-Schlüsselraum für Fragen und Formularfelder. S0a ✅ (Dictionary), S0b-1 ✅ (Mandant: steuerId, familienstand, Migration v73, Versionierung, Weltmodell-Attribute), S0b-2 ✅ (Steuerberater je Praxis, Kinder 1:n mandant_kind, Migration v74; Weltmodell-Attribut kind.* folgt mit S1) | klein–mittel |
| S1 | Feld: Bedingung, Wiederholungsgruppe, Rolle Kunde/Berater, Berechnungsfeld; PubFeldEngine zieht nach. ✅ gebaut: geteilter Kern shared/feld-kern/, feld.ts (Pflicht nur für sichtbare Felder je Rolle und je Gruppeneintrag, Schema-Konsistenz), PubFeldEngine (Bedingungen, abgeleitete Felder; Gruppen-Rendering folgt mit S3) | mittel |
| S2 | Fragenkatalog-Entität + Zuordnung Beratungsangebot → Kataloge + Status bestätigt/signiert. ✅ gebaut als eigene Entität KatalogVorgang (Migration v75, Tabellen katalog_vorgang und angebot_katalog) und KatalogService — nicht als Erweiterung von FormularVorgang (siehe Abweichung unten). Kataloge liegen im Code mit Fassung (Version + Hash); die Zuordnung pflegt die Verwaltung (Oberfläche folgt). Routen/Kundenansicht mit S3 | mittel |
| S3 | Delta-Berechnung + interaktiver Fragebogen; Bestätigung je Katalog mit Fassung (Version+Hash). ✅ gebaut: Feld.attribut (Weltmodell-Verweis), Delta-Ansicht im KatalogService (Vorbelegung aus anderen Katalogen, dann Stammdaten; Bestätigung hält Bekanntes fest), Routen (öffentlich /oeffentlich/katalog/:token, Berater /api/mandanten/:id/kataloge…, Verwaltung /api/angebot-kataloge), eigene Kundenseite katalog-public (statt Umbau von formular-public) mit ‚bekannt‘-Liste, Bedingungen, Wiederholungsgruppen, Zusammenfassung, Bestätigung. Offen: Berater-Oberfläche im Kunden-Detail und Verwaltungs-Oberfläche für die Zuordnung; Übernahme bestätigter Angaben in die Stammdaten (bestehender Review-Weg); Gruppen-Vorbelegung (Kinder) | mittel–groß |
| S4 | Katalog-PDF als Ausgabe + ein DocuSign-Vorgang je Katalog; Write-back setzt Vorgang signiert. ✅ gebaut für die Ausgabeart ‚Bestätigungsblatt‘: aus dem bestätigten Katalog entsteht ein PDF (Titel, Kunde, Fassung + Beleg-Hash, Bestätigungstext, alle Angaben — dieselbe Anzeige-Logik shared/feld-kern/anzeige.ts wie die Zusammenfassung im Browser) als ein Dokument in einem Signatur-Vorgang (KatalogUnterschriftService, Route POST /api/mandanten/:id/kataloge/:token/zur-unterschrift); Rückweg über einen Hook am SignaturService (läuft auch bei jedem weiteren Abgleich eines signierten Vorgangs → ein einmal gescheiterter Hook geht nicht verloren). Schutzriegel (G-4): nur bestaetigt, Beleg-Hash muss zu den Antworten passen, die Katalog-Fassung im Code muss dem bestätigten Stand entsprechen; frühere Fassungen bleiben in der Registry. Offen: die Ausgabearten Haus-/Fremdformular und Textbaustein (S6/S7) — dort ersetzt das jeweilige Zielformular das Bestätigungsblatt; Berater-Oberfläche für ‚zur Unterschrift‘ | mittel |
| S5 | Nachweis-Typ am Kunden, katalogübergreifend, Pflicht-Ablauf, Wiedervorlage 1 Monat vorher. ✅ gebaut: Dokument.nachweisTyp (Migration v77) markiert das EINE Dokument je Kunde und Typ (Altdokument ‚Personalausweis‘ aus dem Onboarding wird übernommen, kein Doppel); Fragenkatalog.nachweise (Typ + Pflicht); Typen personalausweis (Ablauf Pflicht) und meldebescheinigung (kein Ablauf — Annahme); Stand abgeleitet (fehlt · angefordert · Ablauf fehlt · vorhanden · läuft ab · abgelaufen); Routen GET /api/mandanten/:id/nachweise, POST …/nachweise/anfordern, PUT …/nachweise/:docId/gueltigkeit; Wiedervorlage für Nachweise einen Kalendermonat vor Ablauf (Datumsänderung verschiebt, Entfernen schließt; andere Dokument-Fristen unverändert); Kundenseite zeigt den Status in Klartext — kein Upload auf der Katalogseite (Upload über Portal bzw. vorhandenen Upload-Link, keine zusätzliche öffentliche Fläche). Nachweise blockieren die Bestätigung nicht (Annahme). Offen: Berater-Oberfläche (Anfordern, Ablaufdatum erfassen), Ablaufdatum aus dem Upload erfassen | mittel |
| S6 | Textbausteine (versioniert, Platzhalter) + Kontaktsteuerberater-Entität (privat/je Praxis, Übernahmeangebot). ✅ gebaut: Textbausteine (Migration v78): Fassungen append-only mit Inhalts-Hash und Herkunftsangabe, Freigabe einmalig (nur freigegebene Fassungen werden verwendet — das ist die technische Absicherung zu #704), Platzhalter {{feldschluessel}} verweisen auf Felder des ausgebenden Katalogs (also auf die bestätigten, eingefrorenen Antworten, nicht auf veränderliche Stammdaten); die Freigabe prüft, dass jeder Platzhalter ein Feld hat. Ausgabeart Textbaustein: Bestätigung nur mit freigegebener Fassung und gefüllten Platzhaltern, die Fassung wird bei der Bestätigung eingefroren (Teil des Beleg-Hashs), die Unterschrift gilt genau diesem Wortlaut (Dokument = der Baustein, z. B. ‚Vollmacht …‘). Verwaltung: Abschnitt ‚Textbausteine‘ (anlegen, neue Fassung, Text ansehen, freigeben). Kontaktsteuerberater: privat (am Kunden, hash-versioniert) und je Praxis getrennt; Übersicht, Erfassen, Übernahme als Angebot (GET/PUT/POST /api/mandanten/:id/steuerberater…), Überschreiben nur ausdrücklich; Katalog-Vorbelegung aus praxis.steuerberater.* nur bei genau einer Praxis. Offen: Startvorlagen aus den PDF einspielen (Inhalt, nicht Mechanik; Texte liegen bis zur Freigabe bewusst nicht im Repo), Oberfläche für Steuerberater im Kunden-Detail, Mehrfach-Praxis-Zuordnung im Katalog, Katalog FK-4 selbst (S9) | mittel–groß |
| S7 | Fremdformular (Weg A, apoBank-Mapping) als Ausgabeart + Fallback eigenhändige Unterschrift („Original erwartet"). ✅ gebaut: Fragenkatalog.pdfMapping (PDF-Feld → Weltmodell-Attribut, Teil der Katalog-Fassung); die PDF-Vorlage liegt in der Ablage (<Basis>/_Vorlagen/<ref>.pdf, Upload PUT /api/fremdformular-vorlagen/:ref, nur Admin, prüft auf ausfüllbare Felder); die Bestätigung friert den Vorlagen-Hash ein (im Beleg-Hash), Unterschrift/Ausdruck prüfen ihn neu (vorlage_veraendert). Befüllt wird je Feld aus der Antwort (Feld.attribut), sonst aus den Stammdaten; das befüllte PDF ist das EINE Dokument im Signatur-Vorgang. Fallback: POST …/kataloge/:token/ausdruck liefert dieselbe Fassung als PDF (Bestätigungsblatt mit Unterschriftszeile bzw. befülltes Fremdformular), legt einmalig die Wiedervorlage „Unterschriebenes Original erwartet“ (14 Tage) an; POST …/original-erhalten (nur nach Ausdruck) setzt den Katalog auf signiert ohne Signatur-Vorgang (Papier) und erledigt die Aufgabe; KatalogStand.originalErwartet. Offen: echte apoBank-Vorlage hochladen und Mapping der 15 fill_n-Felder festlegen (S9); Berater-Oberfläche für Ausdruck/Original; Scan als Dokument am Kunden (bestehender Upload); Akzeptanz DocuSign bei der apoBank (#707). | mittel |
| S8 | Abschnittsfreigabe je Abschnitt, katalogübergreifend (Feld.abschnitt nutzen). ✅ gebaut: Nach der Bestätigung des Kunden sichtet der Berater je Abschnitt (nur Kunden-Felder, leere Abschnitte entfallen): Freigabe (…/abschnitte/:abschnitt/freigabe, oder POST /api/mandanten/:id/sichtung/freigeben = alle offenen Abschnitte aller Kataloge des Kunden mit einem Klick) oder Ablehnung mit Grund je Feld (…/ablehnung; MED-D-89) — sie öffnet den Katalog wieder, der Kunde sieht die Gründe als ‚Bitte korrigieren Sie diese Angaben‘. Das Urteil ist an den Inhalts-Hash der geprüften Antworten gebunden (Migration v79 katalog_abschnitt): ändern sich die Antworten, ist die Freigabe veraltet; unveränderte Abschnitte behalten sie. Gate: ohne Freigabe aller Abschnitte keine Unterschrift/kein Ausdruck (sichtung_offen). Audit PII-arm (nur Abschnitt, Anzahl Felder; Gründe nicht im Log). Offen: Berater-Oberfläche; Mail-Rückmeldung an den Kunden bei Ablehnung (Benachrichtigungs-Seam); Sperre bereits akzeptierter Felder in der Korrektur; ob die Sichtung bei reinen Stammdaten-Vorbelegungen entfallen darf. | klein–mittel |
| S9 | Standard-Satz FK-1…FK-4 einspielen, Alt-Strecke onboarding-public ablösen. Teil 1 ✅ gebaut (2026-10-15): domain/kataloge/onboarding.ts registriert FK-1 kundendaten (Bestätigungsblatt; Allgemein · Privat · Beruf und Praxis, Kinder nur Vorname + Geburtsmonat, Praxisfelder bedingt, Nachweis Personalausweis), FK-2 einwilligung_lastschrift und FK-2b sepa_mandat (Ausgabeart Textbaustein; Wortlaute nicht im Code, Freigabe-Status: Onboarding-Texte-Freigabe.md — ohne freigegebene Fassung nicht bestätigbar). Annahmen bis zur Klärung T-Q1/T-Q2: Adressen/Gläubiger-ID stehen im Text, Einzahl/Mehrzahl als fester Wortlaut; Niveau SES je Katalog (OP-SIGN-1). FK-3 ✅ gebaut (2026-10-16): apobank_edue (Fremdformular, Vordruck „EDU apoBank, Stand 06/2023“, 2 Seiten, 15 Felder): gesetzt werden nur die Kundenfelder fill_7 Name (Nachname, Vorname — abgeleitetes Attribut person.nachname_vorname), fill_8 Straße/Hausnummer, fill_9 PLZ, fill_11 Ort; nicht gesetzt: fill_6 Stammnummer (apoBank-Kundennummer, nicht in unseren Stammdaten), Block Vertriebspartner fill_19…25 (im Vordruck fest eingetragen), fill_29/30 Ort/Datum der Unterschrift, fill_32/33 Bankvermerke. Die PDF hinterlegt der Admin in der Verwaltung (Fremdformular-Vorlagen, Upload + Prüfung, ob das Mapping zu den Feldern passt); sie liegt nicht im Repo. Noch offen: apoBank-Stammnummer (Frage S9-9), FK-4 Vollmachten (Wortlaut fehlt), onboarding-public, Full-Stack-E2E. | mittel |
Reihenfolge-Empfehlung: S0 → S1 → S2 → S3 als tragender Strang (erster sichtbarer Nutzen: FK-1 Kundendaten online mit Delta). S5/S6 parallel nach S2. S9 erst, wenn #704 (Textfreigabe) geklärt ist.
Abweichung S2 (Entscheidung): Der Plan sah vor, FormularVorgang um die Status bestätigt/signiert zu erweitern. Der Code-Abgleich
zeigt, dass mehrere Konsumenten alle Vorgänge iterieren und je typ eine feste Konfiguration erwarten (SLA-Scan in
formular-vorgaenge-service.ts, Portal-Dashboard in portal-service.ts, Ausfüll-Dienst). Ein neuer typ oder Status würde dort
brechen. Deshalb ist der Katalog-Vorgang eine eigene Entität; Feld-Engine, Sichtungs-Muster und Signatur-Provider werden
wiederverwendet. Die Bestätigung verlangt die Pflichtangaben beider Rollen (Kunde und Berater), weil der Bestätigungstext den ganzen Katalog umfasst
(OB-F4) — das ist eine Annahme, die für Kataloge mit Beraterteil (z. B. Beratungsprotokoll) zu bestätigen ist.
Nicht geprüft: Repository-Schicht (server/src/repo/*) und Detail der bestehenden E2E-Tests.