Order management for fulfilment: promising and sourcing an order

Availability is a calculation, not a stock figure

Promising a date requires knowing what is genuinely available, which means on-hand stock less what is already committed, plus expected receipts that will arrive in time, minus anything reserved for another channel or customer. Each of those components lives in a different system and changes at a different speed. The design decision is whether availability is calculated centrally from replicated data or requested from source systems at the moment of promising, and the answer trades accuracy against response time and coupling.

Sourcing rules and their unintended consequences

When several locations could serve an order, rules choose between them using proximity, stock cover, capacity, cost to serve, and service commitment. Simple rules produce predictable side effects: nearest-location logic strips stock from small sites, lowest-cost logic ignores whether the site can physically cope, and single-location rules split fewer orders but miss more dates. Sourcing is therefore an operational policy expressed in configuration, and it deserves periodic review against what it actually did rather than what it was intended to do.

Orchestration: splits, holds and changes after release

Real orders change. Lines get added, addresses corrected, quantities amended, payments held, items substituted, and part of an order may be despatched while the rest waits. The system has to track the order as a whole while managing fulfilment units that progress independently, and to know which changes are still possible at each stage. Once a pick has started in a warehouse, an amendment becomes a physical operation rather than a data update, so the cut-off rules between order management and the warehouse have to be explicit and enforced in both directions.

Cross-border orders carry obligations, not just addresses

Where the goods cross a customs frontier, the order must carry enough data to support a declaration downstream: classification, origin, value basis and the agreed delivery terms. Those terms decide who arranges and pays for transport and who is responsible for import formalities, so recording them as a structured field on the order, rather than as a note, is what allows transport and customs steps to be automated later. Specific duty and import tax treatment depends on the destination and should be confirmed with that authority.

The handover to execution

The interface to warehouses and carriers is where the design either holds or unravels. Each fulfilment unit becomes a warehouse order with a service level and a despatch-by time, and each despatch produces a transport requirement. Status must flow back at a granularity the order layer can interpret, and the identifiers used must survive the round trip. Where a third-party provider runs the warehouse, this interface is also a commercial boundary, and it is worth specifying event definitions in the contract rather than discovering divergent interpretations during peak.

Frequently asked questions

Does this replace order handling in an ERP?

It sits alongside it. Financial order records, invoicing and revenue stay where the accounts are kept, while fulfilment orchestration handles availability, sourcing and execution across sites and channels. The boundary must be drawn explicitly or both will claim to hold order status.

How should order splitting be controlled?

Treat it as a cost decision with a rule, not a by-product of allocation. Splits add packages, transport cost and customer confusion, so the rule should weigh the value of the earlier date against the extra despatch, and it should be measurable afterwards.

What breaks first when volumes grow?

Usually availability accuracy. Promising against stale replicated stock is tolerable at low volume and produces visible failures once several channels compete for the same units, which is when reservation logic has to become explicit.