Internal · two views of the same architecture

Data-flow view

The wide data-flow view — provider exchange and contract import as two flows, with VDMS expanded. The module-dependency diff lives in the goal overview; the stale copy that used to sit here was removed 2026-09-19.

2026-09-19 · companion to the goal overview.

Two flows, one shared driver layer

Same architecture, laid out as two flows instead of two columns. Use this one when the question is "what happens to a request" rather than "which module depends on which". The VDMS half is expanded, because it is where the next piece of work lands.

FLOW 1 — PROVIDER EXCHANGE  ·  one order, one round trip sale.order maptara.claim.batch the business fact provider_base driver contract · routing · audit picks the plugin by provider_type provider plugin egeko · azh · MIP · ZHP X3 knows the vendor's vocabulary builds the payload — and nothing else transport driver soap · sftp · rest moves bytes · retries · timeouts knows nothing about healthcare the vendor opta data · azh · … endpoint from ConnectionConfig provider.activity audit row · request/response → insurance_state, chatter return path — only the plugin may interpret a status code Credentials and endpoint enter at the driver as a plain ConnectionConfig — built by the caller from its own ORM model. The driver never runs a search(). FLOW 2 — CONTRACT IMPORT  ·  bulk, scheduled, a different domain entirely RHVital API the truth source inherently multi-payer driver_rest token · backoff · paging replaces VdmsClient vdms_connector raw vdms.* staging rows depends: base, mail, masterdata maptara_codexa_vdms the glue — mapping lives here payer binding · versioning vdms_vertrag.py · vdms_ik.py created today  ✓ codexa.contract codexa.contract.version codexa.contract.item codexa.catalogue.item  ·  codexa.provider.site all via sudo() the gap  ✗ codexa.contract.rule  — the price rules imported contracts arrive without pricing; someone still opens the Price Rules menu by hand Excel / XML import — separate module, later another provider · parsing lives here, not in the driver own glue → same targets Wanted: the import should produce price rules too needs a decision on which rule shape RHVital data maps to — scope, family, specificity The two flows share exactly one thing: the transport drivers. Flow 1 is per-order and synchronous; flow 2 is bulk and scheduled. They must not share a contract — that is why bulk import stays out of the provider driver interface, and why the Excel/XML importer is its own module with its own glue rather than a fifth "provider". Codexa is not touched by any of this. Its coupling to the provider tree is two column names — `name` and `active` on maptara.service.provider (codexa_api/models/provider_site.py:20, :63-67, all sudo()). Don't rename the model or those fields and Codexa never notices the refactor.
The wide flow. Flow 1 is the provider exchange; flow 2 is the contract import. The only thing they share is the driver layer, which is the entire argument for putting drivers under Odoo core rather than inside either tree. The red box in flow 2 is a genuine gap found while drawing this: the VDMS importer creates contracts, versions, items, catalogue items and provider sites — but never codexa.contract.rule.
Found while drawing: imported contracts have no prices

maptara_codexa_vdms/models/vdms_vertrag.py creates codexa.contract, codexa.contract.version, codexa.contract.item and codexa.catalogue.item; vdms_ik.py creates codexa.provider.site. A grep for price_rule / contract.rule across that module returns nothing.

So a contract imported from RHVital lands structurally complete and commercially empty — the price rules that make it usable are still created by hand in the Price Rules menu. If the goal is "VDMS creates contracts and price rules", that is net-new work in the glue module, not a driver concern.

The open question is not technical, it is mapping: which rule shape does RHVital data produce? Contract-scope rules, product-family rules, or exact-product rules — and what decides specificity when an import collides with a hand-made rule. That needs answering before any code, and it is the same class of question as the §302 Datenmapping: the data model is easy, the mapping is the work.

Both diagrams describe the same plan. Neither has been implemented.