Demo Commerce Network LLC: one order through every state

Demo Commerce Network LLC is a fictional omnichannel seller operating a web store, a marketplace channel, and two fulfilment nodes. Its base currency is AED; customers pay AED, SAR, and USD. The company sells batch-tracked cosmetics and ordinary home goods, accepts card and cash-on-delivery orders, and must reconcile gateway capture, courier remittance, marketplace commission, refunds, and stock.

Catalogue is not availability

The merchandiser creates product SKIN-CARE-SET-01 with title, description, variant, barcode, images, category, brand, price list, tax category, channel visibility, weight, dimensions, and active dates. The product can be published while stock is zero; publication means the item is discoverable, not that it is sellable. The channel’s availability service must subtract reservations, quarantine, safety stock, and stock assigned to another fulfilment node.

Field	Example	Why it matters
Product/variant code	SKIN-CARE-SET-01	Stable identity in orders and integrations
Channel	Web + marketplace	Determines price, commission, and order source
Price basis	AED inclusive of VAT	Controls displayed and stored price
Warehouse node	WH-DXB	Selects fulfilment responsibility
Reservation expiry	30 minutes	Releases abandoned checkout stock
Tax category	Standard VAT	Drives invoice tax components
Weight/dimensions	1.2 kg / carton size	Carrier quote and shipping label
Returnable	Yes	Determines return eligibility

An inactive product, unpublished price, missing tax category, or disabled warehouse can make checkout fail even when the item master exists. Test catalogue publication, price change, stock-out, reservation expiry, and channel disablement separately.

Cart, checkout, and payment states

The shopper adds two skincare sets and one lamp. The cart records product, variant, quantity, price snapshot, discount, shipping charge, tax, currency, customer, delivery address, and promotion reference. A price list change after cart creation must follow the configured snapshot policy; silently repricing a customer’s cart creates a dispute.

Checkout creates an order with customer, channel, order number, billing/shipping address, warehouse promise, lines, taxes, shipping, discount, total, and idempotency key. Payment is a separate state machine: initiated, authorised, captured, failed, cancelled, refunded, or chargeback. An authorised card is not cash in the bank; a captured payment is not necessarily settled by the gateway.

The gateway callback includes provider, event ID, order number, amount, currency, status, signature, and event time. Verify the HMAC signature against the raw request body and persist the provider event ID. If the gateway retries the callback, the same event must return the original result rather than create a second receipt.

Reservation-led fulfilment

When payment is captured, OSERP reserves two skincare sets at WH-DXB and one lamp at WH-AUH. The order is therefore split into two fulfilment tasks. Each task has node, pick wave, bin, batch/serial where required, quantity, pack status, carrier, tracking number, and promised date. The customer sees one order but the warehouse sees two physical movements.

The reservation report must distinguish:

On hand at Dubai            42
Existing reservations       18
New order reservation        2
Quarantine                   3
Available to promise        19

If the Dubai node cannot fulfil, the allocation service can re-source from Abu Dhabi or backorder according to policy. It must not issue stock from the wrong branch merely to make the order appear complete.

Pick, pack, and delivery

The picker scans the barcode and confirms the actual batch. Cosmetics use expiry and batch policy; the lamp does not. The packer records quantity, package ID, weight, carrier service, and packing exception. Delivery records dispatched quantity, transporter, vehicle or tracking reference, destination, proof of delivery, and delivery date.

A partial shipment leaves an open quantity. The invoice policy may bill on capture, dispatch, or delivery. The consultant must verify the configured stage matrix rather than assume that an order or shipment posts revenue. Inventory relief and revenue recognition can occur at different stages.

COD and courier remittance

A second order is cash on delivery. The courier collects AED 420 from the customer but remits AED 405 after an agreed AED 15 fee. OSERP must keep the balance attached to the courier until remittance is reconciled:

Customer order / COD due        AED 420
Cash collected by carrier       AED 420
Courier fee                     AED 15
Bank remittance                  AED 405
Residual to explain              AED 0

The COD backbone is not the customer payment chain. It identifies the carrier as the party holding money. A short remittance becomes an explicit adjustment or dispute, never an unexplained reduction of the customer receivable.

Marketplace settlement

The marketplace sends a weekly settlement: gross sales AED 50,000, commission AED 4,000, advertising AED 1,000, refunds AED 2,500, and bank payout AED 42,500. The settlement record stores marketplace account, period, currency, gross, fees by type, refunds, chargebacks, tax treatment, payout reference, and matched orders.

Gross order value is not the bank payout. The reconciliation report should show every order included, every fee, every refund, and every unmatched line. A settlement can be financially complete while one order remains operationally unfulfilled; those are different exception queues.

Return, inspection, and refund

The customer returns one skincare set. The return request records order, line, quantity, reason, customer evidence, pickup reference, and requested refund. The receiving node records batch, expiry, condition, inspection result, and disposition: saleable, quarantine, refurbish, or scrap.

Only saleable stock returns to available inventory. A refund records source payment, amount, currency, gateway reference, tax reversal, approval, and date. A return request is not a refund, and a refund is not proof that the product has been received.

Accounting and daily reconciliation

The GL Mapping simulation should cover card capture, COD collection, courier remittance, marketplace settlement, shipping charge, discount, refund, and chargeback. A simplified card sale may be:

Dr Gateway clearing / customer receivable  total
  Cr Product revenue                       net
  Cr Output tax                             tax

When the bank settles, the gateway clearing account clears. Fees post to the configured expense role. Refunds reverse the approved revenue/tax and return stock only when the physical disposition says it is saleable.

Operations dashboard

Question	Evidence
Are we overselling?	Available-to-promise minus active reservations
Where is each order?	Payment, fulfilment, shipment, delivery, and return states
What does the gateway owe us?	Captured minus settled minus fees/refunds
What does each courier owe us?	COD collected minus remitted minus approved adjustments
Which returns are stuck?	Pickup, receipt, inspection, refund, and disposition queue
Is margin real?	Revenue minus discount, tax, shipping, commission, refund, and product cost

Consultant challenge

Repeat this case for payment timeout and retry, duplicate webhook, split shipment, reservation expiry, substitution, cancelled order after capture, gateway chargeback, COD shortfall, marketplace fee change, expired batch return, and customer refund in a foreign currency. For each case record the request, idempotency key, state transition, stock effect, ledger effect, owner, permission, and customer communication.

Use this chapter with E-commerce operations, Inventory, Sales lifecycle, Advanced GL Mapping, and the API Library.