Zum Inhalt springen

Berechnungs-Übersicht

Status: Entwurf

Wie wird aus Stammdaten + Modell + Annahmen ein Case-Ergebnis?

Berechnungs-Pipeline (vereinfacht)

Berechnungs-Pipeline

Unit-Case-Berechnung

Je gewähltem Modul entsteht ein Unit-Case-Resultat. Pro Modul / Tochter typisch:

Sanierungs-Modul (optional, bei energetischer Modernisierung — eigener Case oder Add-on)

CapEx_sanierung = Σ Material_kosten + Σ Dienstleistung_kosten
margin_sanierung = (Umsatz_sanierung - CapEx_sanierung - Overhead) / Umsatz_sanierung
cashflow_sanierung[t] = je nach Bauphasen-Plan

Hinweis: Sanierung ist kein Pflichtmodul. Bei Mandats-Cases ohne Sanierungswunsch entfällt dieser Block komplett. Beim seltenen bestandstyp=eigenbestand oder im case_type=renditerechner ist Sanierung der Hauptposten — bei Standard-Mandaten oft gar nicht enthalten.

Verwaltungs-Tochter

umsatz_verwaltung[t] = Σ Wohneinheit.nettomiete * Verwaltungs-Quote
opex_verwaltung[t] = Personal + Overhead je Wohneinheit
cashflow_verwaltung[t] = umsatz - opex

Energie-Tochter (PV + Mieterstrom)

pv_erzeugung_kwh[t] = leistung_kwp * spez_ertrag * verfügbarkeit
direktverbrauch_kwh[t] = min(pv_erzeugung[t] - speicher_lade[t], last[t])
mieterstrom_erloese[t] = direktverbrauch * arbeitspreis_mieterstrom
einspeise_erloese[t] = (pv_erzeugung - direktverbrauch - speicher_lade) * eeg_verguetung
opex_pv[t] = wartung + msb_kosten + abrechnung
cashflow_energie[t] = mieterstrom_erloese + einspeise_erloese - opex_pv - capex_anteilig

Versicherungs-Tochter

provision_versicherung[t] = vertragspraemie * provisionssatz
cashflow_versicherung[t] = provision - vertriebskosten

Holding-Aggregation

cashflow_holding[t] = Σ_aktive_module cashflow_modul[t] - eliminierungen_intern
NPV_holding = Σ_t cashflow_holding[t] / (1 + zinssatz)^t
IRR_holding = solver(cashflow_holding[])
amortisation_jahre = solver(kumulierter_cashflow >= 0)

In Σ_aktive_module gehen nur die im Mandat gebuchten Module ein. Module ohne Auswahl liefern keinen Beitrag — auch keinen negativen.

eliminierungen_intern: Verträge mit internal_to_holding=true werden als Erlös der einen Tochter und Aufwand der anderen ausgewiesen, summieren sich aber zu null in der Holding-Sicht.

Eigentümer-Sicht (parallel zur Holding-Sicht)

Pro Mandat existieren zwei Cashflows nebeneinander, beide auf demselben Datensatz:

cashflow_eigentuemer[t] =
+ erloese_eigentuemer[t] /* Mieterstrom-Anteil Eigentümer, Mieter-Access-Provision */
+ ersparnisse_eigentuemer[t] /* eingesparte Verwaltung, günstigere Versicherung etc. */
- capex_eigentuemer[t] /* PV/Speicher-Anteil, soweit Eigentümer-finanziert */
- opex_eigentuemer[t] /* Modul-Honorare, die Eigentümer an die Holding zahlt */
+ wertsteigerung[t] /* Bewertungs-Effekt durch Modernisierung, optional */
NPV_eigentuemer = Σ_t cashflow_eigentuemer[t] / (1 + zinssatz)^t

Die Aufteilung Holding ↔ Eigentümer wird per Mandats-Vertrag festgelegt; die Excel-Vorlage zeigt z. B. 12,72 € / 15,04 € pro VE/Monat als Mustermodell. Der Aggregator gibt beide Sichten in einem Dossier aus.

Sensitivitäten

Standard-Set:

VariableBandbreite
Strompreis (Bezug)±10 %
Strompreis (Einspeise)±10 %
Mietsteigerung0 / 1 / 2 / 3 % p. a.
Zinssatz±100 bp
Sanierungskosten±15 %
Eigenverbrauchsquote50 % / 70 % / 90 %
Mieterausfall0 / 5 / 10 %
Förderungmit / ohne

Solver-Kopplung (V2)

Wenn Anwender die Frage stellt „welche Material-/Provider-Kombination maximiert NPV?”, übernimmt ein Solver:

  • Eingang: Constraints (Min-/Max-Mengen, Provider-Mix, Vertragslaufzeiten, Budget) + Zielfunktion (NPV / IRR / Amortisation)
  • Variablen: diskrete Auswahl aus Material-/Provider-Katalog
  • Ausgabe: beste Konfiguration + Pareto-Front

Kandidaten: OR-Tools, Pyomo/HiGHS, CP-SAT — siehe projektmike/output/gettingtoyes/story.md.

Solver ist eigener Python-Service via REST/gRPC. Workbench ruft, wartet asynchron, schreibt Ergebnis ins Dossier.

Determinismus

Berechnungen sind deterministisch: gleiche Eingabe → gleiche Ausgabe. Stochastik nur explizit (Monte-Carlo-Sensitivitäten als Spezialmodus, V2+).

Verwandte Dokumente