OMS, ERP or commerce platform: where should retail orders be controlled?

An online order contains a ₹1,200 shirt fulfilled by a store and an ₹800 mug fulfilled by a warehouse. The customer cancels the mug after the shirt ships. Commerce marks the order cancelled, the warehouse still shows a pick task, and finance sees the full ₹2,000 capture.

The architecture decision is where each business action is authorised and how its result is acknowledged. An OMS, ERP and commerce platform can all participate without competing to make the same cancellation or reservation decision.

Map authority before comparing products

A system of record can store a fact without being authorised to change it. For example, the ERP may store a payment reference while the payment provider establishes whether a refund processed. The service screen can present both without becoming the authority for either.

These assignments are design choices for the example. If the existing commerce platform can coordinate the required locations and exceptions, a separate OMS may add little. If the ERP already controls allocation and changes, duplicating those controls elsewhere can introduce competing writers.

Shopify's ERP integration overview illustrates common data exchanges. It is a starting point for interface scope, not evidence that a connector provides end-to-end order control.

Follow the split order through completion

The original order is ₹1,200 + ₹800 = ₹2,000. The store ships the shirt. The warehouse confirms that the mug's pick is stopped before dispatch. The cancellation coordinator approves the mug line's cancellation, releases its eligible reservation and creates one ₹800 refund instruction.

The resulting commercial value is ₹1,200, but financial completion is a separate state. Until the provider confirms the refund outcome, the order view should show the shirt shipped, mug cancellation accepted and refund unresolved. It must not infer a completed refund from a reduced order total.

If the warehouse rejects the stop because the mug shipped, that line follows the applicable return or intercept process. A commercial screen cannot make physically shipped stock available by changing a status.

Shopify's cancellation guidance makes cancellation dependent on order and fulfilment state, including restrictions for partially fulfilled orders and third-party fulfilment. This example is a system-neutral line workflow; it is not a claim that every platform exposes a native partial-cancel command.

1. Accept the orderShirt ₹1,200 plus mug ₹800; preserve line identities.
2. Allocate and fulfilStore and warehouse acknowledge their own reservations and shipments.
3. Coordinate the changeCancel the mug only after the warehouse confirms the stop.
4. Reconcile completionShirt shipment, mug stock release and ₹800 refund each have evidence.

Exception: A missing acknowledgement keeps that line unresolved; another system must not independently repeat the same action.

Compare three architectures with the same case

A commerce-led design suits relatively simple routing when the platform can express the required state changes and fulfilment integrations. Its limitation may appear in exception recovery or cross-channel visibility rather than ordinary checkout.

An ERP-led design can suit businesses where allocation, credit and fulfilment already run through the ERP. Check whether its response times, integration boundaries and customer-service view fit the commerce workload. Avoid making customer promises from a stale batch import merely because the ERP is authoritative for accounting.

An OMS becomes useful when multiple channels and fulfilment locations need coordinated allocation, splits, rerouting and changes. It brings another integration and operational responsibility. Ask which existing control it replaces, who runs its exception queue and what happens if it is unavailable.

Do not choose from a feature comparison alone. Give each candidate the same split order, duplicate cancellation, delayed shipment event and refund timeout. Require the demonstrator to show the persisted records and recovery path, not only a happy-path dashboard.

Make handovers recoverable

Every command needs a stable business operation identity, the target line and quantity, the expected state or version, and a result that can be queried. A timed-out request is uncertain until checked. The receiving system should reject stale or incompatible transitions rather than silently overwrite newer progress.

For local updates, state changes and outgoing work need a durable boundary. For external effects, use the provider's idempotency or lookup contract and retain unresolved cases. Do not claim that an event bus alone creates exactly-once business execution.

The ERP integration guide develops the integration scope; the refund guide develops financial completion. Operations owns service exceptions, engineering owns delivery recovery and finance owns money reconciliation.

Select the system that closes the handover

The right architecture makes authority and recovery clearer. It should reduce conflicting decisions while preserving the separate evidence behind stock, fulfilment and payment.

1. Map the decisions and their authoritative owners for one order lifecycle.
2. Demonstrate a split order and rejected cancellation in each candidate design.
3. Agree acknowledgement, timeout and reconciliation behaviour at every handover.
4. Pilot one channel-location combination before expanding routing authority.