Sales Order Sync in Practice: Reliable Delivery Note Integration with WMS Outbound

What This Strategy Solves

In a pharmaceutical distributor's supply chain, sales orders are created and approved in the ERP system, which then generates delivery notes. The downstream WMS relies on those delivery notes as instructions for picking and outbound. On paper it looks like a simple push-and-receive, but in practice mismatches in customer codes, material codes, batch/expiry data, and owner or warehouse codes lead to the familiar "order exists in ERP, WMS does not recognize it" problem. We used the Qeasy data integration platform to carry this link, pushing delivery notes from the ERP into the WMS reliably.

Data Flow and Field Mapping

The overall flow is: ERP (source) → Qeasy integration platform (middle layer) → WMS (target). The source uses the executeBillQuery WebAPI to retrieve delivery notes; the target uses the ReqScmPktErp WebService to deliver the prepared payload to the WMS.

Key field mapping:

In the middle layer we apply a centralized code-mapping pattern, putting all cross-system translation tables for customer, warehouse, and owner in a single place. When either endpoint changes a code, only the mapping is updated — the flow itself stays untouched.

How to Configure It in Qeasy

In Qeasy this strategy is split into a source query node and a target execution node. Four configuration points matter:

1. Source side: call executeBillQuery, pull delivery notes filtered by a time window and document status; use FBillNo as the header key and FEntity_FENTRYID as the line key,
2. Target side: the WMS exposes a ReqScmPktErp WebService invoked via GET; key inputs are ERP_GROUPNO, ERP_CLIENTSID, ERP_WHSE_CODE, ERP_OWNERID, PT_ERP_OWNER, ERP_BILLHDRID,
3. Mapping and scripts: configure field mappings in Qeasy, route customer/warehouse through the mapping table, bind date/document number/line directly, and place any special transformation (prefix concatenation, line trimming, etc.) in the script node,
4. Idempotency and response check: use document number + line key as the idempotency key to prevent duplicate WMS writes, validate the WMS response, and push failed rows into the retry queue.

Implementation Steps

We rolled out the sync in three phases:

• Phase 1 — define the incremental baseline. Run a one-time historical full sync in Qeasy to backfill any delivery notes not yet pushed; this run becomes the comparison baseline for subsequent increments,
• Phase 2 — configure incremental scheduling. The source job runs every 5 minutes (*/5 8-22 * * *); the WMS-side job runs every 5 minutes offset (3-59/5 8-22 * * *). The offset avoids hitting both endpoints at the same instant,
• Phase 3 — go-live monitoring and exception handling. Turn on run logs, exception alerts, and the retry panel in Qeasy; observe for three full business days before tuning frequency, timeout, or batch size.

This dual-track full-and-incremental pattern is a common, safe path we see across pharma customers — one full sync as a safety net, then incremental runs for steady state.

Lessons Learned

A few issues we repeatedly see in customer projects:

• Pitfall 1 — no centralized code mapping. Hard-coding translations in scripts leads to mismatched numbers three months later, with mapping logic scattered across dozens of nodes. Safe practice: keep all cross-system code mappings in Qeasy's mapping table,
• Pitfall 2 — pushing header and lines in one shot. Large delivery notes timeout against the WMS interface. Safe practice: split header and lines into stages — header first, lines streamed afterwards,
• Pitfall 3 — coarse idempotency key. Using only the document number causes WMS-side row duplication and quantity doubling. Safe practice: combine document number and line key,
• Pitfall 4 — ignoring owner/warehouse semantic differences. A single "warehouse" in the source may map to "warehouse + owner + warehouse code" on the WMS side; the middle layer must complete that semantic translation,
• Pitfall 5 — one frequency for all hours. The same frequency during peak hours and at night overloads the source query queue at peak. Safe practice: schedule by time window (e.g. 8-22).

When to Use and When Not to Use

Use when: ERP is the system of record for sales, the WMS drives picking and outbound, and the delivery note must reach the WMS to start warehouse operations — typically in pharma distribution where both systems have stable interfaces and clear document/line keys for idempotency. Do not use when: the WMS demands real-time, second-level push (this design is batch-oriented at 5-minute granularity); or when multiple owners and warehouse networks exist and the coding system has not yet been unified.