Beratungsaufträge — das 3-Ebenen-Modell (MED-D-95, Katalog MED-D-99)

Kernaussage: Ein Lead/Kunde hat mehrere Beratungs-Produkte (Dentmarking-Gutachten, Versicherungsoptimierung, Praxisfinanzierung, Kapitalanlage, Investitionsberatung Erneuerbare Energien, Existenzgründung, Abrechnungsberatung, Praxisnachfolge, künftig Dexman-Controlling). Medidentas strukturiert das als 3 Ebenen: Person (ein Mandant, ein Lebenszyklus) → Beratungsauftrag (0..n je Mandant: EIN Produkt + eigener Status) → Artefakte (Beratungsdoku, Dokumente, Unterschriften, Wiedervorlagen, Gutachten). Damit ist der Review-Befund behoben, dass Dentmarking "zu weit vorne" saß (fest im Erstkontakt-Register verdrahtet) — es ist jetzt ein Produkt-Typ unter mehreren, nicht Bestandteil des Erstkontakts.

Zielgruppe: IT-Dev/Architektur · Business/Management. True North: Frage 1 ("Wo steht der Kunde?") wird je Auftrag beantwortbar — nicht nur je Person; Frage 2 (offen/fällig) bekommt in Slice B den Auftrags-Bezug.

✅ Kundenbestätigung (Meeting 12.07.2026, MED-D-108). Der Inhaber hat das 2-Ebenen-Bild in eigenen Worten bestätigt: erst Kunden-Onboarding (Person wird betreubar — Beratungsvertrag), dann darüber 0..n Beratungsprodukte (Dexman, Existenzgründung, Versicherungscheck, freier Auftrag …), je mit eigenem Lebenszyklus (Erstkontakt → Onboarding → Betreuung → Archivierung) und überspringbaren Prozessschritten; ein Auftrag wie Dexman läuft lange, eine Existenzgründung ist evtl. nach einem halben Jahr abgeschlossen. Die Betreuungsintensität (Ebene Person) heißt bewusst Intensiv/Standard/Basis (nicht A/B/C/Gold-Silber-Bronze — damit der Kunde beim Screensharing nicht brüskiert wird), gebaut als betreuungsmodell R1-F11/D-35. Action-Item: Dexman als Produkt in der Beratungsübersicht scharfschalten (Katalog vorhanden, heute verfuegbar:false). Protokoll: docs/fachlich/Anforderungen-Meeting-2026-07-12.md.

---

1. Problem (vorher)

• Dentmarking war Erstkontakt-Inventar: Betriebsdaten/Kennzahlen/Gutachten/Fragebogen-Links klebten als Toggle an der Praxis-Liste im Register "Erstkontakt" — als wäre jedes Mandat ein Dentmarking-Mandat. Versicherungsoptimierung, Finanzierung oder Geldanlage hatten gar keinen Ort.
• Eine einzige Prozessphase je Person kann nicht abbilden, dass ein Kunde gleichzeitig ein abgeschlossenes Gutachten, eine laufende Versicherungsoptimierung und eine angebahnte Finanzierung hat.

✅ Vollständig gelöst (MED-D-151, 0.83.0). Der zweite Punkt blieb nach Slice A/B bewusst bestehen, solange Mandant.prozessphase als dritte, mandantenweite Achse neben Lifecycle-Status und Auftrags-Status weiterlief (§4 unten beschrieb das als "Gliederung des Mandanten" — aber ein Mandant mit EINER Prozessphase konnte die oben beschriebene Mehrfach-Auftrag-Situation nie im Aktendeckel zeigen). PROZESS_PHASE ist jetzt retiriert: die grobe Achse ist lifecycleStatus (unverändert, personenweit), die feine Achse ist ausschließlich Beratungsauftrag.status — das Cockpit zeigt je Mandanten-Karte jetzt eine Auftrag-Status-Chip-Zusammenfassung, die genau diesen Fall abbildet. Siehe §4 (aktualisiert) und Prozessmodell.md §2/§3.

2. Zielbild: 3 Ebenen

