Sales Outbound Order Sync in Practice: Designing the Pipeline from Wangdiantong to Kingdee Cloud and Lessons Learned

What This Strategy Solves

In a private-deployment environment of a retail enterprise, the e-commerce front end runs on Wangdiantong, while the back-office finance and supply chain sit on Kingdee Cloud. The two systems each generate hundreds or thousands of sales outbound orders per day: the warehouse scans and ships in Wangdiantong, while finance needs to post the entries, recognize revenue and calculate cost in Kingdee. Once the two sides drift apart, reconciliation falls back to manual Excel stitching. Our approach is to use the Qeasy data-integration platform to build a pipeline that pushes sales outbound orders from Wangdiantong into Kingdee as scheduled, so the warehouse-side facts automatically land in the ERP.

Data Flow and Field Mapping

The flow is unidirectional: Wangdiantong (source) → Qeasy middle layer → Kingdee Cloud (target). The middle layer fills in differences by business rules, maintains code mappings, and enforces idempotent de-duplication.

On the source side, the interface is wdt.wms.stockout.sales.querywithdetail, which paginates through outbound headers and details. The key fields are stockout_id and order_no. On the target side, the batchSave API writes sales outbound orders into Kingdee with bill type XSCKD01_SYS.

The key field mapping is roughly:

Both idCheck=true on the source and the target are enabled, so Qeasy uses stockout_id as the idempotency key and will not create duplicate documents on retries.

How to Configure It in Qeasy

In Qeasy, one strategy is a combination of "source API + target API + transform script + schedule." The typical steps are:

1. Register the source platform: fill in the Wangdiantong interface info, set wdt.wms.stockout.sales.querywithdetail as QUERY, and attach pagination to pager.
2. Register the target platform: set Kingdee's batchSave as EXECUTE, with bill type XSCKD01_SYS hard-coded.
3. Write transform scripts: in Qeasy's script editor, map source fields to target fields. Code mappings (shop → sales org, customer → customer code, SKU → Kingdee material code) are maintained in a single mapping table. One of the most common patterns among Qeasy customers is "centralized code mapping" — adding a new shop or customer only touches one place, never the script.
4. Configure scheduling: incremental on the source side, batch write on the target side.
5. Enable idempotency: turn on idCheck on both ends so reruns are safe.

Implementation Steps

We split this pipeline into "incremental steady state + full-volume fallback" to avoid the risk of writing everything at once:

• Incremental starting point: first backfill the last 7 days of Wangdiantong outbound orders to validate field and code mappings end-to-end. The most common pitfall here is "code mappings not ready, and three months later the numbers on the two sides don't match," so it is worth being slower up front to get the mapping table right.
• Full-volume trigger: once incremental is stable, run a one-time full-volume compensation to push every historical outbound order. Kingdee's batchSave supports batches, so throughput is acceptable.
• Schedule frequency: the source is configured as 0-59/15 2-4 * * * (every 15 minutes between 02:00 and 04:00), avoiding business peaks; the target is configured as 23 5-6 * * * (batch write between 05:00 and 06:00), leaving a settlement window for Kingdee. Running incremental and full-volume on parallel tracks is one of the most common Qeasy customer patterns in ERP integration scenarios.
• Exception handling: enable Qeasy's retry and alerting, log document-level failures, and never let one bad record block the whole batch.

Another engineering lesson: process headers and entities in stages. First stabilize the header (bill no., date, customer, org), then move on to the entity rows (item, quantity, batch), so one error does not roll back the entire document.

Pitfall Post-mortem

1. Reusing source order_no directly as the bill number: Wangdiantong's numbering rules and Kingdee's allowed character sets differ; we once saw numbers exceeding the limit rejected by Kingdee. The safe approach is to regenerate on the target side using {{short_date}}{{shop_no}}{{warehouse_no}}.
2. Cross-midnight outbound orders: a 1 a.m. order is "yesterday" in Wangdiantong but "today" in Kingdee. The typical mistake is to use the server time as the date; the safe approach is to use the warehouse business day.
3. Code mappings scattered across multiple scripts: when a new shop opens, no one knows what to change. The root cause here is "distributed maintenance"; the convention is to centralize all mappings into one table.
4. Partial entity row failures being silently ignored: Kingdee's batchSave submits header and entity together, so a few failing rows can cause the entire document to be silently dropped. The safe approach is to run validation on the middle layer in Qeasy and intercept bad data there.
5. Reruns causing duplicate documents: an abnormal schedule triggered a manual full backfill, and Kingdee ended up with twice the outbound orders. Always rely on idCheck + the idempotency key (stockout_id) for safety.

When to Use and When Not to Use

Use it when: Wangdiantong acts as the warehouse/e-commerce front end and Kingdee Cloud acts as the ERP back end, the business needs outbound facts posted automatically, and minute-level latency is acceptable. Don't use it when: real-time sub-second sync is required, the scenario spans complex multi-org multi-entity distribution, or the source document structure is still under heavy iteration — those scenarios are better served by message queues, or by freezing the source structure before integration.