Connect client websites, marketplaces, B2B workflows and supported external channels to one transaction-orchestration layer that validates demand, allocates stock, assigns fulfilment ownership, releases warehouse work, tracks documents and carriers, resolves shortages and synchronises final status.
Orders and Fulfilment does not replace the WMS. It decides what must be fulfilled, from which approved stock and by whom; Inventory and Warehouse Management executes the physical location, pick, pack and movement work underneath it.
The orchestration layer can route each approved transaction according to channel, inventory location, client policy, service level, geography and fulfilment ownership.
Send confirmed work to the client’s own warehouse, store, studio or dispatch team while keeping transaction status connected.
Route approved work to Vault or another connected managed operator where separately contracted and operationally available.
Route different lines or transactions to different facilities or operators based on stock, geography and configured rules.
The module connects channel demand to physical execution while preserving the distinction between commercial transaction state and warehouse movement state.
Capture approved channel demand and validate client, destination, lines, values, stock requirements and release conditions.
Reserve exact stock, choose source locations, assign fulfilment owner and split work where required.
Release pick, pack, documents, carrier and handover requirements to the selected operator and warehouse system.
Track delivery, cancellation, shortage, return initiation, failed handover and final status synchronisation.
Start with the complete fulfilment architecture, then move through source intake, validation, allocation, site routing, split fulfilment, warehouse release, documents, carrier handover, delivery, cancellation, return initiation and channel synchronisation.
Demand can originate from a client-owned website, marketplace, B2B workflow, assisted sales team or supported connected source. The orchestration layer converts those inputs into one internal fulfilment-ready structure.
No physical work should be released until the applicable client, destination, line items, commercial state, fraud or risk checks where configured and fulfilment requirements are sufficiently valid.
Bring approved demand sources into one orchestration structure.
Check the basic fulfilment context before allocating stock.
Confirm the applicable commercial state before physical release.
Stop incomplete or conflicting demand from entering warehouse execution.
Allocation should consider actual stock state, reservation state, source site, required dates, fulfilment capability and client policy before deciding where work is released.
Where one source cannot complete the full request, the system can support approved split fulfilment or route the shortage into an exception workflow instead of pretending the entire transaction is ready.
Connect each fulfilment line to the stock that can actually satisfy it.
Choose the approved facility and fulfilment owner.
Handle transactions that require more than one source or shipment.
Surface what cannot be fulfilled before warehouse release.
Once allocation is confirmed, the orchestration layer releases fulfilment work to the selected warehouse or operator with the exact lines, locations, service requirements and due milestones.
The WMS remains responsible for physical execution details, while Orders and Fulfilment tracks whether each fulfilment unit has progressed from release through dispatch and handover.
Create the operational fulfilment unit for the selected warehouse or operator.
Attach the applicable commercial and operational documents.
Connect the completed package to the approved handover route.
Keep one client-facing transaction understandable even when several fulfilment units exist.
Completion should reflect the real state of every fulfilment unit. A transaction should not appear fully completed while one package is still blocked, returned, cancelled or awaiting delivery.
Channel status should be synchronised only after the underlying operational state has been validated, with failures or mismatches routed into an exception queue.
Track the final handover state for each fulfilment unit.
Route requested changes according to how far fulfilment has progressed.
Start the correct downstream return or financial process without pretending the inventory is already recovered.
Keep originating channels aligned with the validated internal state.
The orchestration sequence keeps commercial demand and physical fulfilment connected without collapsing them into the same state machine.
Capture the approved source, client, destination, lines, values and requested service context.
Confirm required data, commercial state, approval and fulfilment eligibility.
Reserve the correct stock, choose source site and operator and resolve shortages.
Release pick and pack work, documents, package requirements and dispatch milestones.
Track delivery, collection, cancellation, failed handover or return initiation.
Update connected channels, surface failed sync and report fulfilment performance.
This module orchestrates demand, allocation, fulfilment ownership and status. The WMS controls physical locations, picking, packing, movement and stock accuracy.
Marketplace Connections moves approved catalogue, stock and transaction data between external channels and Commerce OS. Orders and Fulfilment handles what happens after demand enters the operating platform.
The implementation should identify who owns client-facing policy, who configures orchestration rules and who performs the actual physical work at each site.
The correct allocation, routing, documentation and completion logic depends on where demand originates, how stock is controlled and who owns physical execution.
The final architecture depends on channels, stock ownership, locations, service promise, warehouse systems, carriers, documents, return policy and integration scope.
No. Orders and Fulfilment orchestrates demand, allocation, routing and status. The WMS performs physical location, picking, packing, movement and stock-control work.
Yes, where the applicable channels are connected. Approved sources can feed one internal fulfilment structure while retaining their original source references.
Yes. Line-level allocation and split fulfilment can be configured, with multiple fulfilment units rolled up to the parent transaction.
Yes. Client-managed fulfilment can be used with client-owned warehouses and staff while Commerce OS coordinates demand and status.
Potentially. Managed operators can be connected where separately contracted, operationally available and supported by the agreed integration.
The shortage can route to an exception path such as alternate source, approved substitute, partial fulfilment, backorder, cancellation or manual review.
Yes, where configured. Packing slips, challans, invoices, labels or other required documents can be connected to the fulfilment workflow.
No. Return initiation only starts the downstream return process. Physical receipt, verification, condition review and the applicable recovery workflow determine when inventory can become available again.
Yes, where the connector supports it. Validated dispatch, tracking, delivery, cancellation or return status can be synchronised back to connected channels.
Failed or conflicting updates should remain visible in an exception queue with retry, ownership and resolution history.
We will map channel intake, validation, stock allocation, source sites, fulfilment ownership, split fulfilment, warehouse release, documents, carriers, delivery, cancellations, returns, exceptions and status synchronisation.
Login