Dexman — Systementwurf (Anforderungsanalyse · Bedienkonzept · Architektur)

Kernaussage. Dexman beantwortet jede Frage des Praxisinhabers mit einem Satz, einer Zahl und einem nächsten Schritt — in formeller, betriebswirtschaftlicher Fachsprache (§11, MED-D-383). Der Anker für alles ist eine Größe, die jeder Inhaber sofort versteht: „Was muss meine Praxis je Arbeitstag erwirtschaften, damit alles bezahlt ist?" (die Tageslinie). Statt sieben Excel-Planungsblättern gibt es eine Zeitleiste mit Ereignissen (Einstellung, Darlehen, Investition …). Jede Änderung zeigt sofort ihre Wirkung auf Konto und Ergebnis, weil derselbe Rechenkern im Browser und auf dem Server läuft. Jede Zahl erklärt auf Antippen, woher sie kommt.

Status: Entwurf (MED-D-380, Issue #380) zur Spezifikation Dexman.md (v2, MED-D-372); Entscheidungen E-A…E-F am 2026-09-26 wie empfohlen bestätigt. Gebaut (MED-D-381, 0.151.0): Rechenkern, Planungsbausteine, Ist-Erfassung durch Medidentas, Hebel → Wiedervorlage und zwei Oberflächen — Kompass (dieser Entwurf) und Klassisch (§10); Monatsmeldung im Kundenportal (MED-D-700, §4.6) und Plausibilitäts-Hinweise (MED-D-699, §4.11) gebaut. Noch nicht gebaut: Excel-Import, Bank, PVS. Klickbarer Prototyp mit fiktiven Beispielzahlen: ../design/dexman/Dexman-Prototyp.html. Entscheidungen, die der Auftraggeber treffen muss, stehen gesammelt in §9.

Zielgruppen: Business/Management (§1–§3) · Anwender und Design (§4–§5) · IT-Architektur/Entwicklung (§6–§7) · CISO/Datenschutz (§6.6).

---

1. Anforderungsanalyse

1.1 Was der Auftraggeber tatsächlich will (belegt)

#	Aussage / Anforderung	Beleg
Q-1	„Eine Wahrheit": jede Information nur einmal erfassen, danach überall wiederverwenden	Workshop 2026-01-20, Z. 26
Q-2	Bedienbarkeit ist kritisch, „muss absolut zuverlässig laufen"	Workshop, Z. 27
Q-3	DexMan aus Excel in den Browser; Excel ist instabil („springende Ansichten, Datenverlust")	Workshop W8, Z. 41
Q-4	Kein Passwort-Login; Backoffice verschickt den Link aktiv, auch an das „Vorzimmer"	Meeting 12.07., M12
Q-5	Der Kunde pflegt die Leistungsstatistik selbst (Verantwortung/Datenherkunft beim Kunden); PVS-Anbindung erst später	Meeting 12.07., M13
Q-6	Oberflächen „absolut trivial", auch für ältere oder wenig IT-affine Menschen	MED-D-326
Q-7	Premium-Betrieb mit wenigen Kunden: Datenqualität vor Menge, nachsichtig mit Kundeneingaben	Meeting 12.07., Z. 22
Q-8	Dexman ist ein lang laufendes Beratungsmandat, kein einmaliges Gutachten	Beratungsauftraege.md, Z. 18–24

1.2 Wer Dexman benutzt und wofür (Jobs-to-be-done)

Person	Situation	Job	Häufigkeit
Praxisinhaber/in	zwischen zwei Patienten, oft am Smartphone	„Sag mir, ob meine Praxis läuft und ob ich mir X leisten kann."	wöchentlich, kurz
Vorzimmer / Praxismanagerin	Monatsanfang am Empfangs-PC	„Ich trage die Zahlen ein, ohne etwas falsch zu machen."	monatlich, 2–5 Min.
Berater/in (Medidentas)	Vorbereitung und Durchführung des Beratungsgesprächs, oft mit Bildschirmfreigabe	„Ich finde die Stellschraube, rechne Varianten live durch und halte fest, was vereinbart wurde."	monatlich/quartalsweise, 30–60 Min.
Behandler/in (angestellt)	optional, später	„Wie stehe ich im Vergleich zu meinem Ziel?" (nur eigene Zahlen)	quartalsweise
Admin (Medidentas)	Jahreswechsel	Steuer-/SV-Parameter und Benchmarks pflegen	jährlich

1.3 Was am Excel-Altbestand weh tut (und was wir daraus lernen)

Schmerz (Altbestand)	Ursache	Konsequenz im Entwurf
Datenverlust, springende Ansichten	VBA, Blattschutz, Dateikopien	Eingaben serverseitig, versioniert, append-only (G-4)
Sieben Planungsblätter × Monatsmatrix	Struktur folgt dem Rechenweg, nicht der Frage	drei Räume nach den drei Leitfragen (§4.1)
Personal, Darlehen, Inventar je eigenes Tool, per Import zusammengeführt	Werkzeuggrenzen	ein Planungsmodell, eine Zeitleiste (§4.3)
Nur der Ersteller versteht die Formeln	Logik in Zellen und VBA	„Woher kommt die Zahl?" an jeder Zahl (§4.5)
Klartext-PII in Dateien und Dateinamen	kein Datenschutz-Konzept	Import mit sichtbarem Scrubbing (§4.8), RISK-22
Rechenfehler unentdeckt (Dentmarking-Befund B-1)	keine Tests	Rechenkern mit Golden-Tests gegen die Beispieldaten (§6.2)

1.4 Widersprüche und Lücken in den Anforderungen — mit Vorschlag

ID	Befund	Vorschlag
W-1	Link-Gültigkeit: Meeting M12 nennt „1 Tag gültig, weiterleitbar an Vorzimmer"; das gebaute Portal nutzt 15-Minuten-Einmal-Token und persönliche Kontakt-Logins (MED-D-320, RISK-36).	Kein weiterleitbarer Link. Das Vorzimmer bekommt einen eigenen Portal-Kontakt (gebaut). Erfüllt den Wunsch („das Vorzimmer trägt ein") ohne geteilte Zugänge. Bestätigung nötig (E-A).
W-2	Datenquelle: DM-8/Glossar beschreiben Dexman als „aus Systemdaten"; Meeting M13 legt Phase 1 auf Selbstpflege.	Gelöst durch die Stufen in Spec v2 (DEX-1). Glossar-Text beim nächsten Anfassen angleichen.
W-3	Isolation: Der Tool-Host verlangt einen eigenen Persistenz-Namespace; Dexman soll aber in die Kerntabelle praxis_jahreswert schreiben (D-27).	praxis_jahreswert gilt als Kern-Faktenschicht (gehört dem Kern, Zugriff nur über den Kern-Service). Dexman-eigene Tabellen tragen das Präfix dexman_.
W-4	Benchmarks: Glossar/Spec nennen Personalkostenquote ≤ 35 %, die Dentmarking-Logik 25–33 %.	Ein versionierter Benchmark-Satz, gemeinsam mit Dentmarking (DM-3 ↔ DEX-7). Werte fachlich bestätigen (OP-DEX-3).
W-5	Priorität: Workshop „später", MVP-Scope „nach 1.0.0", Onboarding-Neubau lässt die Reihenfolge offen.	Unverändert „nach 1.0.0". Der Entwurf ändert keine Priorität. Bestätigung nötig (E-B).
W-6	VEM (Vermögensmanagement) ist nicht analysiert (OP-DEX-10).	Entwurf hält einen Platz dafür frei (Raum „Privat", §4.1); keine Fachlogik ohne Analyse.
W-7	Pauschalhonorar-Rentabilität (Meeting M5): Die Zeit läuft für die Rentabilität weiter; im Code nicht gebaut.	Betrifft die Medidentas-eigene Mandatsrentabilität, nicht die Praxis-Rentabilität. Außerhalb Dexman, eigenes Issue beim Bau.
W-8	Art.-9-Lese-Protokoll für Dexman nicht gebaut (Audit-Log.md).	Pflicht ab dem ersten Slice mit Behandler- oder Patientenbezug (X6/X7).
W-9	Veraltete Verweise: Lastenheft nennt nur OP-DEX-1…5, Dentmarking §11 nennt DEX-1…7.	In diesem PR angeglichen.
W-10	Beispieldaten: praxis.json nutzt die Einzeile plzOrt (verstößt gegen G-8).	In diesem PR auf plz/ort getrennt.

---

2. Leitidee

Drei Regeln tragen den Entwurf. Jede Regel hat eine ID, auf die sich Screens und Tests beziehen.

ID	Regel	Warum
P-1 Satz vor Grafik	Jeder Raum beginnt mit einem vollständigen Satz, der die Frage beantwortet. Grafik und Tabelle folgen als Beleg.	Inhaber lesen keine Diagramme zwischen zwei Patienten (Q-6).
P-2 Eine Bezugsgröße	Alle Kennzahlen werden, wo möglich, in € je Arbeitstag gegen die Tageslinie (Mindestumsatz ÷ Arbeitstage) ausgedrückt.	Prozentquoten erfordern Fachwissen; „Sie brauchen 4.440 € am Tag" nicht.
P-3 Ein Knopf	Jede Ansicht hat genau eine Hauptaktion; alles Weitere liegt unter „Mehr".	Setzt die UX-Maßnahme M-04 aus dem UX-Review 2026-09 fort.
P-4 Keine Zahl ohne Herkunft	Jede Zahl ist antippbar und zeigt Quelle, Stand und Rechenweg in einem Satz.	Vertrauen ersetzt Excel-Formeln-Prüfen (Q-3).
P-5 Ändern ist gefahrlos	Was-wäre-wenn ändert nichts, bis „Übernehmen" gedrückt wird; übernommene Änderungen sind versioniert und umkehrbar.	Angstfreies Ausprobieren im Beratungsgespräch.
P-6 Farbe ist nie allein	Status steht immer als Fachbegriff und Form (z. B. „Kostendeckend“ / „Liquiditätsengpass absehbar“ / „Über Richtwert“, §11), Farbe ergänzt nur.	Barrierefreiheit (M17), Bildschirmfreigabe beim Kunden.

3. Was Dexman damit anders macht (wegweisende Elemente)

ID	Element	Gegenüber Excel-Altbestand	Gegenüber MediPulse (belegt, §6 Spec v2)
N-1	Tageslinie als universeller Anker	Mindestumsatz stand versteckt auf Planung7	MediPulse zeigt Quoten und Plan-Ist, keinen Break-even je Tag
N-2	Antwort-Sätze aus festen Satzbausteinen (reproduzierbar, prüfbar, kein Sprachmodell nötig)	keine	Dashboards ohne Textaussage
N-3	Zeitleiste statt Planungsblätter	7 Blätter + 2 Zuliefer-Tools	kein mehrjähriges Planungsmodell belegt
N-4	Was-wäre-wenn in Echtzeit (Rechenkern im Browser)	Neuberechnung per Makro	nicht belegt
N-5	Hebel → Beratungsanlass mit einem Knopf, dokumentiert	keine Verbindung	eigenständiges Produkt ohne Beratungsprozess
N-6	Monatsmeldung in zwei Minuten über das Kundenportal	Datei hin und her	setzt PVS-Anbindung voraus

4. Bedienkonzept

4.1 Informationsarchitektur: drei Räume nach den drei Leitfragen

Raum	Kunde sieht	Berater sieht zusätzlich
Heute	Antwort-Satz, Tageslinie, Konto heute, Status je Bereich	Datenstand je Quelle, offene Sichtungen
Vorschau	24-Monats-Kontoverlauf, Jahresergebnis, Satz „reicht bis …"	Szenarien, Zeitleiste bearbeiten, Monatsmatrix
Hebel	bis zu drei Hebel mit €-Wirkung, „Mit Berater besprechen"	alle Hebel, Annahmen, „Als Beratungsanlass anlegen"
Privat (später, VEM)	Privatentnahmen, Steuer, Vermögen	—

Einstieg: In der Kunde (Kunden-Cockpit) erscheint eine Dexman-Kachel mit Antwort-Satz und Status. Ein Klick öffnet Dexman als Overlay (bestehende Overlay-Shell), nicht als neue Anwendung. Im Kundenportal ist Dexman ein eigener Bereich neben der To-do-Liste; die Monatsmeldung erscheint als Aufgabe in der To-do-Liste.

4.2 Raum „Heute" — die Tageslinie

┌──────────────────────────────────────────────────────────────┐
│ Heute · Zahnarztpraxis Beispiel · Stand 31.08.2026 (gemeldet)│
│                                                              │
│  Ihre Praxis arbeitet kostendeckend.                         │
│  Sie braucht 4.440 € je Arbeitstag, um alles zu bezahlen.    │
│  Im August lagen Sie bei 3.000 € (Ferienmonat).              │
│                                                              │
│  ─────────●─────────────|───●─────────  Tageslinie 4.440 €   │
│         3.000         4.440  Ø Jahr 4.640                    │
│                                                              │
│  Konto heute  12.000 €   Jahresergebnis (Plan)  269.600 €    │
│  [Im Richtwert] Personal [Liquiditätsengpass absehbar] 08/27 │
│                                                              │
│  [ Vorschau ansehen ]                                        │
└──────────────────────────────────────────────────────────────┘

• Bezugszeitraum (MED-D-681): Mindestumsatz, Durchschnitt, Status "kostendeckend" und Kennzahlen beziehen sich auf die nächsten 12 Monate ab heute (rollierend, z. B. "Okt 26 – Sep 27"), nicht auf das Kalenderjahr — sonst kann ein starkes Jahr bis September "kostendeckend" melden, während Kosten des Folgejahres schon einen Liquiditätsengpass erzeugen. Liegt ein Engpass im Planungszeitraum, nennt ihn der Kopfsatz zusätzlich ("Nach aktueller Planung reicht die Liquidität ab … nicht aus.").
• Tageslinie = (Praxisausgaben + Tilgung + Privatbedarf) ÷ Arbeitstage des Jahres (DEX-11, Parameter Arbeitstage je Praxis). Abgeleitet, nie gespeichert (G-2).
• Status-Begriffe (fest, G-3): je Bereich ein eigener Fachbegriff, z. B. Kostendeckend · Knapp kostendeckend · Unterdeckung bzw. Liquidität gesichert · Liquiditätsengpass absehbar · Liquiditätsengpass (vollständige Liste §11). Schwellen sind Stammdaten; Default: knapp kostendeckend, wenn der Durchschnitt weniger als 5 % über der Tageslinie liegt.

4.3 Raum „Vorschau" — Zeitleiste und Was-wäre-wenn

• Oben der Antwort-Satz („Mit der geplanten ZFA ab Januar 2027 wird das Konto im August 2027 knapp und liegt im September 2028 bei −10.600 €.").
• Darunter der Kontoverlauf (24 Monate, eine Linie, Nulllinie betont, tiefster Punkt beschriftet).
• Darunter die Zeitleiste: jedes Ereignis ist eine Marke auf der Monatsachse.

Ereignis-Typ	Quelle im Fachmodell	Beispiel
Person kommt / geht / Gehalt ändert sich	DEX-8	„ZFA (neu) ab 01/2027, 2.900 € brutto"
Darlehen beginnt / Zinsbindung endet / Sondertilgung	DEX-9	„Zinsbindung Praxisdarlehen endet 03/2027"
Anschaffung / Reinvestition	DEX-12	„Behandlungseinheit 3, 45.000 €, 06/2027"
Steuer-Nachzahlung / Vorauszahlung	DEX-10	„ESt-Nachzahlung 02/2027 (Schätzung)"
Einmaliger Umsatz / Ausfall	DEX-10	„Praxisurlaub 08/2027, 3 Wochen"

• Was-wäre-wenn: Ein Ereignis wird per Ziehen verschoben oder über Regler geändert; Kurve und Satz folgen ohne Wartezeit. Nichts wird gespeichert, bis „Übernehmen" gedrückt wird (P-5). Übernommen wird als neue Version (VersionedField-Muster, Quelle berater oder portal).
• Meilensteine (MED-D-682): einmalige Zahlungen — einmalige Ausgaben/Einnahmen, Anschaffungen aus dem Konto, Schlussrate eines Darlehens — erscheinen als Raute auf der Kontokurve (Kompass und Klassisch); Mouse-over bzw. Tastaturfokus zeigt Monat, Bezeichnung, Betrag und Art. Mehrere Ereignisse im selben Monat werden zu einer Marke zusammengefasst.
• Vergleichsmodus: Beim Ändern bleibt die alte Kurve als gestrichelte Linie stehen; der Satz nennt den Unterschied in € („+11.700 € am tiefsten Punkt").

4.4 Raum „Hebel"

Jeder Hebel ist eine Karte mit denselben vier Zeilen:

Zeile	Beispiel
Was	„Neue ZFA erst ab April statt Januar einstellen"
Wirkung	„+11.700 € Kontostand am tiefsten Punkt" (aus dem Rechenkern, nicht geschätzt)
Annahme	„Arbeit wird bis April mit bestehendem Team getragen"
Schritt	Mit Berater besprechen (Kunde) · Als Beratungsanlass anlegen (Berater → R5/R6)

Hebel entstehen regelbasiert (DEX-6). Ein Hebel mit geschätzter Wirkung (z. B. HKP-Abschlussquote) trägt sichtbar den Hinweis „Schätzung" und die Annahme (wie Dentmarking §10 für das Mehrgewinn-Potential).

4.5 „Woher kommt die Zahl?"

Antippen einer Zahl öffnet eine kleine Erklärung (kein neuer Screen):

4.440 € je Arbeitstag = 888.400 € Jahresbedarf ÷ 200 Arbeitstage. Jahresbedarf = Praxisausgaben 618.400 € + Tilgung 48.000 € + Privatbedarf 222.000 €. Quellen: Personal (Planung, Stand 12.09.2026) · Darlehen (Planung) · Leistung August (gemeldet 03.09., geprüft). Parameter: Steuer/SV 2026 (Version 2026.1).

Technisch ist das die Lineage aus DEX-1 (Quelle, Formel, Periode, Parameter-Version).

4.6 Monatsmeldung im Kundenportal

• Ein Bildschirm, eine Frage: „Wie viel Umsatz hat jede Behandlerin im August erbracht?"
• Vorbelegt mit dem Vormonat; ein Knopf „Wie im Vormonat" je Zeile.
• Hinweis bei Abweichung > 30 % zum Vormonat: „Deutlich weniger als im Juli. Stimmt das?" (weich, G-3).
• Ziel: unter zwei Minuten für eine Praxis mit bis zu fünf Behandlern.

Gebaut (MED-D-700, Issue #700) — Abweichungen vom Entwurf:

• Die Aufgabe "Umsätze melden — " erscheint im Portal (nicht per Mail), solange das Dexman-Mandat laufend ist, der Vormonat nicht eingereicht ist und der Berater die Werte nicht schon selbst erfasst hat.
• Der Berater sichtet in Dexman, Reiter Ist-Umsätze: Annehmen schreibt den Wert sofort mit Quelle portal in die Faktentabelle; Ablehnen verlangt einen Grund. Sind alle Werte entschieden und einer abgelehnt, geht die Meldung in die Korrektur (Feedback-Mail, nur die abgelehnten Zeilen sind im Portal offen).
• Kein Push (§6, Live-Push folgt): die Ansicht aktualisiert sich beim nächsten Laden.
• Personaländerungen (DEX-1a) meldet die Praxis noch nicht über das Portal; der Berater pflegt sie.
• Speicherung als FormularVorgang vom Typ dexman_monat (keine eigene Tabelle); Audit ohne Beträge und Namen.

4.7 Beratungsmodus (Bildschirmfreigabe)

Ein Schalter blendet Behandler-Namen aus (Initialen) und zeigt Beträge gerundet auf 100 €. Grund: Im Gespräch wird der Bildschirm oft geteilt (Meeting 12.07., Z. 48). Der Schalter ist an der Kopfzeile, nicht in Einstellungen.

Umsetzung (MED-D-736, Issue #736): gerundet wird nur die Darstellung, nie die Rechnung. DexmanEingabe.anzeigeRaster (Beratungsmodus = 100) steuert, wie genau die vom Rechenkern erzeugten Texte — Kennzahl-Herkunft, Sätze, Empfehlungen, Plausibilitäts-Hinweise — Beträge nennen; die Oberfläche formatiert ihre Beträge über denselben Raster (DexmanDaten.eur). Ein feineres Raster einer Aufrufstelle wird dabei nie verfeinert, nur gröber gemacht (anzeigeFormat). Nicht gerundet werden Eingabefelder (der erfasste Wert bleibt auf den Euro genau) und der Monatsbericht (MED-D-684): er ist ein eingefrorener Beleg und wird serverseitig ohne Raster erzeugt.

4.8 Excel-Übernahme (DEX-13)

Drei Schritte in der bestehenden Overlay-Shell: Datei wählen → Vorschau prüfen → Übernehmen. Die Vorschau zeigt ausdrücklich, was nicht übernommen wird („IBAN, Darlehensnummern, Freitexte mit Ortsangaben") — das Scrubbing ist sichtbar, nicht versteckt (G-6, RISK-22). Wiederholter Import derselben Datei ändert nichts (idempotent).

4.9 Visuelle Sprache

• Bestehendes Design-System (Kunden-Cockpit, client/src/styles.css): Tokens --bg, --card, --text, --accent, --red/--amber/--green; Zahlen in Space Grotesk (.mw-num); Overlay-Shell; Mindestgrößen nach MED-D-335 (Text ≥ 16 px, Ziele ≥ 44 px). Kein neues Button-System.
• Diagramme als eigene SVG-Komponenten (heute gibt es keine Diagramm-Bibliothek im Client): Kontoverlauf (Linie + Fläche, Nulllinie), Tageslinie (Skala mit Marke), Zeitleiste (Monatsachse mit Marken).
• Kundenseiten im hellen Modus (UX-Maßnahme M-06); Berater-Sicht folgt dem Theme.

4.10 Messbare UX-Ziele

ID	Ziel	Messung
U-1	Antwort auf L1 ohne Klick	Satz + Tageslinie im ersten Bildschirm (Smartphone 390 px)
U-2	Monatsmeldung < 2 Min.	Nutzertest mit 3 Praxen (UX-Maßnahme M-08)
U-3	Keine Fachbegriffe ohne Erklärung	Jeder Fachbegriff hat eine Glossar-Sprechblase
U-4	Eine Hauptaktion je Ansicht	Review-Checkliste je Screen
U-5	Was-wäre-wenn reagiert in < 100 ms	Rechenkern-Benchmark im Browser (24 Monate × 7 Jahre)
U-6	Jede Zahl hat eine Herkunft	Test: jede angezeigte Kennzahl liefert Lineage

4.11 Plausibilitäts-Hinweise (MED-D-699)

Dexman prüft die Planung auf Eingaben, die rechnerisch zulässig, fachlich aber vermutlich falsch sind, und zeigt sie über beiden Oberflächen im Kasten "Bitte prüfen Sie die Planung". Die Hinweise blockieren nichts.

Prüfung	Hinweis (Beispiel)
Annuitätenrate ≤ Monatszins auf die Restschuld	Darlehen "Praxisdarlehen": Die Rate von 10.000 € deckt die Zinsen von 12.500 € im Monat nicht; das Darlehen wird nicht getilgt.
Ist-Umsätze vor dem Eintritt bzw. nach dem Austritt	L. M.: Für 2 Monate ab Mai 2026 sind Ist-Umsätze vor dem Eintritt (Oktober 2026) erfasst.
Behandler mit Ist-Umsätzen, Planumsatz 0 €	Dr. A. B.: Es liegen Ist-Umsätze vor, der geplante Monatsumsatz beträgt aber 0 €.

Fallende Tilgung und tilgungsfreie Darlehen sind von der ersten Prüfung ausgenommen. Im Beratungsmodus stehen Initialen statt Namen. Anlass: Testpraxis aus R-28 (#681), die "kostendeckend" und einen Engpass zugleich zeigte.

5. Rollen und Sichtbarkeit im Bedienkonzept

Ansicht	Inhaber	Vorzimmer (Portal-Kontakt)	Berater	Behandler
Heute / Vorschau / Hebel	✅	— (Default)	✅	—
Monatsmeldung	✅	✅	✅ sichten	—
Zeitleiste bearbeiten	Vorschlag einreichen	—	✅	—
Behandler-Vergleich	✅ nach OP-DEX-4	—	✅ nach OP-DEX-4	nur eigene Zahlen
Details (Matrix, Parameter, Import)	—	—	✅	—

„Vorschlag einreichen" nutzt die bestehende 4-Augen-Einreichung des Portals (MED-D-304): Der Inhaber kann z. B. eine geplante Einstellung eintragen; der Berater übernimmt sie in die Planung.

---

6. Architektur

6.1 Überblick

6.2 Rechenkern (Kernentscheidung)

• Eine reine Funktion: rechne(eingaben, parameter, fakten, szenario?) → ergebnis. Keine I/O, keine Uhrzeit, keine Zufallswerte; gleiche Eingaben liefern gleiche Ergebnisse.
• Ein Modul, zwei Laufzeiten: Derselbe TypeScript-Code läuft im Worker (verbindlich: Bericht, Hebel, Kachel) und im Browser (Was-wäre-wenn ohne Server-Rundreise, U-5). Heute teilen Client und Server keinen Code. Vorschlag: ein abhängigkeitsfreies Modul shared/dexman-kern/, das beide Builds einbinden. Entscheidung nötig (E-C).
• Golden-Tests gegen die anonymisierten Beispieldaten (Anhang B) und nachgerechnete Excel-Ergebnisse; verhindert Fehler wie Dentmarking B-1.
• Ergebnis enthält je Zahl die Lineage (Quelle, Formel-ID, Periode, Parameter-Version) → speist P-4.
• Satzbausteine (N-2) sind Teil des Kerns: saetze(ergebnis) → Satz[], deterministisch, getestet. Ein Sprachmodell (In-App-Assistent) kann später Fragen beantworten, erzeugt aber keine Kennzahlen.

6.3 Was gespeichert wird und was nicht (G-2)

Gespeichert (Eingabe)	Abgeleitet (nie gespeichert)
Planungs-Bausteine: Person, Darlehen, Anlage, Einmal-Ereignis — je mit Zeitraum und Versionen	Monatsmatrix, Kontoverlauf, Jahresergebnis
Fakten (praxis_jahreswert: Leistung, Kosten je Periode und Quelle)	Kennzahlen, Tageslinie, Status-Wörter
Parameter je Gültigkeitsjahr (Steuer/SV), Benchmarks (versioniert)	Hebel und deren Wirkung
Szenario nur, wenn benannt gespeichert (optional)	Antwort-Sätze
Monatsbericht als eingefrorener Beleg in R2 (wie Dentmarking-Gutachten)	—

6.4 Datenmodell (Vorschlag, ergänzt Spec v2 §7)

• dexman_baustein: id, praxis_id, art (person · darlehen · anlage · ereignis), status (aktiv · archiviert).
• dexman_baustein_version: baustein_id, version, gueltig_ab (JJJJ-MM), gueltig_bis?, daten (JSON, Schema je art im Weltmodell, G-8), quelle (berater · portal · excel_import), angelegt_am, angelegt_von. Nie überschrieben; die jüngste Version gilt.
• Die Zeitleiste ist eine Sicht auf die Bausteine (Beginn, Ende, Änderungen) — keine eigene Tabelle.
• darlehen.zweck = geschaeftlich · privat · vermietet; privat hängt am Kunden (Inhaber), nicht an der Praxis (DEX-9, OP-DEX-8).

6.5 API

Stand: gebaut (server/src/api/app.ts, Abschnitt Dexman). Excel-Übernahme (DEX-13) ist noch nicht gebaut und steht deshalb nicht in der Tabelle.

Methode	Route	Zweck
GET	/api/dexman/praxen/:id/stand	alle Bausteine + Ist-Werte + Parameter einer Praxis (Eingabe für den Browser-Kern; protokollierter Lesezugriff, D-50)
GET	/api/dexman/praxen/:id/lage	Heute: Ergebnis-Auszug + Sätze + Empfehlungen (verbindliche Server-Rechnung)
POST	/api/dexman/praxen/:id/bausteine	Baustein anlegen (Version 1)
POST	/api/dexman/bausteine/:id/versionen	Änderung übernehmen (neue Version)
POST	/api/dexman/bausteine/:id/archivieren	Baustein archivieren (nie löschen)
PUT	/api/dexman/praxen/:id/ist/:monat	Ist-Umsätze je Behandler für einen Monat erfassen (§10.8)
POST · GET	/api/dexman/praxen/:id/festschreiben · …/festschreibung	abgeschlossene Monate sperren / Stand lesen (§10.8)
POST	/api/dexman/praxen/:id/festschreibung/aufheben	Festschreibung aufheben (nur Administration, auditiert)
POST	/api/dexman/praxen/:id/hebel/:hebelId/anlass	Empfehlung → Wiedervorlage/Beratungsanlass
POST	/api/dexman/praxen/:id/hebel/:hebelId/vorschlag	Empfehlung → Vorschlag an die Beratungsdokumentation (§10.9)
POST	/api/dexman/praxen/:id/monatsbericht/:monat	Monatsbericht als eingefrorenen PDF-Beleg ablegen (DEX-5, §10.6)
GET	/api/dexman/praxen/:id/meldungen	Monatsmeldungen der Praxis aus dem Kundenportal (DEX-1a)
POST	/api/dexman/praxen/:id/meldungen/:token/sichtung	Monatsmeldung sichten: je Feld annehmen / mit Grund ablehnen (MED-D-89)
GET	/api/mandanten/:id/dexman-kacheln	Kacheln für die Kunde (DEX-5, §10.10)
GET	/api/mandanten/:id/beratungsvorschlaege · POST /api/beratungsvorschlaege/:id/{uebernehmen,verwerfen,umgesetzt}	Vorschläge an die Beratungsdoku lesen / entscheiden (§10.9)
GET · POST	/oeffentlich/portal/dexman/:praxisId/:monat	Monatsmeldung des Kunden im Portal (Portal-Session, eigener Kunde; Einreichung + Sichtung MED-D-89/304)

Alle Routen hinter Cloudflare Access (Staff) bzw. Portal-Session (Kunde), RBAC je Request (R7), jede schreibende Aktion als PII-armes Audit-Event (G-4).

6.6 Datenschutz und Sicherheit im Entwurf

Thema	Entwurfsentscheidung
Personaldaten (Gehalt, Steuerklasse, KV)	nur Berater und Inhaber; Portal-Kontakte sehen sie nicht; Lese-Protokoll (D-50)
Behandler-Leistung	Vergleichsansichten erst nach OP-DEX-4 (RISK-11); Beratungsmodus blendet Namen aus
Privatdaten des Inhabers (Steuer, Privatentnahmen, private Darlehen)	eigener Bereich, nur Inhaber + Berater; keine Steuer-ID (MED-D-284)
Browser-Rechenkern	erhält nur die Eingaben der geöffneten Praxis; nichts wird im Browser-Speicher abgelegt
Monatsbericht	eingefroren in R2, EU-Residenz; Aufbewahrung nach Mandats-Retention
Satzbausteine statt Sprachmodell	keine Praxiszahlen an externe Dienste

6.7 Echtzeit

Nach Sichtung einer Monatsmeldung oder einer Planänderung erhalten geöffnete Ansichten ein daten-loses Push-Signal (Muster MED-D-275) und laden neu. Das erfüllt den Standard-Baustein „Echtzeit" ohne neue Infrastruktur.

---

7. Umsetzung (bezogen auf die Slices der Spec v2)

Slice (Spec v2 §9)	Was aus diesem Entwurf	Prüfbar an
X1 Fundament	Rechenkern-Modul + Golden-Tests · Bausteine Person · Dexman-Kachel · Portal-Monatsmeldung	U-2, U-6
X2 Vorschau	Räume Heute + Vorschau · Tageslinie · Kontoverlauf · Satzbausteine · Was-wäre-wenn	U-1, U-5
X3 Darlehen & Anlagen	Bausteine Darlehen/Anlage auf der Zeitleiste	Golden-Tests Darlehen
X4 Excel-Import	Übernahme-Assistent mit sichtbarem Scrubbing	Idempotenz-Test
X5–X8	Hebel-Raum, Bank, Behandler, PVS (nach Gates)	je Spec v2

Jeder Slice liefert Vitest (Kern/API), gemockte E2E (Räume) und — ab X1 — eine Full-Stack-E2E „Monatsmeldung → Sichtung → Heute aktualisiert".

8. Prototyp

../design/dexman/Dexman-Prototyp.html zeigt die drei Räume, die Tageslinie, den Kontoverlauf mit Was-wäre-wenn (ZFA-Beginn, Umsatz, Privatentnahme), die Hebel-Karten, „Woher kommt die Zahl?" und die Monatsmeldung. Alle Zahlen sind fiktiv und dienen nur der Anschauung; der Prototyp nutzt ein vereinfachtes Rechenmodell, nicht den späteren Rechenkern.

9. Entscheidungen für den Auftraggeber

Alle sechs am 2026-09-26 wie empfohlen bestätigt (MED-D-381).

ID	Frage	Empfehlung = Entscheidung
E-A	Vorzimmer: eigener Portal-Kontakt statt weiterleitbarem 1-Tages-Link (W-1)?	eigener Kontakt
E-B	Bleibt Dexman „nach 1.0.0" (W-5)?	ja, unverändert
E-C	Gemeinsames Modul shared/dexman-kern/ für Client und Server?	ja
E-D	Tageslinie (N-1) als zentrale Bezugsgröße für Kunden?	ja, im Nutzertest prüfen
E-E	Beratungsmodus (Namen ausblenden) standardmäßig an bei Bildschirmfreigabe?	nein, ein Schalter genügt
E-F	Benchmark-Werte: ein gemeinsamer Satz mit Dentmarking (W-4)?	ja

10. Variante B — „Klassisch" (Alternative zum Kompass, MED-D-381)

Kernaussage. Nicht jede Nutzerin will in Sätzen geführt werden. Wer seit Jahren mit dem DexMan-Excel arbeitet, erwartet Tabellen, Kennzahlen-Kacheln und eine Monatsmatrix. „Klassisch" liefert genau das — über dieselben Daten, denselben Rechenkern und dieselbe Versionierung wie der Kompass. Ein Schalter oben im Dexman-Fenster wechselt die Oberfläche; die Wahl merkt sich der Browser.

10.1 Wann welche Oberfläche

Situation	Kompass	Klassisch
Inhaber/in will wissen „läuft es?"	✅ ein Satz, eine Zahl	Kacheln lesen
Beratungsgespräch mit Bildschirmfreigabe	✅ Räume, Was-wäre-wenn, Beratungsmodus	Beratungsmodus ebenfalls
Berater/in pflegt viele Positionen am Stück	Zeitleiste, Formular je Ereignis	✅ Tabelle je Bereich
Abgleich mit dem Excel-Altbestand / BWA	—	✅ Monats- und Jahresübersicht
Umsteiger aus DexMan-Excel	Umgewöhnung nötig	✅ vertraute Struktur

10.2 Aufbau

Reiter	Inhalt	Entspricht im Excel-Altbestand
Übersicht	Umsatz, Mindestumsatz je Arbeitstag, Betriebsergebnis, Personal-/Material-/Finanzierungsquote, Konto heute, tiefster Kontostand; Kontoverlauf; Empfehlungen als Tabelle	Planung-Kopf, Kostenstruktur
Personal	Tabelle mit Rolle, Status, Brutto, Plan-Umsatz, Ein-/Austritt, Version; Summenzeile	Personal / Personal Manager
Darlehen	Restschuld heute, Zins, Zinsbindung, Tilgungsform, Rate, Ende	Darlehen / Darlehensübersicht
Anschaffungen	Wert, Nutzungsdauer, AfA/Jahr, Zahlungsweg	Inventar
Posten	Einmalige und befristete Einnahmen/Ausgaben, Umsatzänderungen	Einzelzeilen der Planung
Ist-Umsätze	Monatsumsatz je Behandler (gleiches Formular wie im Kompass)	Leistung
Monate	16 Positionen × 12 Monate, Summen, Ist-Monate markiert, Negativwerte nur in Saldo/Kontostand/Ergebnis rot	Planung0…7 Monatsmatrix
Jahre	Jahresergebnis, Umsatzrendite, Tilgung, Anschaffungen, Privat, Liquidität; Mindestumsatz	Planung7, Ausgaben
Parameter	Praxis-Parameter inkl. laufender Kosten und Saison	settings, Kopfdaten

10.3 Gemeinsame Regeln beider Varianten

• Ein Formular für jeden Baustein (md-dexman-baustein-form), gleiche Prüfregeln wie der Server (G-8).
• Speichern = neue Version, Archivieren statt Löschen (kunden-patterns §1); archivieren nur im Formular, nicht in der Tabellenzeile (eine Hauptaktion je Zeile).
• Status als Wort + Form (P-6): Kacheln tragen einen Farbstreifen und das Statuswort.
• Beratungsmodus gilt in beiden Varianten.
• Kein zweites Rechenmodell: beide Oberflächen lesen rechne() aus shared/dexman-kern/.

10.4 Umsetzung (Stand 0.151.0)

Teil	Datei
Rechenkern (Worker + Browser)	shared/dexman-kern/ (rechne, findeHebel, Sätze, Prüfung, Beispielpraxis)
Persistenz	dexman_baustein, dexman_baustein_version (Migration v63, server/src/repo/dexman-repo.ts); Lohnnebenkosten-Parameter lnk_parameter (append-only, Migration v72, MED-D-709); Ist-Umsätze in praxis_jahreswert (dexman.umsatz.<personId>, Quelle berater)
API	/api/dexman/praxen/:id/{stand,lage,bausteine,ist/:monat,hebel/:hebelId/anlass,monatsbericht/:monat,festschreiben,festschreibung,festschreibung/aufheben}, /api/dexman/bausteine/:id/{versionen,archivieren}, /api/lnk-parameter (GET alle Rollen, POST nur admin; Verwaltung → "Lohnnebenkosten-Parameter")
Monatsbericht (DEX-5)	server/src/domain/dexman-monatsbericht.ts (Blockmodell → PDF + Markdown), Ablage + Dokument-Referenz in server/src/api/dexman-service.ts
Personal als Person + Spannen	shared/dexman-kern/person.ts (Spannen-Logik + Read-Fallback), Spannen-Tabelle in client/src/app/dexman-baustein-form.component.ts
Festschreibung der Ist-Monate	dexman_festschreibung (Migration v69, server/src/repo/dexman-repo.ts), Guard + Aktionen in dexman-service.ts, Fähigkeit dexman_festschreibung_aufheben in server/src/domain/rechte.ts
Oberflächen	client/src/app/dexman*.ts — Einstieg „Dexman" je Praxis im Reiter Praxen, Deep-Link /dexman/:praxisId
Tests	Vitest dexman-kern.test.ts · dexman-monatsbericht.test.ts · dexman.test.ts; E2E gemockt e2e/dexman.spec.ts; Full-Stack e2e-fullstack/dexman-flow.spec.ts (Zahlen: Test-Uebersicht.md)

Bewusste Vereinfachungen (dokumentiert, nicht versteckt): Arbeitgeberkosten als pauschaler Aufschlag statt Lohnsteuer-/SV-Rechnung (OP-DEX-9; spart zugleich Steuerklasse/KV-Daten, G-6) — aufgehoben (MED-D-709 Slice 4): Einzelberechnung je Mitarbeiter und Monat inkl. Jahresgrenzen, Parameter in der Verwaltung (Modell: Data Dictionary §3.2b); die Pauschale gilt nur noch als Rückfall, wenn keine Parameter vorliegen oder für einen Monat ein Wert fehlt · Umsatzbeteiligung = Satz auf den Monatsumsatz oberhalb der Schwelle (vorläufige Lesart OP-DEX-6) · Ein-/Austritt in vollen Monaten (OP-DEX-7) · keine Einkommensteuer-Schätzung; Steuerzahlungen als private Posten · Ist-Werte im Kalendermonat.

10.5 Regel-Katalog der Handlungsempfehlungen (DEX-6, MED-D-683)

Kernaussage. Die Empfehlungen sind regelbasiert und nachvollziehbar — kein Sprachmodell, keine Blackbox. Jede Regel nennt Auslöser, Schwelle und Datengrundlage; ihre Auswirkung ist entweder mit demselben Rechenkern nachgerechnet (Szenario) oder eine als Schätzwert gekennzeichnete Überschlagsrechnung. Quelle ist HEBEL_KATALOG in shared/dexman-kern/hebel.ts; diese Tabelle spiegelt ihn, und scripts/check-doc-consistency.sh (Check 10) prüft beide Richtungen mechanisch (G-2).

Gebaut — Mindestwirkung je Regel 1.000 € (unterhalb wird nicht vorgeschlagen), Sortierung absteigend nach Euro-Wirkung:

Regel	Empfehlung	Auslöser	Auswirkung	Datengrundlage
person-spaeter	Geplante Einstellung später beginnen	Liquiditätsengpass + Eintritt in der Zukunft	nachgerechnet (3 Monate später)	Planung: Personal
anlage-spaeter	Geplante Anschaffung später tätigen	Liquiditätsengpass + aus dem Konto bezahlter Zugang in der Zukunft	nachgerechnet (6 Monate später)	Planung: Anschaffungen
privat-1000	Privatentnahmen reduzieren	Liquiditätsengpass + Entnahme ≥ 2.000 €/Monat	nachgerechnet (−1.000 €/Monat)	Praxis-Parameter
zinsbindung	Anschlussfinanzierung frühzeitig anfragen	Zinsbindung endet in ≤ 18 Monaten	Zinsaufwand je Prozentpunkt p. a.	Planung: Darlehen
darlehen-endfaellig	Fällige Restschuld zum Laufzeitende vorbereiten	Laufzeitende im Planungszeitraum mit Restschuld	fällige Restschuld	Planung: Darlehen
kontokorrent	Kontokorrent-Inanspruchnahme umschulden	Kontokorrentzinsen im Planungszeitraum über dem günstigsten vorhandenen Darlehenszins	Schätzwert (Zinsdifferenz)	Praxis-Parameter · Darlehen · Kontoverlauf
personalquote	Personaleinsatz und Dienstplanung überprüfen	Personalkostenquote über Richtwert	Schätzwert (Entlastung p. a.)	Personal · Benchmark-Satz (E-F)
umsatz-luecke	Deckungslücke zum Mindestumsatz schließen	Durchschnittsumsatz je Arbeitstag unter dem Mindestumsatz	Schätzwert (Lücke p. a.)	Ist-Umsätze · gesamte Kostenstruktur

Geplant — bewusst nicht als Attrappe gebaut: erst die Datenquelle bzw. der Richtwert, dann die Regel.

Regel	Empfehlung	Wartet auf
materialquote	Material- und Laborkosten überprüfen	Richtwert fachlich offen — die Dentmarking-Kennzahl 4.1 misst Materialkosten ÷ Gesamtkosten (OP-DM-1 Frage 3), nicht die Dexman-Quote je Umsatz-Euro (W-4)
budget	KZV-Budgetausschöpfung steuern	DEX-18 (PVS-Konnektor)
hkp-conversion	Liegengebliebene Heil- und Kostenpläne nachfassen	DEX-18 (PVS-Konnektor)
recall	Abwesende Patienten reaktivieren	DEX-15 (Patientenstamm-Analytik)
abrechnungsluecke	Abrechnungslücken schließen	DEX-17 (Leistungsziffern-Analyse)

Nicht in dieser Liste: die Datenpflege-Erinnerung („Monatszahlen anfordern", „Ist-Umsätze erfassen", „Monatsbericht besprechen"). Sie entsteht aus dem laufenden Dexman-Mandat als Wiedervorlage je Monat (MED-D-652, server/src/domain/dexman-monatsaufgaben.ts) — zwei Quellen für dieselbe Aufgabe wären eine Dublette (G-2).

Vom Vorschlag zur Maßnahme: „Wiedervorlage anlegen" je Empfehlung erzeugt eine Wiedervorlage (quelle=befund, fällig in 7 Tagen, idempotent je Praxis × Regel) — vorschlagend, nicht ausführend.

10.6 Monatsbericht als eingefrorener Beleg (DEX-5, MED-D-684)

Kernaussage. Der Monatsbericht macht das Beratungsgespräch nachweisbar: ein Knopf im Dexman-Fenster erzeugt aus der verbindlichen Server-Lage einen PDF-Beleg, legt ihn in der geschlossenen Ablage ab und führt ihn als Dokument im Kunden-Detail — eingefroren wie das Dentmarking-Gutachten (G-4).

• Berichtsmonat: der Knopf schlägt den abgeschlossenen Vormonat vor (den Monat, den die Monatsaufgaben MED-D-652 abfragen). Die Route nimmt jeden abgeschlossenen Monat des Planungszeitraums an — damit ist ein Nachtrag für einen übersprungenen Monat möglich; künftige Monate und Monate außerhalb des Planungszeitraums werden mit sprechendem Hinweis abgewiesen, bevor ein Dokument entsteht (ein Beleg ohne Monatswerte wäre kein Beleg, G-4).
• Inhalt (pyramidal): Lage-Sätze (Kompass-Wortlaut) → Kennzahlen des Bezugsjahres mit Richtwert → Berichtsmonat Position für Position → Liquiditätsvorschau 12 Monate (Ist/Plan je Zeile) → Handlungsempfehlungen mit Auswirkung und Annahme (Schätzwerte gekennzeichnet) → Berechnungsgrundlage je Zahl (Lineage aus §4.5) → Abgrenzung zur Steuerberatung.
• Eine Datengrundlage, zwei Ausgaben (G-2): dasselbe Blockmodell rendert die PDF-Fassung (pdf-lib im Worker) und die Markdown-Fassung; letztere geht nicht in die Datenbank, ihr SHA-256 steht im Audit-Event — der Beleg ist damit nachweisbar unverändert, ohne Praxiszahlen doppelt zu speichern.
• Jeder Aufruf = eigene Fassung: der Dateiname trägt ein eindeutiges Suffix, eine ältere Fassung wird nie überschrieben (Beleg-Charakter, G-4).
• Dormant ohne Ablage: ist keine Ablage konfiguriert, antwortet die Route mit einem sprechenden Hinweis (503) statt mit einem halben Beleg.

10.7 Personal: Person einmal anlegen, Anstellung als Zeitspanne (MED-D-693)

Kernaussage. Eine Person wird einmal angelegt (Kürzel · Rolle · Behandler ja/nein). Alles Zeitabhängige steht in Anstellungs-Zeitspannen: ab · bis · Status · Monatsbrutto · Plan-Umsatz · Beteiligung. Gehaltserhöhung, Teilzeit, Statuswechsel und Wiedereintritt sind je ein weiterer Zeitraum — damit sind Änderungen und Ein-/Austritte dort, wo man sie erwartet, statt in Sonderfeldern.

Warum. Vorher trug der person-Baustein zwei Achsen gleichzeitig: die Korrektur-Historie (Version, append-only) und die fachliche Gültigkeit (gueltigAb/gueltigBis = Eintritt/Austritt, plus eine Sonderliste gehaltsaenderungen[]). Ein Statuswechsel oder ein geänderter Plan-Umsatz war damit gar nicht zeitabhängig abbildbar. Jetzt gilt: Version = Korrektur, Spanne = Gültigkeit.

Was	Wo	Regel
Identität	PersonDaten	bezeichnung · rolle · behandler
Gültigkeit je Zeitraum	PersonDaten.abschnitte[]	vollständiger Stand des Zeitraums; Lücken erlaubt (Wiedereintritt), Überlappungen nicht; offen laufen darf nur der letzte Zeitraum
Eintritt / Austritt	abgeleitet	Beginn der ersten / Ende der letzten Spanne (null, solange eine Spanne offen läuft)
Rahmen der Version	abgeleitet	gueltigAb/gueltigBis kommen immer aus den Spannen — Liste und Filter arbeiten weiter über die Spalten, ohne zweite Wahrheit (G-2)
Korrektur	Baustein-Version	jede Änderung = neue Version (append-only, G-4)

• Rechnung: rechne() fragt je Monat die gültige Spanne (anstellungInIndex); ohne Spanne zählt die Person in diesem Monat nicht (Personalkosten, Plan-Umsatz, Beteiligung folgen der Spanne).
• Was-wäre-wenn: „Eintritt drei Monate später" verschiebt alle Spannen der Person mit (P-5), nicht nur das Fenster — die Empfehlung person-spaeter rechnet damit weiter exakt nach.
• Bestand: Alt-Daten werden lesend in Spannen überführt (personDaten()); gespeichert wird nur die neue Form. Kein Datenbank-Umbau, keine Migration — und Aufrufer, die noch die Alt-Felder senden, erzeugen automatisch eine Spanne aus dem Fenster.

10.8 Performance je Behandler: Monats-Tabelle + Festschreiben (MED-D-694)

Kernaussage. Die Ist-Umsätze werden tabellarisch erfasst — Zeilen = Monate (neueste zuerst), Spalten = Behandler —, und abgeschlossene Monate lassen sich festschreiben: bis zum Wasserzeichen „festgeschrieben bis " ist keine Änderung mehr möglich. Damit widerspricht kein späterer Eingriff mehr dem eingefrorenen Monatsbericht (G-4).

Teil	Regel
Erfassung	13 Zeilen (laufender Monat + 12 davor), je Zeile „Wie Vormonat", Summenspalte; gespeichert werden nur geänderte Monate
Weiche Hinweise	Abweichung > 30 % zum Vormonat wird je Zelle und als Zeile unter der Tabelle gemeldet — blockiert nicht (G-3)
Sperre	der Guard sitzt im Dienst (istErfassen → 409), nicht in der Oberfläche: auch Portal-Monatsmeldung und späterer PVS-Import laufen hinein
Festschreiben	nur abgeschlossene Monate (vor dem laufenden) und nur vorwärts; jede Rolle darf es (normaler Monatsabschluss)
Aufheben	nur Rolle admin (Fähigkeit dexman_festschreibung_aufheben, R7), senkt das Wasserzeichen oder hebt es ganz auf
Nachweis	append-only Log dexman_festschreibung (Praxis · bis-Monat · Aktion · wann · wer); Stand = jüngster Eintrag (abgeleitet, G-2), jede Aktion zusätzlich als Audit-Event
Monatsbericht	nennt den festgeschriebenen Stand in der Datengrundlage (DEX-5)

10.9 Empfehlung als Vorschlag für die Beratungsdokumentation (DEX-6, MED-D-735)

Kernaussage. Eine Handlungsempfehlung kann der Berater als Vorschlag in die Beratungsdokumentation (R6) geben. Der Vorschlag schreibt nie selbst ins Protokoll: das letzte Wort hat der Berater — er übernimmt (mit eigener Formulierung), verwirft (mit Grund) oder meldet später „umgesetzt". Damit beantwortet Medidentas, was dem Kunden empfohlen wurde und was daraus geworden ist (True North #3, G-4).

Teil	Regel
Wo landet er	am laufenden Dexman-Mandat der Praxis (dort liegt die Beratungsdokumentation); ohne solches Mandat 409 mit Hinweis
Idempotent	je Praxis × Regel ein Vorschlag (quelle_ref = dexman:<praxis>:<regel>); erneutes Vorschlagen ändert nichts, auch nicht nach „verworfen"
Text	aus der Regel erzeugt (was · Auswirkung · Annahme; Schätzwert bleibt gekennzeichnet); der Berater darf ihn vor dem Übernehmen ändern
Übernehmen	hängt „Empfehlung aus Dexman: …" als Absatz an das Protokoll an und setzt einen bereits geprüften Entwurf zurück (G-4). Abgewiesen (409, Vorschlag bleibt offen) bei: keine Doku am Mandat · Doku freigegeben (keine stille Änderung einer Freigabe) · Dokumentationsverzicht
Verwerfen	verlangt einen Grund (3–500 Zeichen), endgültig. Auch nach der Übernahme möglich („nicht umgesetzt melden", etwa weil der Kunde der Empfehlung nicht folgt): der übernommene Absatz bleibt als Beleg im Protokoll (append-only, G-4), die Entscheidung wird zusätzlich festgehalten
Umgesetzt	nur für Übernommenes; danach ist der Vorschlag abgeschlossen
Gleichzeitigkeit	Beanspruchen vor Ändern: jede Entscheidung setzt den Status zuerst atomar (bedingtes UPDATE), erst danach wird das Protokoll geändert. So entsteht bei Doppelklick oder zwei Sitzungen kein doppelter Absatz und keine Ablehnung, die dem Protokoll widerspricht; scheitert die Protokoll-Änderung, wird die Beanspruchung zurückgenommen. Auch das Anlegen ist atomar idempotent (INSERT … ON CONFLICT DO NOTHING auf quelle_ref)
Nachweis	je Schritt ein Audit-Event (beratungsvorschlag.angelegt/uebernommen/verworfen/umgesetzt), PII-arm: nur IDs/Enums, nie Text oder Beträge
Beratungsmodus	der Vorschlagstext entsteht serverseitig ohne Anzeige-Raster des Beratungsmodus (§4.7): das Protokoll ist ein Beleg, kein Bildschirm — es gelten nur die Raster der Regel selbst

Oberfläche: Dexman → Empfehlungen → „In Beratungsdoku vorschlagen" (Kompass und Klassisch); die Vorschläge stehen im Mandat-Overlay unter der Beratungsdokumentation. Keine KI im Spiel — der Text entsteht aus der Regel (RISK-14).

10.10 Kachel im Kunden-Detail (DEX-5, MED-D-737, MED-D-764)

Kernaussage. Die Kunde beantwortet „Wie ist die Lage der Praxis?" ohne Klick: eine Kachel in der linken Rail, je Praxis mit laufendem Dexman-Mandat. Sie ist eine reine Verdichtung der Server-Rechnung (lage) — nichts wird gespeichert (G-2) — und erscheint nur, wenn es ein laufendes Dexman-Mandat gibt.

Zeile der Kachel	Quelle
Praxis + Gesamtstatus (Form und Farbe: ● trägt · ◆ knapp · ■ Unterdeckung)	Ergebnis.status, Begriffe wie im Dexman (§11)
Kernaussage (+ ergänzender Satz)	satzHeute — derselbe Satz wie im Kompass „Lage"
Ampel der drei Bereiche	Ergebnis.bereiche → Rentabilität · Personal · Liquidität, je mit Fachbegriff
Umsatz vs. Plan (MED-D-764)	umsatzGegenPlan (shared/dexman-kern/plan-ist.ts): letzter gemeldeter Ist-Monat gegen den Plan derselben Behandler im selben Monat; Ampel bis −5 % „Im Plan" · bis −15 % „Leicht unter Plan" · darüber hinaus „Deutlich unter Plan" (Schwellen PLAN_TOLERANZ/PLAN_ABSTAND, Annahme — #764); ohne Plan „Kein Plan hinterlegt"; Beträge folgen dem Beratungsmodus
Wichtigste Empfehlung (+ „n weitere") = Top-Reserve	findeHebel, erste Empfehlung — die nach Wirkung in € sortierte Liste führt die größte Reserve; darunter die Wirkung (Schätzwert gekennzeichnet)
Datenstand	letzter Monat mit erfasstem Ist-Umsatz, sonst „nur Planung"
Offene Vorschläge	Beratungsvorschläge des Mandats im Status zur Entscheidung (§10.9)
„Dexman öffnen →"	öffnet das Dexman-Overlay der Praxis

• Endpunkt: GET /api/mandanten/:id/dexman-kacheln (Scope je Kunde über den Kunden-Chokepoint; fremder Berater → 404). Wie lage ein abgeleiteter Überblick und kein Rohdaten-Zugriff: kein eigenes Lesezugriffs-Event; der Zugriff auf stand (Gehälter, Umsatz je Behandler) bleibt der protokollierte Lesezugriff (D-50).
• Beratungsmodus (§4.7): das Kunden-Detail wird bei Bildschirmfreigabe mitgezeigt. Der Schalter ist deshalb ein App-weiter Zustand (BeratungsmodusState, nicht mehr nur im Dexman-Fenster); ist er an, fragt die Kachel mit ?anzeigeRaster=100 nach (nur die Werte 1 und 100 sind zulässig) und zeigt den Hinweis „Beratungsmodus: Beträge auf 100 € gerundet" mit „ausschalten".
• Leichtgewichtig: die Kachel importiert den Rechenkern nicht, sie lädt als eigener Chunk (@defer) — das Start-Bundle bleibt klein, das Dexman selbst erst beim Öffnen geladen. Nach dem Schließen des Dexman lädt sie neu.
• Fehlerfall: schlägt das Laden fehl, fehlt nur die Kachel — das Kunden-Detail bleibt unberührt.

10.11 Zahlungseingang: Kassen-/Privatleistungen, Bezugsbasis, Verzug (MED-D-710)

Antwort in einem Satz: Die Praxis erfasst je Monat, wie viel Kassen- und wie viel Privatleistung sie erbracht hat; in der Auswertung wählt sie per Radio-Button, ob nach Leistungsmonat oder Zuflussmonat gerechnet wird und nach wie vielen Monaten die Kasse zahlt.

Baustein	Verhalten
Eingabe	Ist-Tabelle: je Monat "Davon Kasse" und "Davon Privat" (beide Beträge, 0 wenn keine); PUT /api/dexman/praxen/:id/ist/:monat mit leistung
Speicherung	zwei Fakten je Leistungsmonat in praxis_jahreswert (dexman.leistung.kasse / .privat); die Festschreibung (MED-D-694) sperrt sie mit
Auswertung	rechne(eingabe) mit eingabe.leistungsmix und eingabe.annahmen; im Browser und im Worker identisch
Bezugsbasis	Leistungsmonat = Umsatz des Monats; Zuflussmonat = Zahlungseingang mit Verzug. Wirkt auf Liquidität und Umsatzbeteiligung
Verzug der Kasse	einheitlich für alle Kassenleistungen; wählbar sofort · 3 · 4 · 5 · 6 Monate (die Praxis-Einstellung bleibt wählbar)
Nicht gespeichert	die Wahl der Radio-Buttons (reine Auswertung); der Kassenanteil des Monats (abgeleitet)
Hinweis	leistung_abweichung, wenn Kasse + Privat um mehr als 1 % von den Behandler-Umsätzen abweicht

Kompatibilität: Ohne Leistungsmix und ohne Wahl rechnet Dexman wie zuvor. Praxen mit erloesModus = zuflussbasiert starten in der Sicht "Zuflussmonat"; ihre Umsatzbeteiligung folgt jetzt ebenfalls dem Zahlungseingang (bisher dem Umsatz des Monats).

11. Sprachregelung — formelle Fachsprache (MED-D-383)

Kernaussage. Zielgruppe sind Ärztinnen und Ärzte als Praxisinhaber. Dexman spricht deshalb formell und betriebswirtschaftlich präzise (Sie-Form, Fachbegriffe aus Controlling und Finanzierung) statt umgangssprachlich. Die Begriffe sind an einer Stelle definiert (shared/dexman-kern/begriffe.ts, Sätze in saetze.ts, Empfehlungen in hebel.ts) und gelten in beiden Oberflächen gleich (G-3, G-8).

11.1 Status je Bereich

Bereich	trägt	knapp	unterdeckt	keine Daten
Betriebsergebnis (Mindestumsatz)	Kostendeckend	Knapp kostendeckend	Unterdeckung	Keine Datengrundlage
Personalkostenquote	Im Richtwert	Leicht über Richtwert	Über Richtwert	Keine Datengrundlage
Liquidität (Kontoverlauf)	Liquidität gesichert	Liquiditätsengpass absehbar	Liquiditätsengpass	Keine Datengrundlage

11.2 Begriffe in der Oberfläche

Bisher (Entwurf)	Jetzt
Heute · Vorschau · Hebel · Zahlen erfassen	Lage · Liquiditätsvorschau · Empfehlungen · Ist-Umsätze
„Ihre Praxis trägt sich. Sie braucht … je Arbeitstag, um alles zu bezahlen.“	„Ihre Praxis arbeitet kostendeckend. Der erforderliche Mindestumsatz beträgt … je Arbeitstag.“
„Das Konto rutscht im … ins Minus.“	„Ab … ist ein Liquiditätsengpass zu erwarten.“
Tageslinie (Anzeige)	Mindestumsatz je Arbeitstag (Tageslinie bleibt der Entwurfsbegriff)
Stellschraube · Wirkung · Schritt	Handlungsempfehlung · Auswirkung · Maßnahme
Übernehmen · Zurück zum Plan	In Planung übernehmen · Szenario verwerfen
Zeitleiste · „… kommt/geht“	Planungsereignisse · „Eintritt/Austritt: …“
Personal je Umsatz-Euro (Cent)	Personalkostenquote (%)
Woher kommt die Zahl? · Quelle	Berechnungsgrundlage anzeigen · Datengrundlage
„bitte ausfüllen“ · „bitte eine Zahl angeben“	„Angabe erforderlich“ · „numerischer Wert erforderlich“

Regel für neue Texte: Sie-Form, Nominalstil nur wo er präziser ist, keine Umgangssprache („knapp“, „rutscht“, „Stellschraube“), Fachbegriffe aus BWA/Controlling (Mindestumsatz, Liquidität, Unterdeckung, Personalkostenquote), Beträge immer mit Bezug (je Arbeitstag, monatlich, pro Jahr). Der Prototyp (design/dexman/) ist entsprechend angeglichen.