Practical Guide: Syncing Wangdiantong Transfer Orders to Kingdee Cloud Direct Transfer Orders (WMS Callback)

What This Strategy Solves

The most common point of friction between a WMS and an ERP is the transfer workflow. Once a warehouse executes a transfer-out, stock status changes in real time, but the corresponding transfer document in the ERP may still be pending approval—or may not exist at all. The two sides go out of balance, and procurement, warehousing, and finance end up arguing.

In one of our retail client projects, the requirement was very clear: push audited, executable transfer orders from the WMS back into Kingdee Cloud to generate direct transfer documents, which then serve as the basis for inventory movement on the ERP side. This strategy is essentially a "WMS callback" channel, not a full bidirectional sync. It is intentionally lightweight, with a single purpose—resolving the timing mismatch of transfer data between the two systems.

Data Flow and Field Mapping

The flow is unidirectional: the WMS acts as the source, exposing a query interface that returns the transfer order header plus line items; Qeasy (the integration platform) processes the data in a middle layer; finally, Kingdee Cloud's batchSave endpoint creates the direct transfer document.

Key field mapping:

Encoding mapping (warehouses, organizations) is where this design most often breaks. A common practice among Qeasy clients is to centralize warehouse and organization encodings into a single mapping table rather than scattering them across scripts—when a new warehouse is added, only one place needs updating.

Configuring It in Qeasy

In the Qeasy data integration platform, this strategy is split into two platform connection actions:

Source side: register the WMS query interface, configure the pager and business parameters, and use the primary key field transfer_no for idempotent deduplication. The increment start point uses transfer_id to ensure only new/changed records are pulled each run.

Target side: register Kingdee Cloud's batchSave interface. Fixed values like document type, organization, and owner are configured directly in the platform; document number and date are taken from source fields using template variables such as {{transfer_no}} and {{created_date|dateTime}}.

We recommend two rules in the middle layer: first, perform warehouse encoding lookup via a mapping table; second, normalize the document date from the source-side field, to avoid ERP validation failures caused by timezone or string-format mismatches.

Implementation Steps

We suggest a three-phase rollout to avoid scrambling both ledgers with a single big bang:

Step 1—Establish the increment baseline. Pick a low-business window (usually month-start or weekend), choose a historical timestamp as the starting point for transfer_id, and from then on only sync increments.

Step 2—Trigger a full reconciliation. Once the increment stream is stable for a while, manually trigger a full backfill so historical transfer orders are idempotently written to the ERP by document number. Do not switch the regular schedule before the full backfill has finished.

Step 3—Move to steady-state scheduling. The source side runs every 50 minutes during business hours (e.g., minute 50 of each hour, 09:00–21:00); the target side runs slightly later (e.g., minute 3 of each hour, 09:00–21:00). This creates a staggered "source pull → target write" cadence so the load never piles up at one point.

Another reliable pattern is a "dual-track" approach: increments as the primary path for real-time needs, plus a daily full-volume run during the night window to repair any drift.

Lessons from the Field

1. Passing warehouse codes straight through — A classic mistake is writing WMS warehouse codes directly into the ERP, which either fails validation or creates junk data. The reliable approach is to centralize the encoding mapping and let the middle layer do the lookup.

2. Inconsistent date formats — The WMS sometimes returns dates with timezones, sometimes as raw strings. Kingdee Cloud is strict about date formats. Always normalize explicitly in the middle layer instead of trusting the source.

3. Wrong idempotency key choice — Using transfer_no as the idempotency key is fine, but the target system must use the same field for dedup checks; otherwise, a re-run produces duplicate documents.

4. Submitting header and lines in one shot — Kingdee's batchSave submits header and lines atomically. If any single line fails validation, the entire document rolls back. We recommend landing the header first and submitting lines in phases, so failures are easier to trace.

5. Over-aggressive scheduling triggering ERP throttling — Kingdee Cloud's endpoint has rate limits; running the source every 50 minutes is already aggressive. Faster scheduling easily triggers throttling. Run stably at the current cadence first, then adjust based on actual volume.

When It Fits, When It Doesn't

Fits: retail/distribution enterprises where the WMS is the system of record and the ERP plays a supporting role; audited WMS transfer orders need to flow back to the ERP as the basis for inventory and finance; hour-level real-time requirements are acceptable.

Doesn't fit: scenarios where the ERP drives the WMS (e.g., transfer approval lives in the ERP), complex cross-org multi-legal-entity transfers, and businesses requiring minute-level real-time sync—those should use event-driven integration or a dedicated inventory middle platform.