Sales Outbound Order Sync in Practice: A Deep Dive into a Single Strategy from Wangdiantong to Kingdee Cloud

What This Strategy Solves

Within supply chain integration, the sales outbound order is the document most likely to fall out of reconciliation between a WMS and an ERP: on one side, the physical proof that a warehouse has shipped against an order; on the other, the source of truth for financial posting and cost accumulation. In a real engagement we saw a typical situation — a retail enterprise using Wangdiantong as its e-commerce fulfillment hub, with back-office accounting on Kingdee Cloud, and outbound orders pushed from Wangdiantong into Kingdee every day. The path looks straight, but once encodings, organizations, and document statuses drift, inventories and accounts receivable stop matching within three months.

The core value of this strategy is to turn "shipment equals posting" into a one-way, replayable, traceable sync chain. We use the Qeasy Data Integration Platform to carry it: Wangdiantong as the source, Kingdee Cloud as the target, with no third-party business system in between — only field translation and status alignment.

Data Flow and Field Mapping

The overall flow is unidirectional A → B: Wangdiantong (outbound execution side) → Qeasy middle layer (field translation, mapping, validation) → Kingdee Cloud (financial / inventory aggregation side).

Key field mapping (excerpt; source fields follow Wangdiantong, target fields map to Kingdee Cloud's header and lines):

Centrally managed encoding mapping is a common pattern among Qeasy customers: put the shop → sales org, warehouse → ship-from org, and customer code lookup tables on the platform side, so that the source never needs to change and the target side can be edited in one place.

How to Configure on Qeasy

In the Qeasy strategy orchestration UI, this strategy is generally configured along these lines:

1. Source connection: choose the Wangdiantong Flagship platform, use the API wdt.wms.stockout.sales.querywithdetail (POST query); keep paging parameter pager and business parameter params separate; turn on idCheck=true and use stockout_id as the idempotency key.
2. Target connection: choose the Kingdee Cloud platform; the execution API is batchSave (POST); the document type FBillTypeID is hard-coded to the sales outbound document type code; FBillNo is built with template variables.
3. Field mapping: in the Qeasy mapping canvas, drag source fields onto target fields; template strings (date, org code) use variable placeholders such as {{short_date}}, {{shop_no}}, {{warehouse_no}}.
4. Validation rules: block null values on required fields (document number, customer, sales org); enforce numeric type checks on quantity and price.
5. Failure handling: enable the platform's default retry and alerting; write error logs to Qeasy's message center.

Implementation Steps

We recommend going live in phases — headers first, lines next, incremental and full tracks running in parallel:

• Phase 1 — Incremental start: set the crontab to 0-59/15 2-4 * * * (every 15 minutes between 02:00 and 04:00), use stockout_id as the incremental cursor and pull only new or changed documents since the previous run; the goal here is to verify connectivity and document landing.
• Phase 2 — Full trigger: backfill historical data with a one-off full sync, sliced by document date or ingestion time; keep page sizes controlled to avoid oversize target transactions. The full run executes only once during cutover.
• Phase 3 — Converge schedule frequency: once stable, schedule source pulls into off-peak hours such as 23 5-6 * * * to minimize pressure on the source system; at the same time, enable rate limiting on Qeasy to avoid tripping the target API's throttle.
• Phase 4 — Monitoring and reconciliation: every morning produce a reconciliation report covering the day's outbound count on the source side, the successful landings on the target side, failure count, and pending retries; any deviation from baseline triggers an alert.

Phased header/line rollout is another common pattern among Qeasy customers: get the document header working first, then fill in the lines — when something breaks, the problem is far easier to locate.

Lessons from the Field

1. A classic mistake is mismatched document-number rules on the two sides. The source order_no is a natural number, while the target FBillNo is built by template concatenation. As soon as a shop or warehouse code changes, the concatenated result stops matching the source, and the investigation burns half a day. The safe approach is to take the document number straight from the source and let the template only add a prefix.
2. Never hard-code the inventory organization mapping inside a script. If it lives in a Qeasy script node, opening a new warehouse means editing code and going through a release. Push it down into a mapping table so that operations can change it themselves.
3. Using only stockout_id as the idempotency key is not enough. Wangdiantong outbound orders get modified; deduplicating by ID alone will miss status changes. The safe approach is to use stockout_id + modify_time as both the incremental cursor and the dedup key.
4. Don't chase large batch sizes. Kingdee's batchSave tends to hit transaction timeouts when the batch is too large, which actually makes it slower than smaller batches. Tune the batch size against historical volume: start small, then scale up gradually.
5. Cross-day documents need separate handling. When a scheduled run picks up a document from 23:50 yesterday, the target-side FDate is yesterday but the source completes the outbound today. These boundary documents should be listed separately on the reconciliation report to avoid day-count drift at month-end.

When This Applies and When It Doesn't

Applies: an e-commerce fulfillment hub on Wangdiantong paired with back-office accounting on Kingdee Cloud, where sales outbound documents need to be aggregated into finance and supply chain. Daily volumes from a few thousand to tens of thousands of orders all fit. Doesn't apply: scenarios that require bidirectional sync (such as reverse writes to the source for returns) and scenarios where the target side needs complex invoicing or tax splitting — for those, let Kingdee's own business rules handle the logic rather than overloading the sync layer.