• Ebene 1 Person: unverändert — EIN Mandant, EIN Lifecycle (lead→…→archiviert), Stammdaten, Praxen/Gesellschaften. Onboarding bleibt personenbezogen (Identität, Einwilligung, SEPA …) — diese Aussage steht auch nach MED-D-151 unverändert fest: der Lifecycle-Status (inkl. seiner onboarding-Stufe) ist und bleibt die Person-Achse. Was sich geändert hat, ist die fein-granulare Prozessphase (beratung/unterschrift/betreuung), die früher zusätzlich am Mandanten hing (prozessphase) — sie ist retiriert; ihre Rolle übernimmt vollständig der status je Beratungsauftrag unten (§4).
• Ebene 2 Beratungsauftrag (neu): je Mandant 0..n Aufträge. Jeder Auftrag trägt ein Produkt aus dem Katalog, optional einen Praxis-Bezug (nur bei praxisbezogenen Produkten) und einen eigenen Status: anbahnung → beratung → unterschrift → laufend → abgeschlossen (laufend nur für Dauer-Produkte; Einmal-Gutachten springen von unterschrift auf abgeschlossen). Begriff "Beratungsauftrag" bewusst statt "Mandat" (Verwechslungsgefahr mit "Mandant").
• Ebene 3 Artefakte: Beratungsdoku, Dokumente, Unterschriften, Wiedervorlagen, Gutachten gehören fachlich zu einem Auftrag. Die Verknüpfung (auftragRef) ist in Slice B gebaut (0.70.0, MED-D-101): Artefakte werden — bestehende bleiben ungebunden (nullable, keine Regression) — im Auftrags-Panel an einen Auftrag gebunden/gelöst; die Reife je Auftrag zeigt, was noch fehlt.

3. Produkt-Katalog (Slice A; vom Kunden bestätigt — MED-KB-7 ✅, MED-D-99)

Eine Definition je Produkt (G-8), Quelle server/src/domain/beratungsauftrag.ts — der Client rendert nur, was der Server liefert. Praxis-Bezug "optional" bedeutet: das Produkt kann sich auf die Person ODER eine Praxis/Gesellschaft beziehen (der Praxis-Bezug ist wählbar, nicht erzwungen).

Produkt	Praxis-Bezug	Dauer-Betreuung (laufend)	Buchbar
Dentmarking-Gutachten	optional	nein (Einmal-Gutachten)	✅
Versicherungsoptimierung	optional (Person oder Praxis)	nein	✅
Praxisfinanzierung	optional	nein	✅
Kapitalanlage	optional (Person oder Praxis)	ja	✅
Investitionsberatung Erneuerbare Energien	optional (Person oder Praxis)	nein	✅
Existenzgründung	optional	nein	✅
Abrechnungsberatung	optional	nein	✅
Praxisnachfolge	optional	nein	✅
Dexman-Controlling	optional	ja	⛔ vorbereitet (verfuegbar:false, Start mit R10/Dexman)

