OMS for an online store: when you need a separate system

An OMS for an online store is not needed simply because sales are growing. A separate order management system is justified when the website, marketplaces and warehouses can no longer jointly decide who gets the stock, where to ship it from and what to do after an order changes. If the existing platform or ERP handles these rules reliably, an additional product may only complicate operations.

Start with a conflicting scenario: who gets the last unit ordered simultaneously on the website and through another channel? Below are decision criteria, system responsibilities and a pilot plan.

Where synchronization ends and orchestration begins

Synchronization transfers data: a new order reaches the accounting system and the stock level updates on the website. Orchestration determines the sequence of actions: check availability, allocate stock, select a warehouse, release a picking task and respond to a rejection. A shared decision across several channels, rather than another order list, is what an OMS addresses.

A hypothetical example: the website has accepted payment for a bundle, but a marketplace reserved one component earlier. A second warehouse has the required item, but a separate delivery would change the agreed terms. A defined rule is needed: split the shipment, offer a different delivery time or send the exception to an operator. Updating stock levels alone does not answer this question.

Collect recurring failures: manual warehouse reassignment, selling unavailable items, stuck reservations and partial cancellations. Record the cause, owner and consequence of each. An incorrect SKU or an undelivered event should be fixed in the data or integration, not by buying a new system.

What remains in the ERP, WMS and commerce platform

Before choosing a product, agree on the owner of each decision. An ERP usually handles accounting and financial documents, a WMS handles warehouse operations, and the commerce platform handles checkout. An OMS can coordinate fulfillment between them. This is an architectural agreement, not a universal property of the labels: individual products overlap in functionality.

For example, Shopify's routing documentation describes sequential location-selection rules, including minimizing split fulfillments. Multiple warehouses therefore do not in themselves demonstrate a need for a separate OMS. Compare your scenarios, not the number of features in a presentation.

A Drupal store does not necessarily need to control every operation. When designing a web system and its integrations, identify the owner of the confirmed order state. If the website and ERP independently authorize shipment, a new interface will not remove the contradiction.

Stock reservations: on-hand quantity is not availability

Stock reservation ties available quantity to a specific commitment to a customer. The item is physically still on the shelf, but must no longer be promised to another order. Distinguish recorded stock, quantity available for sale and confirmed reservations, rather than exchanging a single “in stock” field between systems.

A single decision point for availability

Microsoft Inventory Visibility describes soft reservations: the service checks availability, reduces the quantity available for subsequent reservations and returns a reservation identifier. Physical stock does not necessarily change at that point. To protect against double-booking, all relevant channels must use the agreed mechanism, rather than merely receiving periodic copies of stock levels.

This does not mean that any integration guarantees there will be no overselling. Separately agree on the behavior of a channel that cannot request an immediate reservation: a limited stock pool, safety stock, or order acceptance without final confirmation. Customers should not be promised guaranteed availability if it has not yet been technically verified.

The reservation lifecycle

Define when a reservation is created and the conditions for extending and releasing it. An unpaid cart, a confirmed order and goods being picked require different rules. After cancellation, the reservation must restore availability; after shipment, it must correctly transition into an actual stock deduction without reducing quantity twice.

Adobe Commerce describes compensating reservations for cancellations and changes to salable quantity. This is an example of a specific implementation, not instructions for every platform. Your architecture needs its own event table: which action changes the reservation, stock and status, who confirms it and how an unfinished transition is detected.

Order routing must account for the customer promise

Order routing means choosing where and how an order will be fulfilled, not just the nearest warehouse. First check constraints: available goods, an eligible carrier, order cut-off times and the ability to assemble a bundle. Then apply priorities: avoid splitting the cart, avoid overloading a location and meet the agreed delivery time.

The order of rules changes the result. Shopify applies them sequentially; its closest-location rule uses straight-line distance, which is not the same as a driving route. Geographic proximity alone therefore does not guarantee cheaper or faster delivery. In the pilot, test the actual constraints of your logistics, not just the warehouse address.

