Für Administratoren und Entwickler
Architektur: Wie das Centroplan-System gebaut ist
Dieses Kapitel richtet sich an Administratoren, Entwickler und alle, die verstehen wollen,
warum sich das System so verhält, wie die Schulung es zeigt. Alles hier Beschriebene ist
aus dem Code und der laufenden Instanz verifiziert, Stand August 2026.
Die Module
Sechs eigene Module auf Odoo 19 Enterprise. Jedes hat genau eine Verantwortung:
| Modul | Verantwortung |
|---|---|
centroplan_base | Schirm-Modul: installiert alle Apps und Module, setzt das Branding |
centroplan_project | Projekt-Stammdaten und Technik-Felder, die fünf Lebenszyklus-Phasen, Gate-Aufgaben mit Freigabeverfahren, die Kalkulationspositionen als Kontenbaum, Projektvorlagen, Salesforce-Freeze |
centroplan_finance | Die versionierte Kalkulation: Plan, Ist, Leistungsstand, Prognose, Ampel, Snapshot- und Freigabemechanik, die Pivots Abgleich Plan/Ist und Forecast Drift |
centroplan_import | Die kontrollierten Kostenzuflüsse: Vario- und Personio-Batches, die Zuordnungstabellen (Artikel, Kostenstellen), Buchung als analytische Kostenzeilen |
centroplan_contacts | Die fünf Kontakttypen mit typspezifischen Karteikarten |
centroplan_staging_data | Nur Schulung/Staging: das Demoprojekt, die Demo-Kalkulation, Beispielkontakte. Ein Installationswächter verhindert die Installation auf Produktion |
Hinweis: Die automatische Dokumentordner-Struktur je Projekt liegt auf dem
Staging-Stand und ist im Schulungsstand nicht enthalten.
Das Datenmodell im Kern
Zwei analytische Pläne tragen das gesamte Kostengeschehen:
- Projekt – jedes Projekt hat sein analytisches Konto.
- Kalkulationsposition – ein Kontenbaum aus 15 Oberpositionen und 71 Unterpositionen
(account.analytic.account mit Eltern-Kind-Beziehung). Gebucht wird nur auf
Unterpositionen; Oberpositionen sind reine Summen.
Jede Kostenzeile (account.analytic.line) trägt beide Dimensionen: das Projekt und
die Position. Genau das erlaubt die eine Frage, auf die alles hinausläuft: was hat dieses
Projekt auf dieser Position gekostet.
Die Kalkulation (cp.calculation) hält je Position eine Zeile mit Planbudget,
Ist-Kosten, Leistungsstand, erwarteten Restkosten und der Ampel. Die Prognose liegt
monatsweise daneben (cp.forecast.entry); ein Prozentwert je Monat errechnet den Betrag
aus dem Planbudget der Position.
Die Zuordnungslogik der Importe
Jede Vario-Zeile findet ihre Position über die Artikel-Zuordnung, in dieser Rangfolge:
Produkt-Treffer vor exaktem Treffer vor Präfix; unter Präfixen gewinnt der längste.
Personio bringt statt Artikeln Kostenstellen mit; die Kostenstellen-Zuordnung übersetzt
sie in Positionen. Overhead-Kostenstellen (etwa 31000 Kalkulation) tragen bewusst keine
Position: ihre Stunden buchen nur auf das Projekt.
Drei Regeln, die das Verhalten im Alltag erklären:
- Die Projektnummer ist der einzige Schlüssel. Vario matcht sie direkt, Personio
extrahiert sie per Muster (sieben Ziffern plus Großbuchstabe) aus dem Anwesenheitstext.
- Zeilen-Gating statt Batch-Gating. Eine unbuchbare Zeile (unbekannter Artikel,
fehlender Wert, nicht genehmigte Anwesenheit) hält nie die Datei auf. Sie bleibt
sichtbar liegen und ist nach der Korrektur einzeln nachbuchbar.
- Duplikate sind unmöglich. Jede Zeile trägt einen Schlüssel aus Beleg, Artikel und
Projekt; bereits gebuchte Schlüssel werden beim erneuten Upload als Duplikat markiert.
Versionierung und Freigaben
Save Version / Snapshot friert die aktuelle Kalkulation unveränderlich ein und öffnet
eine neue Arbeitskopie mit denselben Planwerten. So entsteht je Monat ein Stand, gegen den
der Forecast Drift die Bewegung zeigt. Submit for Approval sperrt die Werte und zeigt
dem Freigeber die Änderungen als Vorher/Nachher-Liste – beides Ergebnis des Trainings
vom August, in dem genau dieses Verhalten gewünscht wurde.
Wer freigeben darf, ist Firmen-Stammdatum auf res.company:
| Liste | Wirkung |
|---|---|
| Gate-Freigeber | Nur diese Personen bewegen Gate-Aufgaben zwischen Phasen. Leere Liste = jeder darf |
| Kalkulations-Freigeber | Nur diese Personen sehen und nutzen den Approve-Knopf der Kalkulation |
| Gruppe Freeze-Manager | Darf den Salesforce-Freeze von Hand setzen und lösen; Administratoren erben sie |
Integrationen
- Salesforce / CDB: Projekte im Vertrieb gehören Salesforce. Der Sync matcht über den
Idempotenzschlüssel cdb_ref; solange der Freeze gesetzt ist, sind die gesyncten Felder
in Odoo schreibgeschützt, damit die Systeme nicht auseinanderlaufen.
- Partner-Kosten: Der Partner schreibt Fremdkosten direkt als analytische Zeilen über
die Odoo-API, mit Projekt und Position, am Import-Puffer vorbei.
- Refresh Ist ist absichtlich manuell. Das Controlling bestimmt selbst den Tag des
Monatsend-Standes, statt von automatischen Aktualisierungen überrascht zu werden.
- Die Ampel bewertet das Erwartete, nicht das Ausgegebene: Ist plus Prognose gegen
Plan, mit einer prozentualen Schwelle als einstellbarem Parameter.
In Arbeit
Bewusst noch nicht gebaut, damit hier niemand etwas sucht, das es noch nicht gibt:
- Markup/Marge auf Gesamtkosten (Formel kommt vom Controlling, Ticket 424)
- Drei-Rollen-Modell lesen / ändern / freigeben für die Kalkulation
- Umstellung des Plans auf native Odoo-Budgetbuchhaltung (Ticket 391, pausiert)
- DATEV- und CDB-Integrationsausbau, Migration und Cutover (Epics im Backlog)