How do I set up a warehouse management system for real-time stock sync and backorder handling?

Setting up a warehouse management system (WMS) for real-time stock sync and backorder handling is mostly about getting your inventory source of truth, event flow, and order allocation rules right.

Here’s a practical setup approach.

---

1) Define the systems and the source of truth

You usually have:

• WMS: warehouse operations, picking, packing, receiving, bin/location management
• ERP/Inventory service: authoritative stock records
• OMS / eCommerce platform: order capture, customer-facing availability
• Shipping system: labels, tracking, carrier updates

Pick one system as the inventory authority

For real-time sync, decide which system owns:

• On-hand stock
• Reserved stock
• Available-to-promise (ATP)
• Backordered quantity

Most commonly:

• WMS owns physical counts and bin movements
• Inventory/OMS owns ATP and reservations
• eCommerce reads ATP from OMS/inventory service

---

2) Model inventory correctly

Track these separately:

• On hand: physically in warehouse
• Reserved/allocated: assigned to open orders
• Available: on hand minus reserved minus safety stock
• In transit: inbound PO stock not yet received
• Damaged/quarantine: not sellable
• Backordered: demand waiting for future stock

Minimum data model

For each SKU and location:

• SKU
• Warehouse/location/bin
• On hand qty
• Reserved qty
• Available qty
• Backordered qty
• Safety stock
• Reorder point
• Lot/serial if applicable
• Timestamp/version

Use versioning or event timestamps to prevent stale updates.

---

3) Use event-driven real-time sync

Instead of batch updates every hour, sync with events:

Key inventory events

• Receipt posted
• Putaway completed
• Pick confirmed
• Pack confirmed
• Shipment confirmed
• Adjustment posted
• Transfer in/out
• Return received
• Order reserved
• Reservation released
• Backorder created/fulfilled

Recommended pattern

1. WMS writes inventory change
2. WMS emits event
3. Inventory service updates master record
4. OMS/eCommerce receives updated ATP
5. UI reflects new stock almost instantly

Use:

• Message queue / event bus: Kafka, RabbitMQ, SQS/SNS, Pub/Sub
• Webhook if low volume, but queues are more reliable
• Idempotency keys to avoid duplicate processing
• Retries + dead-letter queue for failed syncs

---

4) Implement reservation and allocation logic

This is the core of backorder handling.

Reservation flow

When an order comes in:

1. Check ATP
2. Reserve stock if available
3. If partial stock only, reserve what’s available
4. Put the remaining units into backorder

Allocation strategies

Choose one:

• FIFO by order time: fair and simple
• Priority-based: VIP, channel priority, SLA
• Warehouse proximity: allocate from closest warehouse
• Batch allocation: reserve in waves for operational efficiency

Important rule

Do not let two systems independently reserve the same inventory.
Reservations should happen in one place, with atomic locking or transactional updates.

---

5) Backorder handling design

Backorders should be explicit records, not just “negative stock.”

Backorder record should include:

• Order ID
• SKU
• Backordered qty
• Original requested qty
• Reserved qty
• Expected replenishment date
• Priority
• Customer notification status
• Fulfillment status

Backorder workflow

1. Order exceeds available stock
2. Create backorder line for shortage
3. Notify customer/CS team
4. Monitor inbound stock or replenishment
5. Auto-allocate stock when inventory arrives
6. Convert backorder to reserved/picked
7. Optionally split shipment if partial stock is available

Options for handling backorders

• Hold full order until complete
• Ship partial now, backorder rest
• Split by warehouse availability
• Cancel after SLA timeout
• Preorder-style fulfillment if product is not yet available

---

6) Build real-time stock synchronization rules

Sync directions

You need to define flows for both directions:

Warehouse → inventory/OMS

• actual stock changes
• receipts
• picks/shipments
• adjustments

OMS/eCommerce → WMS

• new orders
• cancellations
• reservation release
• changed quantities
• customer address changes if relevant to routing

Conflict handling

Use:

