Order and inventory workflows connect when every commercial commitment maps to an explicit stock state and every fulfilment event updates the promise safely. The critical design is reservation, allocation, release, shipment, cancellation and return—not a generic “two-way sync.”
Define state authority and identifiers first. Then test duplicate, delayed and partial events so channels cannot oversell or hide stranded stock.
Define the promise
State which quantity each channel may offer, at what location, time and confidence. Distinguish on-hand, available-to-promise, reserved, allocated and in-transit.
Document priority between channels, customers and orders. Technology cannot resolve an implicit allocation policy.
Map the state chain
| Order state | Inventory effect | Release condition |
|---|---|---|
| Quoted/cart | usually none or soft hold | expiry or conversion |
| Accepted | reservation according to policy | cancel, allocate or expiry |
| Allocated | specific stock/location committed | pick, reallocate or release |
| Shipped | on-hand reduced and movement recorded | delivery/return |
| Cancelled/returned | release or condition-based receipt | inspection and disposition |
Choose system authority
Decide who owns order lifecycle, stock event, promise calculation, allocation and customer communication. Keep shared identifiers across order, line, item, location, reservation and shipment.
Avoid both systems independently changing the same state with last-write-wins behavior.
Design reservation
Define when reservation begins, whether it is soft or firm, quantity, expiry, partial behavior and release. Test abandoned carts, payment delay, manual order and priority customer.
Monitor stale reservations. They can create false shortage while stock remains physically present.
Design allocation
Specify location selection, lot/serial, substitution, split, backorder and manual override. Record why an allocation changed and its customer effect.
Test concurrent demand for the last available unit and failure after allocation but before acknowledgement.
Use an event contract
For each message define event ID, business ID, version, timestamp, source, state, quantity, unit and expected acknowledgement. Make processing idempotent.
Define retry, dead-letter/exception queue and who resolves it. Delivery does not prove business acceptance.
Synchronise product and location data
Define item, variant, unit, barcode, location and fulfilment capability before order events depend on them. Use stable identifiers and effective changes. Test inactive, replaced and channel-specific items.
A perfect order message cannot reserve stock when master mappings are ambiguous.
Control promise calculation
Document supply included, demand deducted, safety buffer, lead time, cut-off and channel priority. Show freshness and uncertainty to the ordering channel. Do not expose on-hand as available by default.
Test future receipts, backorders and constrained items. Record who may override promise and how the customer is informed.
Design payment and fraud timing
Decide whether reservation occurs before, during or after payment authorisation and risk checks. Define expiry and reversal. Avoid holding scarce stock indefinitely for abandoned or failed transactions.
Test delayed payment confirmation, duplicate callback and authorised order later rejected.
Manage order changes
Specify which states allow quantity, item, address or cancellation change and how inventory reservations update atomically. Keep the original and revised commitment understandable.
A change that succeeds in order software but fails in inventory must become a visible exception before fulfilment.
Handle distributed inventory
Define source selection, transfer, drop-ship, store fulfilment and split shipment. Include capacity and cut-off where they affect promise. Preserve per-line and per-shipment state.
Test reassignment after a location cannot fulfil. Release old reservations before creating new ones safely.
Communicate customer state
Map internal states to clear customer messages without exposing unstable technical detail. Send updates after accepted business events, not message dispatch alone.
Provide support with the same order, reservation and shipment evidence so customers do not receive contradictory answers.
Handle partial fulfilment
Trace line and quantity through split shipments, backorder, cancellation and invoice. Keep order summary consistent with stock and customer communication.
Do not mark the entire order shipped because one package left.
Design returns
Separate requested, received, inspected, restockable, damaged and disposed. Inventory availability changes after the relevant physical and quality event, not automatically at return authorisation.
Connect credit and replacement without losing item and order traceability.
Reconcile the chain
Compare accepted order quantity, active reservations, allocations, shipments, cancellations and returns by period and location. Investigate stuck and impossible combinations.
Use control totals plus case sampling. Grand totals can hide an oversold item and an unrelated surplus.
Pilot and operate
Use normal, last-item, partial, cancellation, duplicate event, interface delay and return scenarios. Monitor promise errors, stale reservations, exception age and manual correction.
Name order, inventory, integration and customer-communication owners. The connected workflow succeeds when a promise can be explained from current stock evidence through fulfilment.
Operate a daily exception reconciliation during stabilisation: orders without reservations, reservations without active orders, allocations not released, shipments without accepted confirmation and returns in unresolved condition. Give each exception a business owner and technical path. Reduce the cadence only after volumes and causes remain controlled.
Keep a versioned state dictionary and event contract beside support runbooks. When a new channel, location or fulfilment method arrives, review the whole promise chain before connecting it.
Rehearse recovery before the first peak trading period.
Document the accepted results for service and integration owners.
Review them regularly.