Twelve desks, one optimistic button
Fictional buyer Fern Library orders twelve desks from Cedar Workshop. Six are ready now; six will be built next month. The purchasing screen offers a single button marked “Finish order.” Nobody agrees whether it means approve the request, dispatch the desks, issue a bill or record payment. The button is small. Its ambitions are not.
Order ORD-42 describes intended supply. It has a buyer, requested items and quantities. The workshop later issues INV-71 for the first six desks and INV-89 for the remaining six. This is one possible commercial workflow, chosen for this example. It is not a universal rule about how orders and invoices relate.
Draw the fork in the road
The diagram shows ORD-42 branching into two fulfilments and two invoices. That fork is the story. The order is not slowly transforming into an invoice, shedding its old identity like a caterpillar. Several records describe different parts of one commercial journey.
The registry distinguishes Order from Invoice. Both can contain commercial lines, with Order line and Invoice line describing their respective roles. The shared Commercial line item meaning helps compare entries without pretending that requesting six desks and charging for six desks are the same event.
Match quantities before joining totals
In the fictional records, order line OL-1 requests twelve desks at an agreed illustrative unit price of EUR200. Invoice line IL-1 bills six; IL-2 later bills six. Each invoice totals EUR1,200, with no other charges or adjustments in this simplified example.
If a report joins the full EUR2,400 order total to both invoices and sums the resulting rows, it reports EUR4,800 of ordered value. Nothing was sold twice. The join repeated a parent value. A useful mapping says which line or quantity an invoice covers, and how to avoid counting the same parent amount on each child row.
The invoice that arrived before the money continues from billing to payment evidence. Currency is part of the number explains why the EUR qualifier belongs in every calculation, even when every row currently happens to use it.
The buyer is another connection
Fern Library is the customer in this order. A staff member places it; a different team approves it; another organization might receive the delivery. A customerId can identify the commercial party without being a universal answer to “who did this?”
Customer is a role makes that distinction explicit. Person beyond the row follows the human across systems. A well-labelled relationship lets a reader discover those meanings instead of guessing from an integer that has been called userId since an early prototype.
Which day did the order happen?
An order-placement instant and a promised delivery date are also different facts. A customer can place an order late in one time zone while the warehouse has already entered tomorrow. A local cut-off for “next-day delivery” needs its business zone and calendar policy. Time zones and due today follows the clock rules; city identity keeps the delivery location from becoming a guess about them.
Let each milestone keep its name
Orders can be amended, cancelled, partially fulfilled or billed together with other orders. Some workflows have no order record at all. A model should publish the relationships it actually supports, including multiplicity and exceptions, rather than borrowing this example's two-invoice shape.
Cedar Workshop eventually retires “Finish order.” It records approval, supplied quantities, invoiced quantities and payment allocations separately. The graph is more detailed, but the questions get simpler: what was requested, what has been supplied, what has been charged, and what remains? Twelve desks are still twelve desks. The software has finally stopped asking one status to carry all of them.
