Tenant capability checks¶
Every ecommerce client has a separate Odoo database. Installed modules, configuration, access groups, companies, Studio changes, and data state can differ, so feature enablement must be evidence-based per tenant.
Capability record¶
Store this alongside the tenant connection:
{
"snapshot_generated_at": "2026-06-29T00:00:00Z",
"snapshot_schema": 2,
"odoo_version": "19",
"required_models_fields_ok": true,
"integration_acl_ok": true,
"ap_draft_supported": true,
"posting_smoke_tested": false,
"reconciliation_wrapper_supported": true,
"reconciliation_wrapper_version": "v1",
"purchase_order_supported": true,
"three_way_match_supported": true,
"german_b2b_einvoice_receive_supported": true,
"german_b2b_einvoice_issue_supported": false,
"einvoice_capability_contract": "einvoicing-capability.v1",
"website_supported": false,
"manufacturing_supported": false,
"subscriptions_supported": false,
"last_health_check_at": "2026-06-29T00:00:00Z"
}
Required gates¶
| Gate | Evidence |
|---|---|
| Connectivity | API-key user can authenticate, read context, active/allowed companies, and server version |
| Runtime schema | Fresh exporter contains every required model/field and records metadata changes |
| ACL | Exported read/create/write/delete ACL aligns with intended role; record rules and field groups reviewed |
| Company isolation | Every request supplies/validates the tenant database and allowed company context |
| Defaults/constraints | default_get, same-company relations, required combinations, and smoke tests pass |
| Reconciliation | Wrapper version/hash/URL/secret, no-op health check, guarded exact-match test, transaction-rollback and concurrent-duplicate clone evidence, and a least-privilege operating identity that cannot write server-action code pass |
| Reconciliation surface policy | No account.reconcile.model has auto-validate enabled; client users hold no accounting-mutation groups; alerting exists for new accounting-capable users |
| AP draft | Disposable vendor/draft/line/attachment create-update-read-cleanup passes |
| Posting | Separate disposable-clone posting/reversal plan passes before production enablement |
| Purchase | Purchase models, journal/vendor/product/UoM, permissions, and native confirmation behavior pass |
| Three-way matching | purchase_stock, warehouse, incoming picking type, stock location, route, receipt validation, bill link/readback pass |
| German B2B e-invoice receive | Company/localization, structured formats, production endpoint, Peppol receiver state or approved alternative intake, journal/Documents routing, original XML retention, valid/invalid/duplicate inbound fixtures pass |
| German B2B e-invoice issue | Partner format/endpoint verification, generated XML, credit/correction behavior, controlled recipient delivery, status readback, error/timeout handling, and retention fixture pass |
| Drift | Scheduled check compares snapshot time/schema, required fields, ACL, wrapper version/hash, health response, reconcile-model auto-validate state, and the accounting-capable user set |
Current database¶
| Capability | Status on accountify_v19_clone_21.06.2026 |
|---|---|
| Runtime snapshot | 764 models / 15,789 fields, generated June 29, 2026 |
| CRM | Installed (crm.lead) |
| Purchase | Installed and controlled smoke test passed |
| Inventory receipt | Installed and controlled smoke test passed for company 11 |
| AP draft coding | Controlled smoke test passed; no bill posted |
| Reconciliation automation management | Controlled Studio automation smoke test passed |
| German e-invoicing modules | account_peppol, account_edi_ubl_cii, documents_account_peppol, and German localization detected |
| German B2B receive/issue | Runtime surface verified; tenant-specific production registration and end-to-end fixtures still required |
| Website | Model absent from snapshot |
| Manufacturing | mrp.production absent from snapshot |
| Subscriptions | No subscription model detected |
Do not inherit capability across tenants
A passing test in this clone does not enable the same feature in another client's database. Re-run discovery and smoke tests with that tenant's integration identity and company configuration.
See German B2B e-invoicing for the separate receive/issue gates, Odoo fields, evidence contract, and rollout tests.