Decisions: Orders with Lifecycle

The key decisions behind the Orders with Lifecycle design, in plain language, and the industry research that shaped them.

DEC-01 — Holds on demand live order-side

Decision. An order line holds the production requests it services; the demand side does not know which order (if any) holds a request.

Why. Keeping the reference on the holder means demand stays a simple, self-contained layer that the kanban loop feeds without any awareness of procurement. “Is this request already spoken for?” is answered by asking the order side. It also means a request can be serviced by no order at all (blind receiving) without demand needing a special case, and that an order’s holds are released simply by the order ending — no line-by-line cleanup on the demand side.

DEC-02 — Cancel is draft-only

Decision. An order can be canceled only while it is still a draft. Once submitted, it cannot be canceled in this version.

Why. Canceling a submitted order retracts a commitment already made to an outside party — reversing vendor communication, in-flight production, and expectations. That is genuinely hard and situation-specific, so it must not be a casually available button. If the capability is ever needed, it will be designed explicitly against concrete requirements rather than approximated now. Draft-only cancel needs no cleanup choreography: the draft’s production requests simply return to the queue.

DEC-03 — Received amounts accrue; open amounts are computed

Decision. Each line stores a received quantity that is accrued (added to) from actual production/receipt events; the open quantity is computed as confirmed-or-requested minus received.

Why. Storing received amounts as an accrual of real events — rather than a figure someone edits — makes the order an honest ledger of what has actually arrived, with over-receipt simply showing as a negative open amount. Computing the open amount rather than storing it removes a whole class of drift: there is no second figure to keep in sync. This mirrors how mature systems treat goods receipts as an append-only history (see the research below).

DEC-04 — The supplier freezes at submission

Decision. While drafting, the buyer may choose the supplier and override its details for this order; at submission a snapshot is recorded and the binding freezes.

Why. An order should be an accurate record of the commitment as it stood when it was placed. Freezing at submission means later edits to a supplier’s master record do not silently rewrite orders already sent. Allowing overrides while drafting — and a name-only supplier — keeps the buyer unblocked when a vendor is not yet fully set up.

DEC-05 — Four stored states, two computed views

Decision. The order stores Draft, Submitted, Closed, and Canceled. Confirmed and Receiving are computed views over Submitted, not stored states.

Why. The two labels users think of as “confirmed” and “receiving” are really readings of the order’s lines — every live line answered, or some line with received material. Computing them keeps the stored state model small and prevents the labels from getting out of step with the lines they summarize. It also lets “confirmed” be transient (a later receipt moves the order to Receiving) without any special transition handling.

Research that shaped the design

The design draws on how ordering works across mature procurement systems and interchange standards. This is the fuller survey behind the plain rationale above.

Header-and-line decomposition. Separating an order header from its lines, with the line as the unit of receipt, is the near-universal shape across procurement systems — the design follows it (a line is the grain of both confirmation and receipt).
Requested versus confirmed quantities. Electronic order-acknowledgment practice (the X12 855 order-acknowledgment and its EDIFACT counterpart) treats the supplier’s answer as a distinct, line-granular facet that can differ from what was requested. This shaped the Confirmation facet with its dispositions (accepted, changed, backordered, rejected, substituted, waived), separate from the requested quantity.
Receipts as an append-only ledger. Mature systems (for example SAP’s goods-receipt history) treat receipts as an accumulating history rather than an editable total. This shaped DEC-03 — received quantity accrues from events; open is computed.
Closure as a separate act. Distinguishing “fully received” from “closed” — so a buyer can deliberately close a line short — is standard practice; the design makes closure an explicit act, never an automatic consequence of a full receipt.
Agreement and release layering, deliberately not pursued. Systems that model blanket agreements with scheduled releases (for example SAP’s outline agreements) informed the explicit decision to not build an agreement/release layer in v1 — a discrete order only.
Amendment protocols, deliberately deferred. Interchange standards carry rich versioned-amendment mechanisms. The design records out-of-system revisions as notes rather than building a formal amendment protocol in v1 — a conscious divergence, tracked as a non-goal.

None of the interchange standards bind the design at the wire level; they are read as domain evidence for how ordering behaves, not as an integration requirement.