Sales Order Sync in Practice: Wiring the Shipping Path from CRM to WMS
What This Strategy Solves
In many retail and manufacturing companies the order flow is "CRM takes the order → WMS ships it." Each side records its own order numbers, recipients, SKUs and amounts. After three months the inventory no longer reconciles, finance cannot match payments to orders, and business and accounting argue. This strategy moves sales orders from CRM into the WMS shipping module under a fixed set of rules, keeping status and key fields consistent on both sides and removing manual re-entry from the loop.
Data Flow and Field Mapping
Overall direction: CRM (source) → Qeasy integration platform (middle layer, cleaning and mapping) → WMS shipping module (target).
Key field mapping (typical retail order):
| Business meaning | Source field (CRM sales order) | Target field (WMS shipping order) | Handling rule |
|---|---|---|---|
| Order number | order_no | external_order_no | Pass through, used as idempotency key |
| Customer code | customer_code | receiver_code | Code mapping managed centrally |
| Recipient | receiver_name/phone/addr | ship_to_* | Header merged and sent down |
| Line items | items[].sku | items[].sku | SKU mapping via item cross-reference |
| Quantity | items[].qty | items[].qty | Negative values rejected |
| Amount | total_amount | order_amount | Currency unified to CNY |
| Remark | remark | memo | Truncated to 500 chars |
Centralizing the code mapping inside Qeasy's mapping table module (rather than scattering it across scripts) keeps long-term maintenance cost low.
How to Configure on Qeasy
Use the Qeasy CRM adapter on the source side to pull orders incrementally by last-modified time; add an "approved" status filter. On the target side, use the WMS shipping module adapter to write data.
Typical configuration points:
- Source: select CRM as the source system, pick the corresponding business object, set the incremental field (usually
last_modified_time), and for the first full backfill set the start time far earlier than any real order. - Target: select WMS as the target, choose "shipping order / sales outbound order" as the object, and set the write mode to "if external order exists then update, otherwise create."
- Mapping rules: drop the field table into Qeasy's field-mapping area. SKU and customer codes go through the mapping table, address fields go through expression merging.
- Dedup and idempotency: use
external_order_noas the primary key so Qeasy's duplicate detection blocks repeated pushes. - Exception handling: Qeasy's default retry is usually enough, but separate out "target returns 5xx / network timeout" for automatic retry, and route business errors (e.g. out-of-stock validation) to a manual queue.
Implementation Steps
Roll it out in phases; do not jump into full-volume plus high-frequency from day one.
- Phase 1: Full backfill (run once only). Trigger it manually in Qeasy to push historical orders to WMS in one shot. This step validates mapping and cleans dirty data on both sides. Set the incremental start time to the timestamp of the oldest historical order.
- Phase 2: Switch the incremental anchor. After confirming the backfill is clean, move the incremental field from "backfill start" to "now minus 5 minutes" to avoid pulling history again.
- Phase 3: Turn on scheduling. Retail scenarios usually run every 5–15 minutes depending on WMS write throughput; manufacturing shipping is lower frequency, 30 minutes to 1 hour is enough. Configure cron in Qeasy, then watch the 24-hour failure rate in production before tightening the interval.
- Phase 4: Status write-back (optional). If shipping/delivery status from WMS needs to flow back to CRM, start a separate strategy so it does not couple with the down-stream link.
Lessons Learned
- Classic mistake: forgetting to switch the incremental anchor. After a full backfill the polling jumps straight into incremental mode but the start time still points at the oldest historical record, so on day one every historical order gets re-pushed, WMS rate-limits, and duplicates explode. The safe move is to manually verify the latest pull timestamp when switching phases.
- Sending header and lines together makes failures hard to locate. We have seen customers POST the whole order in one shot; if any single SKU fails an out-of-stock check the entire order rolls back and manual remediation becomes painful. In Qeasy, send the header first and write each line separately so each line can retry on its own.
- Currency mismatch on the amount field. CRM stores local currency, WMS defaults to CNY; cross-border orders simply do not match. The mapping must do an explicit currency conversion; do not rely on the target's default.
- No idempotency key, double inventory deduction. Using the external order number as the idempotency key is the baseline; without it, network jitter leads to double sends.
- Logs only show successes, not failure details. When support only sees "100 orders synced successfully" but 30 failed due to stock-out, no one notices. In Qeasy, send failure details to an observability dashboard, grouped by error code.
When to Use and When Not to
Use when: the architecture separates CRM order capture from WMS shipping, daily order volume is in the thousands to tens of thousands, and there is already a working code cross-reference. Do not use when: the WMS side needs to edit orders heavily, orders originate from more than three mixed systems, or WMS write throughput is very low (<10 orders/minute) — in the last case, optimize the target system first instead of stacking more sync frequency on top.