UC-02 · Holding-Case aggregieren

Status: Entwurf · Leitfall V1

Verdichtung mehrerer Unit-Cases (je gewähltem Modul / je Tochter) zu einem konsolidierten Holding-Case je Mandat. Beantwortet die Frage: Lohnt sich das Mandat für diese Liegenschaft im Verbund aller gewählten Module?

Trigger

Pro Mandat existieren ein oder mehrere Unit-Cases — einer je gewähltem Modul. Aggregator soll den Holding-Case daraus bilden. Module, die der Eigentümer nicht gewählt hat, gehen nicht in die Aggregation ein.

Akteur

Primär: Aggregator-Service (automatisch)
Mitwirkend: Analyst (parametriert die Aggregation), Management (reviewt das Aggregat)

Ablauf

1. Eingangsmenge bestimmen

Aggregator findet alle Unit-Cases zum selben Mandat (gleiche Liegenschaft + gleicher Eigentümer) mit Status analyse oder neuer. Maßgeblich ist die gewählte Modul-Konfiguration des Mandats — nur die zugehörigen Unit-Cases gehen ein. Beispiel-Sets:

Minimum: nur versicherung → 1 Unit-Case
Typisch: verwaltung + mieterstrom + abrechnung → 3 Unit-Cases
Volles 360° + Mieter-Access: 7 Unit-Cases

2. Konsistenz prüfen

Gleiche Liegenschaft? (Pflicht)
Gleicher Modellstand? (Pflicht — sonst nicht vergleichbar)
Gleicher Stammdaten-Snapshot? (Pflicht)
Gleicher Szenario-Identifier? (Pflicht — Best/Worst/Realistisch nicht mischen)

Bei Verletzung: Hinweis im Dossier, Aggregation läuft trotzdem mit Warnung — der Analyst entscheidet.

3. Verdichtung

Pro Kennzahl-Familie:

Familie	Verdichtung
CapEx (Modul-Investitionen, Holding-Anteil)	Summe über Töchter — nur Holding-finanzierte Anteile, vom Eigentümer getragene Anteile separat ausweisen
OpEx laufend	Summe je Periode
Erlöse Holding	Summe je Periode (intern eliminieren — siehe unten)
Erlöse Eigentümer (Eigentümer-Sicht)	parallel ausgewiesen: Eigentümer-Vorteil pro Periode
Cashflow Holding	Summe der Cashflows nach Eliminierung
IRR / NPV	aus aggregiertem Cashflow neu berechnet (separat für Holding und Eigentümer)
Amortisation	aus aggregiertem Cashflow
Risiko	maximaler Verlust über Szenarien

4. Eliminierung interner Leistungsverflechtungen

Wenn Tochter A der Tochter B eine Dienstleistung in Rechnung stellt, ist das aus Holding-Sicht ein interner Posten — er darf nicht doppelt als Erlös und Aufwand zählen. Aggregator eliminiert solche Posten anhand der internal_to_holding-Markierung am Vertrag.

5. Tochter-Beitrag-Tabelle

Jede Tochter erhält eine Zeile mit:

Eigener Marge (intern berechnet)
Beitrag zum Holding-Cashflow
Risikobeitrag
Anteil am Gesamt-Holding-Ergebnis

Das ist die zentrale Sicht für die Holding-Geschäftsleitung: wer trägt wieviel? Wer ist Verlustbringer, der durch andere kompensiert wird?

6. Sensitivitäten

Aggregator rechnet Standard-Sensitivitäten:

±10 % Strompreis
±10 % Mietsteigerung
±100 bp Zinsänderung
±15 % Sanierungskosten

→ Tabelle, welche Variation den Holding-Case kippen lässt.

7. Holding-Case bereitsteht

Resultat ist ein eigener Case-Datensatz vom Typ holding_case, der:

die Unit-Cases referenziert (nicht kopiert — Live-Verknüpfung im Draft, Snapshot bei Freigabe)
eigene Kennzahlen trägt (verdichtet)
ein eigenes Dossier führt (mit den Unit-Dossiers verlinkt)

8. Freigabe Holding-Case

Management der Holding (nicht der Töchter) gibt den Holding-Case frei. Bei Freigabe:

Modell-Snapshot
Stammdaten-Snapshot
Snapshot der Unit-Cases zum Freigabezeitpunkt

Alternative Pfade

Unit-Case fehlt (nur 3 von 5 erwarteten Töchtern haben einen Case): Aggregator markiert die fehlende(n) Tochter(n) und rechnet ohne. Analyst muss entscheiden, ob das Aggregat aussagekräftig ist.
Widersprüchliche Snapshots: Aggregator verweigert die Aggregation, fordert Konsistenz an.
Tochter widerspricht den von ihr ausgewiesenen Konditionen: eigener Workflow, der das Stammdatum reklamiert.

Datenhoheit zwischen Töchtern

Heikel: Tochter A soll nicht zwingend die Marge von Tochter B sehen. Optionen (zu entscheiden — siehe ../80-open-questions/01-fachliche-offene-punkte.md):

Holding-Sicht-Privileg — nur Holding-Management und Auditor sehen Aggregat; Tochter sieht nur ihren Unit-Case.
Anonymisiertes Aggregat — andere Töchter werden als „andere Beiträge” zusammengefasst.
Voll transparent — alle Beteiligten sehen alle Beiträge.

Die ACL-Mechanik aus docs/spec/70-security/02-authorization.md (scope=entity, attribute_key) deckt alle drei Varianten ab — die fachliche Konfiguration ist offen.

Beteiligte Fachobjekte

Liegenschaft, Tochtergesellschaft, Holding
UnitCase, HoldingCase (zwei Spezialisierungen von Case über case_type)
Modell, Szenario, StammdatenSnapshot
Vertrag mit Flag internal_to_holding