Modell-Hinweis (MED-D-99): Das Feld praxisbezogen heißt heute technisch "ist ein Praxis-Bezug erlaubt" (true = optional wählbar, false = kein Praxis-Bezug). Im aktuellen Katalog ist es überall true — es gibt kein reines Personen-Produkt mehr. Der Endpoint-Guard praxis_nicht_erlaubt (#132) bleibt als Absicherung für ein etwaiges künftiges reines Personen-Produkt bestehen (heute dormant). "Geldanlage" wurde zu "Kapitalanlage" umbenannt (Migration v37, bestehende Zeilen umgesetzt).

4. Abgrenzung der Achsen (ergänzt Prozessmodell.md, Tabelle aktualisiert MED-D-151)

| Prozessphase (Mandant/Arbeitssicht) | Person (Mandanten-Gliederung) | Erstkontakt · Onboarding · … | Retiriert (MED-D-151, 0.83.0). Es gibt nur noch zwei Prozess-Achsen — die dritte, mandantenweite Prozessphase ist vollständig abgelöst:

Achse	Gilt für	Beispielwerte
Lifecycle-Status (R1-F03)	Person	lead · onboarding · aktiv · ruhend · archiviert
Auftrags-Status (MED-D-95)	je Beratungsauftrag	in Anbahnung · in Beratung · zur Unterschrift · laufend betreut · abgeschlossen

Der Lifecycle-Status bleibt die Gliederung des Mandanten (Register = Lifecycle-Stufen, seit MED-D-151); der Auftrags-Status sagt, wo jedes einzelne Produkt steht. Ein aktiver Mandant kann gleichzeitig einen abgeschlossenen und zwei laufende Aufträge haben — und kann aktiv erreichen, unabhängig davon, in welchem Status seine einzelnen Aufträge gerade stehen (der Lifecycle-Guard prüft ausschließlich personenweite Fakten: Onboarding vollständig + keine offenen Unterschriften, nie den Auftrags-Status).

5. Umsetzung Slice A (gebaut, 0.68.0)

• Server: Entität beratungsauftrag (Migration v36, Index je Mandant), Katalog + Regeln rein in domain/beratungsauftrag.ts (erlaubteAuftragStatus), BeratungsauftragService (Anlage nur buchbarer Produkte, Praxis muss dem Mandanten gehören, Status mandant-scoped + produkt-validiert), Audit auftrag.angelegt/auftrag.status PII-arm (G-4/G-5). Routen: GET /api/auftrag-produkte, GET/POST /api/mandanten/:id/auftraege, POST …/auftraege/:auftragId/status.
• Client: neues Register "Beratungsaufträge" (quer-liegend, stufe: null seit MED-D-151 — wie Dokumente & Unterschriften) mit Panel akte-auftraege (Liste + Status-Wechsel + Anlage mit Produkt-/Praxis-Wahl); Dentmarking komplett dorthin umgezogen als eigenständiges Panel akte-dentmarking (Betriebsdaten · Kennzahlen · Gutachten/Befunde · Fragebogen-Links je Praxis) — das Erstkontakt-Register führt nur noch Lead-Quelle, Erstgespräch und Praxen-Stammdaten.
• Keine neue PII-Kategorie (Referenzen + Enum + interne Notiz, G-6); keine Retention-Änderung.

6. Fahrplan (MED-OP-AUFTRAG-1)

Slice	Inhalt	Status
A	Entität + Katalog + Register + Dentmarking-Umzug	✅ 0.68.0
B	auftragRef an Beratungsdoku/Dokumente/Wiedervorlagen/Gutachten (Migration v38, nullable); Auftrags-Reife ("was fehlt je Auftrag?", True North #2, schlanke Checkliste); Retro-Ableitung: bestehende Gutachten → je Praxis ein dentmarking_gutachten-Auftrag (Status abgeschlossen, idempotent)	✅ 0.70.0 (MED-D-101)
C1	Produkt-Playbooks (Schritt-Vorlagen je Produkt, analog Phasen-Playbook): beim Anlegen entstehen die Standard-Folgeaufgaben als Wiedervorlagen, an den Auftrag gebunden, idempotent	✅ 0.71.0 (MED-D-104)
C2a	Lead-Auto-Anlage: das öffentliche Lead-Formular fragt optionales Produkt-Interesse ab (nur buchbare Produkte); bei Einreichung entsteht je gewähltem Produkt direkt ein Auftrag (Status anbahnung, an die Lead-Praxis gebunden) samt Playbook (C1). Schließt den Kreis Lead → Auftrag → Folgeaufgaben	✅ 0.72.0 (MED-D-106)
C2b	Auftrags-Status-Playbook (Statuswechsel erzeugen Folge-Wiedervorlagen, nicht nur Anlage) + Cockpit-Kontext teil-gebaut: Auftrag-Status-Chip-Zusammenfassung je Mandanten-Karte (löst zugleich das in §1 beschriebene Mehrfach-Auftrag-Problem am Aktendeckel)	✅ 0.83.0 (MED-D-151)
C2b Rest / C3	Auftrags-Reife in der Leitstand-Sicht (nicht nur Status-Zähler) · Dexman-Produkt scharf (R10, eigener Tool-Host-Track)	⛔ offen

KB (erledigt): der Produkt-Katalog wurde mit dem Kunden bestätigt (MED-KB-7 ✅, MED-D-99, 0.69.0) — 9 Produkte inkl. Existenzgründung/Abrechnungsberatung/Praxisnachfolge/Investitionsberatung Erneuerbare Energien; Slices A + B sind darauf aufgebaut.