Relationships and lifecycles
The model distinguishes durable facts, decisions, financial states, and process execution. One object may expose several status axes when those axes answer different business questions; projections describe a calculation at a point in time and invent no autonomous lifecycle.
Vue d’ensemble
Relationships are read first by functional family, then by object type.
| Famille | Objects | Role |
|---|---|---|
| Companies and relationships | company, contact, contact_role, company_group | Identify organizations, their contacts, and the relationships that structure their business roles. |
| Journeys | checkout_session, onboarding_case | Carry the durable business context of a checkout or onboarding case independently from process execution. |
| Checks and decisions | compliance_check, risk_score, approval_request, approval_assignment | Represent checks, scores, and approvals that produce reusable decision facts. |
| Sales and invoicing | order, invoice, invoice_balance, return, return_item, dispute, receivable, payment_term, due_date_schedule, line_item | Represent customer orders, invoicing, returns, disputes, due amounts, and receivable balances. |
| Credit | credit_limit, credit_exposure, effective_credit_limit, credit_availability_check | Define credit limits, measure exposure, and calculate available capacity at a point in time. |
| Payments and reconciliation | psp_payment, payment, payment_allocation | Track PSP payments, cash movements, payment allocations, and settlement commitments. |
| Purchasing and suppliers | purchase_order, supplier_invoice, payable, supplier_payment | Represent purchase orders, supplier invoices, AP liabilities, and disbursements. |
Do not conflate status axes
Un champ status must never become an ambiguous summary of different realities. When administrative lifecycle, commercial resolution, physical facts, or settlement evolve independently, the model exposes them on separate axes.
| Axe | Question | Exemples |
|---|---|---|
| Resource lifecycle | Does the object still exist as an active case or document? | return.status, dispute.status, invoice.status |
| Business resolution | What business conclusion was reached? | return.resolution_status, dispute.resolution_status |
| Settlement | What is the financial state of a document? | invoice.settlement_status, supplier_invoice.settlement_status |
| Faits physiques | What actually happened? | return.shipped_at, received_at, inspected_at |
| Process execution | Where is the orchestration handling the case? | derived `process_status` when the object is process-owned |
| Computed projection | What is the balance or capacity at this moment? | receivable, payable, effective_credit_limit, credit_availability_check |
Process-owned objects
Some business cases have a canonical process instance carrying their policy and orchestration. The resource preserves what must remain true even if the process is replayed, replaced, or fails.
| Objet | Responsibility split |
|---|---|
checkout_session | The session preserves checkout context and durable outcome; the process orchestrates the required steps. |
onboarding_case | The case preserves onboarding facts; the process carries collection, checks, and interactions. |
dispute | The dispute exposes the contested fact and its resolution without imposing suspension, reminder, or remediation policy. |
return | The Return preserves request, physical facts, and resolution; the process decides authorization, inspection, and remediation. |
The clearest example is the return : status describes the case, resolution_status the commercial conclusion, milestones describe logistics facts, and process_status separately reflects execution of the owning process.
AR and AP financial chains
Customer and supplier chains are symmetrical in principle without merging their objects. Buyer-side incoming cash remains a payment ; supplier disbursement remains a supplier_payment.
Sales / accounts receivable
order— carries the customer order and its lines.invoice— carries the financial document and due date.receivable— projects the balance owed by the buyer.psp_payment— tracks a payment or refund on the PSP side when a PSP is involved.payment— observes buyer-side cash movement, with or without a PSP.payment_allocation— explains how the financial source is allocated to business targets.
Purchasing / accounts payable
purchase_order— carries the order addressed to the supplier.supplier_invoice— carries the supplier financial document.payable— projects the balance owed to the supplier.supplier_payment— carries supplier disbursement and its lifecycle.payment_allocation— explains allocation of the movement to AP targets.
disputed, due et undisputed de receivable et payable expose analytical facts. A process then decides whether to remind, suspend, approve, or pay; the projection does not make that decision.Approvals: aggregated request and human decision
Une approval_request carries policy and aggregated lifecycle. Itsapproval_assignment assignments are embedded: each represents an approver solicitation and becomes a human decision only when it reaches approved ou rejected.
There is therefore no third approval_decisionobject. Administrative expiration or cancellation may resolve the request without fabricating a human decision.
Projections and embedded objects
receivable, payable, effective_credit_limit et credit_availability_checkare calculated snapshots. They have no autonomous identifier to progress through statuses.
line_item, return_item et approval_assignment are embedded in a parent context. Their semantics are documented with that parent rather than as an independently addressable resource.