Skip to main content
/v1/ dokumentiert eine Tabelle erst, sobald sie live ist. Aktuell haben vier Domänen mindestens eine dokumentierte Tabelle.

Accounting

booking_header, booking_positions und budgets, mit period-, amount- und amount_per_sqm-Objekten.

Operations

notifications und projects, mit der Umbenennung zu technical_object_id und dem hierarchy-Array.

Property

technical_objects, mit dem bedingten property_structure_account_id-Fallback.

Stakeholder

tenants, mit Mietvertrags-Datumsfeldern und Kontaktdaten — die Spalten phone_1phone_3 sind noch nicht zu einem Array zusammengefasst.
Property.properties ist ebenfalls live unter /v1/, wird aber unverändert (inklusive der durchnummerierten Spalten entrance_1entrance_5) statt umgeformt ausgeliefert — bewusst nicht Teil dieses Datenmodells. Nutze stattdessen das unversionierte Property.properties. Jede andere Tabelle (orders, property_structure, assets, contract_debits usw.) ist noch nicht live unter /v1/ und bleibt auf dem unversionierten Pfad.

Wie die v1-Tabellen zusammenhängen

property_id ist der Join-Key, den sich alle Tabellen auf dieser Seite teilen.

Verknüpfungsschlüssel im Detail

budgets und tenants tragen als Join-Key in die Tabellen dieser Seite nur property_id — weitere, externe Join-Keys (account_id, floor_area_id) stehen in ihren jeweiligen Feldreferenzen.
Die oben genannten Kardinalitäten beschreiben das beabsichtigte Datenmodell, nicht unabhängig verifizierte Zeilenzahlen. projects.creditor_id und projects.to_hdr_id sind bewusst nicht Teil dieses Diagramms — beide sind in der Operations-Feldreferenz als unzuverlässig markiert, also nicht als funktionierende Verknüpfung behandeln.