• Optimistic locking on inventory rows
• Event sequence numbers
• Last-write-wins only when safe
• Reconciliation jobs for exceptions

Reconciliation

Even with real-time sync, schedule periodic audits:

• compare WMS counts vs inventory service
• compare shipped orders vs reserved orders
• correct drift
• investigate failed events

---

7) Set up warehouse operational workflows

A WMS works best when every physical process is scanned and timestamped.

Core workflows

• Receiving
• QC / inspection
• Putaway
• Replenishment
• Picking
• Packing
• Shipping
• Cycle counts
• Returns processing

Scanning discipline

Use barcode/RFID scanning at:

• receipt
• bin putaway
• pick
• pack
• ship
• count

This gives real-time status changes and reduces sync errors.

---

8) Include safety stock and ATP calculation

Available-to-promise formula

A common formula:

ATP = On hand - Reserved - Safety stock + Inbound confirmed - Damaged/quarantine

You can tune by channel:

• ecommerce
• retail
• wholesale
• marketplace

Safety stock

Keep a buffer to avoid overselling due to:

• lag
• shrinkage
• damaged goods
• late receiving

---

9) Handle partial fulfillment and split shipments

If an order contains multiple SKUs or quantities:

• reserve what is available
• backorder the shortage
• allow partial shipment if business permits

You should support:

• order lines with mixed states
  • reserved
  • picked
  • shipped
  • backordered
  • canceled

This prevents the whole order from blocking due to one unavailable item.

---

10) Design APIs/events you’ll need

Inventory API

• GET /inventory/{sku}
• GET /inventory/{sku}/availability
• POST /reservations
• POST /reservations/release
• POST /adjustments
• POST /receipts
• POST /shipments/confirm

Order/backorder API

• POST /orders
• POST /orders/{id}/allocate
• POST /backorders
• POST /backorders/{id}/fulfill
• POST /orders/{id}/cancel

Event examples

• inventory.received
• inventory.reserved
• inventory.released
• inventory.shipped
• order.backordered
• order.fulfilled

---

11) Pick the right technology stack

A common robust setup:

• WMS: existing SaaS or custom app
• Database: PostgreSQL/MySQL for transactions
• Event bus: Kafka / RabbitMQ / SQS
• Cache: Redis for fast availability reads
• OMS: custom or ERP module
• Integration layer: middleware/iPaaS or custom API service

High-traffic note

If stock checks are frequent, use:

• Redis for fast read-through ATP
• DB as source of truth
• event consumer to keep Redis updated

---

12) Avoid common failure points

Problems to prevent

• Overselling due to delayed sync
• Duplicate reservations
• Negative stock without audit trail
• Backorders not auto-fulfilled
• Manual adjustments bypassing event updates
• Race conditions during peak traffic
• No reconciliation after message failure

Best practices

• atomic reservation transactions
• idempotent events
• audit logs for every inventory mutation
• monitoring for event lag
• alerts on negative stock, sync failures, and stale inventory

---

13) Suggested implementation sequence

Phase 1: Foundation

• define inventory states
• select source of truth
• create reservation model
• integrate order intake and stock updates

Phase 2: Real-time sync

• add event bus
• connect WMS, OMS, ecommerce
• use inventory cache for ATP

Phase 3: Backorder logic

• create backorder entities
• partial allocation
• fulfillment when stock arrives
• customer notifications

Phase 4: Hardening

• retries, DLQ, reconciliation
• audit trails
• cycle count workflows
• monitoring and alerting

---

14) Simple reference flow

Order arrives

1. OMS receives order
2. Inventory service checks ATP
3. If enough:
   • reserve stock
   • send pick task to WMS
4. If not enough:
   • reserve what’s available
   • create backorder for rest
   • notify customer
5. When replenishment arrives:
   • receive stock
   • auto-allocate to backorders by priority
   • generate pick tasks

---

If you want, I can also provide:

• a system architecture diagram
• a database schema
• an event/API design
• or a step-by-step implementation plan for Shopify + WMS + ERP