Order

What It Models

An order is the retained record of a sale after placement. It preserves purchased items and agreed policy while tracking billing, payment attempts, resource commitments, delivery progress and later changes. Accounting remains responsible for the receivable.

Identity and Attributes

The displayed order number is distinct from its record identity. Address, policy, price and purchase snapshots preserve the agreement; processing fields and quantities can still change through their workflows. Attempts and invoice links explain financial requests, while the money mirror reports Accounting's latest known position.

Relationships

A cart can originate one sale, and an amendment can originate a change order. Selling applications own product delivery and resource claims. Grants and after-sale documents reference the purchased lines. CRM supplies party records, and Accounting owns business units, invoices and financial movements.

Invariants

The database checks monetary arithmetic, quantity bounds, uniqueness and protected purchase snapshots. Service persistence checks lifecycle changes and records the history. Stable Accounting keys support request recovery; their guarantees depend on the receiving contract as well as Commerce's own records.

How It Is Stored and Shared

Orders owns the sale and its child records. Fulfilment owns delivery obligations, settlement plans and operational exceptions in the shared database. Other applications receive participant calls rather than direct ownership of order tables. The local event trail supports export and Order 360 without publishing business events or adopting Platform record history.

Open Design Questions

Closed is declared but has no current transition caller. Recovery gaps remain around deferred provisional-invoice deletion, amendment acceptance and installment reduction. The financial integrations need live evidence beyond fixture tests.