Datenmodell

/v1/ umfasst sechs Datendomänen und dazu vorberechnete Objekt-Kennzahlen, unten nach Tabelle aufgeschlüsselt. Die Feldreferenz je Endpunkt steht in der API-Referenz.

Accounting

accounts, booking_headers, booking_positions, budgets und account_hierarchies

Contracts

service_contracts, contract_debits, contract_debit_diffs, contract_ends und index_rent

Depreciation

assets und depreciation

KPI (Preview)

property_kpis und property_kpis_by_floor_area_type, aggregiert aus den anderen Domänen

Operations

notifications, offers, orders, projects und requests

Property

properties, property_structure, property_creditor_services und technical_objects

Stakeholder

creditors, employees, owners und tenants

Wie die Tabellen zusammenhängen

property_id ist der Join-Key, den sich alle Tabellen auf dieser Seite teilen. Ein Buchungsvorgang erzeugt einen booking_headers, der alle dabei ausgelösten Buchungen (booking_positions) vereint. Buchungen können auf Konten unterschiedlicher Art gebucht werden — Sachkonto, Personenkonto, Kreditorkonto, Projektkonto oder Kostenstelle, siehe accounts.account_type_name. Da ein Buchungsvorgang in der Regel einen Kreditor, einen Mieter oder eine Kostenstelle betrifft, enthält booking_headers creditor_id, person_id und property_structure_account_id bereits selbst — der Join über booking_positions entfällt.
Zu jedem Konto kann es ein budget für einen bestimmten Monat geben. Bei einer Kostenstelle entspricht property_structure.account_id dem accounts.account_number der zugehörigen Konto-Zeile — nicht deren accounts.account_id. contract_debits referenziert über account_number das Sachkonto, auf das gebucht wird — gegen accounts.account_number. contract_debit_diffs nutzt denselben Feldnamen account_number, löst aber gegen ein Personenkonto auf — gleicher Spaltenname, andere Kontoart je Tabelle. contract_debits.debit_type.code ist etwas anderes, ein Sollart-Code, kein Kontenbezug (siehe die account_id-Zeile weiter unten).

Verknüpfungsschlüssel im Detail

Key	Bedeutung	Kardinalität
`property_id`	Identifiziert ein Objekt. Auf jeder Tabelle dieser Seite vorhanden, außer `creditors` (eine eigenständige Entität, referenziert über `creditor_id`).	1 Objekt → viele Zeilen in jeder Domäne
`booking_header_id`	Gruppiert Buchungspositionen unter einem Buchungskopf.	1 `booking_headers` → viele `booking_positions`
`account_id`	Interne Konto-ID bei `accounts`, `booking_positions`, `budgets` und `account_hierarchies` — darüber verknüpfbar. `index_rent.account_id` und `contract_debits.debit_type.code` bedeuten etwas anderes: den Sollart-Code — nicht mit `accounts` verknüpfen. Bei `property_structure` bedeutet es wieder etwas anderes: einen Kostenstellen-Geschäftscode, der `accounts.account_number` der zugehörigen Kostenstellen-Zeile entspricht, nicht `accounts.account_id`.	1 `accounts`-Zeile → viele `booking_positions`/`budgets`-Zeilen, eine `account_hierarchies`-Zeile je Reporting-Struktur
`account_number` (bei `contract_debits`/`contract_debit_diffs`)	Das Konto, auf das eine Zeile bucht. Bei `contract_debits` ein Sachkonto, bei `contract_debit_diffs` dagegen ein Personenkonto — gleicher Spaltenname, andere Kontoart. Entspricht `accounts.account_number`, nicht `accounts.account_id`.	1 `accounts`-Zeile → viele `contract_debits`/`contract_debit_diffs`-Zeilen
`creditor_id`	Identifiziert einen Kreditor. Referenziert von `technical_objects`, `property_creditor_services`, `service_contracts`, `booking_headers`, `booking_positions`, `orders` und `offers`.	1 Kreditor → viele Zeilen über Domänen hinweg
`project_account_id`	Verknüpft eine Anfrage, ein Angebot oder einen Auftrag mit dem Projektkonto. Vorhanden auf `projects` (eins je Projekt), `requests` und `offers`; auf `orders` heißt derselbe Wert `project_reference_id`. Leer außerhalb eines Projekts; bei `requests` und `offers` haben einzelne Werte kein passendes Projekt.	1 Projekt → 0..N Anfragen/Angebote/Aufträge
`technical_object_id`	Vorhanden auf `notifications` und `orders`, löst sich gegen `technical_objects.technical_object_id` auf. Bei beiden hat nicht jeder Wert ein passendes technisches Objekt — Left Join verwenden.	1 technisches Objekt → viele Meldungen/Aufträge
`report_id`	Verknüpft einen Auftrag mit der Meldung, aus der er entstanden ist.	1 Meldung → 0..N Aufträge
`request_id`	Verknüpft ein Angebot mit der Angebotsanfrage, auf die es antwortet.	1 Anfrage → 0..N Angebote
`order_id` (auf `offers`)	Der Auftrag, der auf Basis eines Angebots vergeben wurde.	1 Auftrag → 0..1 Angebot
`service_contract_id`	Verknüpft ein technisches Objekt mit dem Wartungsvertrag, der es abdeckt. Referenziert `service_contracts.contract_id`.	1 Vertrag → viele technische Objekte
`person_id`	Verknüpft eine Buchung mit dem Mieter, auf den sie sich bezieht. Nur gemeinsam mit `property_id` gültig, da die Nummerierung pro Objekt neu beginnt. Bei `tenants`, `booking_headers` und `booking_positions` ein String. Buchungen sind einem Mieter nur auf Objektebene zuordenbar, nicht bis zur einzelnen Fläche — hält derselbe Mieter mehrere Flächen im selben Objekt, lassen sich seine Buchungen nicht nach Fläche trennen.	1 Person → 1..N Mietverhältnisse pro Objekt
`floor_area_person_id`	Identifiziert ein Mietverhältnis. `tenants`, `contract_debits`, `contract_ends` und `index_rent` teilen denselben Wert und denselben Typ (String) — direkt darüber verknüpfen, ohne `property_id` und ohne Cast.	1 Mietverhältnis → viele Soll-/Ende-/Index-Zeilen
`floor_area_id`	Identifiziert eine Einheit in `property_structure`. Außerdem vorhanden auf `technical_objects`, `tenants`, `contract_debits`, `contract_ends`, `requests` und `offers`.	1 Einheit → viele Zeilen
`asset_id`	Verknüpft eine Abschreibungsbuchung mit dem Anlagegut, auf das sie abschreibt. Jede `depreciation`-Zeile löst sich gegen `assets` auf.	1 Anlagegut → viele Buchungen
`property_structure_account_id`	Fremdschlüssel auf `property_structure`, vorhanden auf `booking_headers`, `booking_positions` und `technical_objects`. Auf den beiden Buchungstabellen immer befüllt und dort der einzige Weg von einer Buchung zu einer Einheit; auf `technical_objects` der Fallback für Zeilen ohne `floor_area_id`.	1 Einheit → viele Zeilen

