Skip to main content
Talk to an expert
TechnologyOMS

OMS integrations for ecommerce operations.

OMS is where the order graduates from intent to operations: allocation, fulfilment, partial dispatch, returns. iWeb integrates ecommerce with the OMS that already runs the business, or builds OMS behaviour into the platform when there is not one.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
Contents · 6 sections
  1. 01Common problems and patterns.
  2. 02Selected case studies.
  3. 03How this system fits next to commerce, PIM and ERP.
  4. 04Questions we get asked.
  5. 05Clients we build for.
  6. 06Where this fits in the wider estate.
01 · Common problems and patterns

Common problems and patterns iWeb sees.

Allocation
Stock allocated against the right location, depot or branch, with safety thresholds and back-order rules honoured.
Partial dispatch
Orders that ship in multiple parts, with customer-visible status that matches reality.
Click-and-collect
Collect-by-time honoured against branch capacity and stock, not against an optimistic estimate.
Returns
Returns recorded once, reflected in stock, refunds processed against the original tender.
Order state customers can trust
Order state on storefront and emails matches what operations actually did. No silent divergence.
Where OMS lives in the estate
OMS sits between ecommerce and ERP/WMS. iWeb makes the boundary explicit rather than smearing logic across the stack.
Multi-channel order capture
Storefront, marketplace, telesales and in-branch orders converging into one OMS with consistent SLAs.
Promise and cut-off engines
Cut-offs, carrier choices and delivery promises driven by OMS capacity, not by a static rule buried in the CMS.
Reservations and back-order
Stock reservations, back-order rules and pre-order behaviour honoured consistently across channels.
Operational monitoring
Throughput, allocation failures and stuck orders surfaced as visible signals with on-call ownership, not as silent backlog.
Ownership and support
OMS owned as a first-class part of the platform, with named owners on both ecommerce and operations sides.
Honest OMS-vs-platform decision
Where the operation runs cleanly on commerce-platform order behaviour, iWeb will say so and avoid introducing an OMS without operational reason. The trigger is multi-location, partial dispatch or complex returns.
02 · Related work
03 · Integration and operational context

How this system fits next to commerce, PIM and ERP.

Where this system lives in the estate
The integration boundary with commerce, PIM, ERP and operational systems named, versioned and observable, not implied by a connector setting.
Catalogue and PIM separation
Catalogue truth lives in PIM. This system reads from PIM rather than maintaining a parallel product record that drifts away from it.
ERP boundary and commercial data
ERP still owns price, stock and accounts. This system orchestrates around the ERP rather than replacing it; the boundary is the design decision.
Storefront and customer surface
How customers see the output of this system on the storefront (search, content, order state, payments) governed with the same rigour as the commerce platform itself.
Real-time vs scheduled sync
Read paths cached at the storefront boundary, writes posted through monitored queues, reference data refreshed on a defined cadence tuned to ERP and PIM load.
Multi-territory and locale handling
Locale-aware behaviour wired in early, not bolted on per project. Translation, currency and per-market rules belong inside the platform rather than the storefront.
Governance and editorial workflow
Approval, completeness and audit workflows that match how the merchant actually edits, releases and runs the estate day to day.
Operational telemetry
Throughput, failures, queue depth and reconciliation reports surfaced as visible signals with on-call ownership, not as silent backlog.
AI under governance
AI features (query understanding, attribute mining, recommendations) scoped to where they earn their place, with decision logs and override controls.
Long-term support and incident response
Releases, incidents and upgrades governed under the same operating model as the wider estate, with a written runbook the on-call team can act on.
Takeover and stabilisation
Inherited builds audited, stabilised and documented before any larger change. The first month on support is deliberately conservative on change.
Honest vendor independence
iWeb names the right tool for the brief rather than the closest partner badge. Decisions are written down with their trade-offs, not assumed.
04 · Questions we get asked

Questions we get asked.

When does a dedicated OMS actually matter?

When orders ship in parts, allocation crosses multiple locations, or returns are routine. Smaller single-warehouse operations often run OMS behaviour inside the commerce platform.

Where does the OMS sit relative to ERP and commerce?

Between commerce and ERP / WMS. Commerce captures intent; the OMS owns the fulfilment lifecycle; the ERP owns finance. Each system stays responsible for its own data.

Which commerce platforms does the OMS pattern sit alongside?

The pattern is platform-agnostic. iWeb has direct project experience integrating OMS behaviour with Adobe Commerce and Magento, and the same boundary works for other commerce platforms where the connector and project shape align.

What should not live in the commerce platform when there is an OMS?

Pick paths, partial-dispatch logic and multi-warehouse allocation. Trying to model these in the storefront cart usually leaks operational state across systems and is hard to support.

How does B2B trade order state differ here?

Account orders often need approval steps, credit checks and partial release. Those belong in the OMS or ERP, with the storefront reflecting state rather than making the decision.

When is a dedicated OMS overkill?

Single-warehouse operations with simple fulfilment, where the commerce platform and ERP already cover the order lifecycle. Adding an OMS in that case adds surface area without commercial return.

Which OMS systems does iWeb work with?

The decision is client-led. iWeb integrates against the OMS the operation already runs or has chosen, with the same boundary principles regardless of vendor.

How does the OMS connect to PIM and ERP?

Through governed boundaries. PIM keeps attributes and channel rules. ERP keeps finance and accounts. OMS owns the fulfilment lifecycle. Each system stays responsible for its own data.

Can iWeb take over an existing OMS integration?

Yes. The team reads the existing integration, allocation rules and incident history first, then writes down what to keep, stabilise or change. The first month on support is deliberately conservative on change.

How is OMS integration cost scoped?

By the number of in-scope flows, the OMS chosen, the number of channels and the support model. iWeb brackets cost honestly in scoping rather than against a default template.

Where does customer-visible order state live?

In the OMS, not in the storefront cart. The storefront reads order state from the system that actually did the work, so customers see what operations see.

How are stuck or failed orders surfaced in production?

Throughput, allocation failures and stuck orders are surfaced as visible signals with on-call ownership, not as silent backlog. The runbook covers triage and resolution.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Got a brief on oms?

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see erp integrations →