Sales Order Sync from ERP to WMS: A Single-Strategy Implementation Guide on Qeasy
What This Strategy Solves
In a supply-chain integration project for a retail enterprise, the client runs two core systems side by side: an upstream ERP that handles order entry and billing, and a downstream WMS that handles outbound and fulfillment. The seemingly simple "sales order sync" routinely breaks in production: inconsistent encoding, wrong incremental anchors that cause missed orders, and header-line pushes that time out under load. This strategy delivers a stable pipeline that pushes ERP sales orders into the WMS outbound module following the business contract, configured end-to-end on the Qeasy data integration platform.
Data Flow and Field Mapping
The overall flow is: source ERP → Qeasy middleware → target WMS. The middleware handles three things: protocol adaptation, field transformation, and incremental state management.
Key field mapping (abbreviated):
| Business Meaning | Source ERP Field | Target WMS Field | Conversion Notes |
|---|---|---|---|
| Document number | bill_no | outbill_no | Pass-through; used as idempotency key |
| Customer code | cust_code | customer_id | Routed through the centralized mapping table |
| Warehouse code | wh_code | wh_id | Use primary code when multiple exist |
| Item code | item_code | sku_id | Shared mapping with the material master strategy |
| Quantity | qty | out_qty | No unit conversion; handled by the base master strategy |
| Unit price | price | sale_price | Do not aggregate to avoid billing conflicts |
| Expected ship date | req_date | expect_out_date | Normalize date format |
The encoding mapping is the most underestimated part of this solution. We have seen many sites scatter mapping logic across scripts, only to find three months later that the numbers no longer reconcile and no one can trace why. The reliable approach is to maintain it centrally in Qeasy's mapping module and share the same base table with the material and customer strategies.
How to Configure on Qeasy
On the Qeasy data integration platform, a sync strategy consists of four parts: data source, target source, transformation rules, and scheduling plan.
- Data source: Select the source ERP instance and configure the query entry. A typical pull view is "approved, not yet synced, last modified after the incremental watermark" sales orders.
- Target source: Select the WMS outbound interface and configure write parameters.
- Transformation rules: Introduce middleware scripts to handle field renaming, encoding mapping, date formatting, and idempotency key construction. It is recommended to use "idempotency key = bill_no" as the document-level deduplication basis to avoid concurrent retransmission.
- Scheduling plan: Adopt a "scheduled incremental + full-load compensation" dual-track model, which is a common pattern among Qeasy customers.
Implementation Steps
We usually split the rollout into three phases, each mapped to a release window:
- Set the incremental anchor: Freeze source-system data one day before go-live, export a "starting full snapshot," and write the starting timestamp into the Qeasy watermark variable. This is a baseline configuration; one mistake here means a full re-backfill.
- Trigger one full load: Manually trigger a full sync in Qeasy, verify that the transformation rules and target writes are correct, and only then switch to scheduled runs.
- Enable scheduling frequency: Choose the cycle based on volume. For low-volume projects, a 15-minute cycle is enough; for high-volume projects, a 5-minute cycle is recommended, with a "query window slightly larger than the cycle" as the missed-order safeguard.
Two additional rollout details deserve emphasis. First, header and line items should be phased in—stabilize the header first, then add lines—to avoid having N+1 details break the pipeline on day one. Second, monitoring alerts should cover both "watermark stall" and "document backlog" dimensions; the former indicates pull issues, the latter indicates target-side write congestion.
Lessons from the Field
- Wrong incremental anchor causes missed orders: A common mistake is using "current system time" as the anchor, which misses un-synced historical orders at go-live. The reliable approach is to use "the maximum modified time at 23:59:59 the day before" as the anchor, combined with a full-load compensation.
- Scattered encoding mapping: Hardcoded values in scripts, ad-hoc mappings, and temporary tables mixed together leave no one able to explain the mapping three months later. Centralized maintenance is the highest-ROI improvement.
- Missing idempotency key: Without deduplication on the WMS side, any source-side retransmission creates duplicate outbound orders. Using bill_no as the idempotency key is the safe default.
- Header and lines pushed together: When line count is high, a single pull times out and the pipeline stalls. Phased rollout dramatically shortens recovery time.
- Mismatch between cycle and query window: A 15-minute cycle with a "last 5 minutes" query inevitably misses orders. Setting the query window slightly larger than the cycle is a common pattern among Qeasy customers.
When to Use and When Not to Use
Use it for: standard sales order sync between a single ERP and a single WMS, with stable order structures and enumerable encoding differences. Do not use it for: cross-ERP aggregation, complex order splitting/merging, or sub-second real-time push scenarios—those need a dedicated channel.