Die oben genannten Kardinalitäten beschreiben das beabsichtigte Datenmodell.

Schlüsselaufbau: zusammengesetzt, aber nicht zerlegbar

Die Identifikatoren sind hierarchisch. Jeder trägt den darüberliegenden als wörtliches Links-Präfix, ein Mietverhältnis-Schlüssel nennt also Einheit und Objekt gleich mit:

property_id                    1002
└─ floor_area_id               100210001         property_id + Flächennummer
   └─ floor_area_person_id     100210001100001   floor_area_id + person_id

Der Schlüssel entsteht durch Anhängen: 1002 (Objekt) + 10001 (Flächennummer) = floor_area_id 100210001; 100210001 + 100001 (Mieter-Nummer) = floor_area_person_id 100210001100001. Trotzdem nicht zurückzerlegen, um die Bestandteile zu ermitteln. Die Segmentbreiten sind nicht fest — dasselbe Objekt kann sowohl 45111 als auch 451110 als floor_area_id führen, 45111 ist also selbst ein Präfix von 451110 und ein Präfix-Vergleich damit mehrdeutig. Beim Bilden des Schlüssels fallen außerdem Trennzeichen weg: eine person_id "010-1" landet als Suffix 0101 und lässt sich nicht zurückgewinnen. property_id, floor_area_id und person_id direkt lesen statt den zusammengesetzten Wert zu zerschneiden.

Erste Schritte

Kernkonzepte

Anleitungen

Datenmodell

Accounting

Contracts

Depreciation

KPI (Preview)

Operations

Property

Stakeholder

Wie die Tabellen zusammenhängen

Verknüpfungsschlüssel im Detail

Schlüsselaufbau: zusammengesetzt, aber nicht zerlegbar

Accounting

Contracts

Depreciation

KPI (Preview)

Operations

Property

Stakeholder

​Wie die Tabellen zusammenhängen

​Verknüpfungsschlüssel im Detail

​Schlüsselaufbau: zusammengesetzt, aber nicht zerlegbar

Wie die Tabellen zusammenhängen

Verknüpfungsschlüssel im Detail

Schlüsselaufbau: zusammengesetzt, aber nicht zerlegbar