Skip to content

Data catalogue

Audience: internal & partnersStatus: implementedSource: application code

The catalogue shows which fields exist in each canonical domain, how external names map to them, which direction they travel and which system may overwrite them. It describes the current implementation, not a proposed integration. A domain gets a page once it holds data: services that only carry platform plumbing, and services still reduced to a stub, are deliberately absent.

  • Certificates

    Calibration-certificate records, customer access, and PDF delivery.

    Open certificates

  • Customers

    Customer and shipping-address mappings across Büro+, Business Central and Salesforce.

    Open customers

  • Employees

    Personio inbound and Microsoft 365 provisioning.

    Open employees

  • Procurements

    Suppliers, purchased items, supply options, and source catalogues.

    Open procurements

  • Products

    Büro+ and Salesforce workflow, article-number grammar, and catalogue mappings.

    Open products

  • Integrations

    Application e-mail, Hivebuy purchase-order PDFs, and supplier invoice conversion and delivery.

    Open integrations

  • Auth & logging

    Operational identity, credential and audit fields.

    Open auth & logging

How to read the tables

Marker Meaning
→ core Vendor data is translated into the canonical field.
core → Canonical data is pushed to the external system.
↔ Both paths exist; authority still decides which inbound values may win.
mirror only Stored for integration operation but not promoted into core.
core-owned Inbound vendors cannot overwrite a non-empty canonical value.
open A non-empty inbound value may update core.
derived Computed or normalized rather than copied directly.

Database-generated primary keys are omitted because they do not cross a system boundary. Timestamps and operational mirror fields are listed separately when they matter to sync behavior.

Lineage at a glance

flowchart LR
  source["External payload"]:::ext --> mirror["Vendor mirror"]:::vend
  mirror --> translate["Validation + translation"]:::vend
  translate --> core["Canonical domain model"]:::corebox
  core --> sync["Scheduled sync"]:::plat
  sync --> target["External consumer"]:::ext

  classDef ext fill:#f9d6d6,stroke:#b04,color:#000
  classDef vend fill:#fde8e8,stroke:#b04,color:#000
  classDef corebox fill:#cfeec9,stroke:#2a6,color:#000
  classDef plat fill:#e0f0ff,stroke:#268,color:#000

Colours in the diagrams

Every diagram in the catalogue uses the same six node colours, in both the light and the dark theme.

Colour Node kind
External External system or party outside ESZ.
Vendor mirror Vendor-shaped mirror and its translation step.
Ledger Operational ledger row: a request, a job, a delivery attempt.
Core Canonical domain model.
Platform Platform mechanism such as the scheduled sync or the job queue.
Object storage Object storage holding a document outside Postgres.

A new diagram may only use these classes; a class without a dark-theme rule in stylesheets/extra.css keeps its light fill when the reader switches themes.