Describe partial fulfillment separately. If some items have already been released to a warehouse, a subsequent address change or cancellation must not silently overwrite the previous task. You need confirmation of the stop, a new decision about the remaining goods and a clear message to the customer. Refunding money and returning goods to sale are different processes.

Operators need an exception queue with the reason, permitted action and decision history. They must see whether a location can be changed, whether customer approval is required and whether packing has already begun.

How to test the need for an OMS before a major implementation

A pilot must test the business decision end to end, not just the transfer of a test order. Select a limited set of products, channels and warehouses with a specific conflict. Agree in advance on the expected outcome of each scenario, the logs that will confirm it and the authority to stop the test.

1. Map SKUs, units of measure and location identifiers across all systems. A bundle and its components must not accidentally be counted as independent stock.
2. Submit simultaneous requests for the last unit from different channels. Check who received the reservation and what response the other customer received.
3. Resend the same payment or order-creation event. A retry must not create a second order or an additional stock deduction.
4. Disable one data-exchange channel and then restore it. Check event order, redelivery and the absence of lost changes.
5. Perform a partial cancellation, split shipment and return. Check money, the reservation, physical stock and customer messages separately.
6. Simulate a warehouse rejection after routing. Make sure the order is either safely reassigned or sent to the responsible operator.
7. Reconcile results against the source systems and rehearse rollback. Returning to the old process must not leave duplicate active reservations.

Measure the time from order acceptance to a confirmed reservation, manual interventions, availability discrepancies and unfinished transitions. Set thresholds for your operational requirements rather than borrowing them from someone else's case study. If fixing a single connector or the platform rules is sufficient, that is a valid pilot outcome.

Risks of a new management layer

The greatest danger is adding another source of contradictory statuses. Preserve order, line-item and reservation identifiers across systems. Reprocessing a message must be idempotent: the same event must not create a duplicate business action. Delayed messages need version rules or rules for permitted state transitions.

Do not move every historical error into the OMS. Determine which active orders move to the new layer and which finish in the old one. Restrict manual changes through access permissions, record the reason for intervention and regularly reconcile reservations against fulfillment. Automation without an owner for exceptions only accumulates unresolved situations faster.

Also assess vendor dependency: event-log access, state exports, integration limits and recovery procedures after failure. An OMS will not fix inaccurate warehouse records or an inconsistent returns policy. If the team cannot yet formulate these rules, work on the process first.

What determines the timeline and cost

The timeline involves more than installing software. It requires process documentation, cleaning master data, access to test environments, building data exchange, scenario testing and operator training. Arranging marketplace access or confirming a third-party warehouse's capabilities can become a critical dependency even when your own development is complete.

Plan checkpoints instead of guessing a date

Divide the project into rule agreement, a technical prototype, a pilot and expansion. Each transition needs evidence: an approved state model, a reproduced reservation conflict, correct recovery of data exchange and operator readiness. Refine the full-launch date after checking the riskiest integrations, rather than tying it to a universal timeline from a market overview.

In the estimate, separate licensing or subscription, business analysis, connectors, migration of active orders, testing and launch. Recurring costs include infrastructure, monitoring, maintaining data exchange, partner API changes and rule development. Compare total cost of ownership with improving the existing platform for the same scenarios.

The decision: buy an OMS or strengthen the existing system

A separate OMS makes sense if several independent channels need shared control of reservations and fulfillment, while existing tools fail the agreed tests. If the problems disappear after fixing data, a connector or routing rules, a separate product is not yet essential. The selection criterion is a controlled order lifecycle, not the name of a system category.

For a discussion with GL.ua (Glyanec), prepare a map of channels and warehouses, a list of integrations and examples of failures without personal data. Discuss the online store architecture and integrations to define the pilot boundaries and compare a separate OMS with developing the existing solution before choosing a product.