Online store and warehouse integration must connect the full order lifecycle, not merely two stock tables: product publication, availability check, reservation, picking, dispatch, cancellation and return. If a site receives only a total quantity once a day, it can still sell an item already reserved by a sales manager or held for inspection.
A reliable design begins by naming the owner of every data type. The warehouse controls physical and available stock, the storefront captures the customer's order, and the order-processing flow controls reservation and fulfilment state. Integration carries changes between them and confirms that each change was accepted.
Separate stock into meaningful states
The statement “twelve in stock” is not enough. Some units may be damaged, reserved, undergoing return inspection or unavailable at a particular location. The storefront should promise only the quantity that can genuinely be allocated to a new order.
| Measure | Meaning | Use |
|---|---|---|
| Physical stock | Units actually present in storage locations | Warehouse operations and counts |
| Reserved stock | Units allocated to accepted orders | Prevention of overselling |
| Unavailable stock | Damage, quarantine or return inspection | Excluded from sale |
| Available to sell | Physical stock minus reservations and restrictions | Storefront and basket validation |
Agree the availability formula before development. It may include a confirmed incoming quantity when the business deliberately sells backorders, but an unconfirmed supplier purchase should not silently become sellable stock.
Assign one master source to each field
Conflicts occur when price, name or stock can be edited independently in both systems. The last save then overwrites valid data by accident. Each field needs an authoritative source and an allowed direction of travel.
| Data | Recommended source | Direction |
|---|---|---|
| SKU, unit and core product name | Catalogue or ERP | To the online store |
| Description and SEO content | Online store | Normally not returned to ERP |
| Price and discount rules | Approved pricing system | To sales channels |
| Available quantity | Warehouse | To the online store |
| Order and customer details | Online store | To fulfilment |
| Reservation, picking and dispatch | Warehouse | Back to the channel and sales team |
Do not depend on one nightly export
A large catalogue can be reconciled in batches, but critical changes should be event-driven. A new order, cancellation, shipment or stock adjustment changes what can be promised now. These events should be sent immediately or through a short durable queue that retries temporary failures.
Periodic reconciliation is still required because it finds missed events and discrepancies after incidents. The practical design is operational events plus scheduled control totals, rather than choosing only one method.
What should happen when an order is placed
- The store rechecks price and availability before confirmation.
- It creates an order with a unique external identifier.
- The fulfilment system accepts that order once, even if the request repeats.
- Stock is reserved and confirmation is returned.
- Picking and dispatch update the order and physical stock.
- Cancellation releases the reservation; a return stays unavailable until inspected.
Stable identifiers and idempotency prevent duplicates. If the store loses a response and retries, the receiver must return the original result instead of creating another order.
Map meanings rather than copying status labels
The storefront may have “processing”, while the warehouse distinguishes “awaiting pick”, “picking” and “checked”. Customers do not need every internal step, but each customer-facing state must correspond to a defined fulfilment condition.
| Event | Warehouse action | Sales channel state |
|---|---|---|
| Order accepted | Reservation created | Confirmed |
| Picking started | Task assigned | Processing |
| Dispatch confirmed | Units removed from location | Handed to delivery |
| Order cancelled | Reservation released | Cancelled |
| Return inspected | Restocked or quarantined | Return processed |
Treat integration errors as business exceptions
“Exchange failed” is useless unless it identifies the object, stage, retry option and responsible person. Unknown SKU, invalid warehouse, price conflict and insufficient availability need different responses. A technical success response also does not prove that the business operation was completed correctly.
Use an exchange journal, retry queue, assigned exceptions and daily reconciliation of order counts, amounts, reservations and shipments. That makes silent loss visible.
Pre-launch checklist
- assign the master source for every field;
- approve the available-stock formula;
- describe create, amend, cancel and return scenarios;
- map system statuses by meaning;
- test repeated requests without duplicates;
- test an outage on either side;
- schedule stock and order reconciliation;
- assign an owner for unresolved exceptions.
The integration is ready when it survives retries, delays, cancellations and partial failures without manual reconstruction of every transaction. The Business Reactor catalogue module can provide a shared basis for product, availability and order execution across sales channels once the exchange rules and ownership boundaries are agreed.
