Standard Kingdee Purchase Return to Wangdiantong Outsourced Warehouse Outbound: A Practical Sync Solution
What This Strategy Solves
In the supply chain of a manufacturing enterprise, Kingdee Cosmic acts as the ERP ledger of record, while Wangdiantong handles execution across e-commerce and outsourced warehouses. In the return-material scenario, the shop floor sends excess materials back to the warehouse, which generates a purchase return material order in Kingdee. On the business side, this corresponds to an outsourced warehouse outbound in Wangdiantong — returning sellable stock and pushing the cost back to the ERP. If this flow is keyed manually on both sides, the inventory ledger and the financial ledger will diverge within three months, and the dispute is almost impossible to trace. We use the Qeasy data integration platform to turn this document flow into an observable, replayable strategy. The value is locking the return-material semantics to a single set of rules.
Data Flow and Field Mapping
Data flow: Kingdee Cosmic (purchase return material order) → Qeasy integration platform (middleware) → Wangdiantong (outsourced warehouse outbound). The middleware handles code mapping, field rewriting, status mapping, and breakpoint resumption.
Key field mapping (typical items):
| Business meaning | Kingdee Cosmic | Qeasy middleware | Wangdiantong |
|---|---|---|---|
| Document number | FBillNo | doc_no | outer_no |
| Document status | FDocumentStatus | status_code | status (10=pending, 20=approved) |
| Return organization | FStockOrgId | org_code | warehouse_id |
| Material code | FMaterialId.FNumber | sku | goods_no |
| Return quantity | FRealQty | qty | nums |
| Batch | FLot | batch_no | batch_number |
| Stock type | FStockId | stock_type | stock_type (outsourced flag) |
| Remark | FNote | remark | remark |
For code mapping we use Qeasy's built-in centralized mapping table rather than hard-coding in scripts — a pitfall we have seen repeatedly across customer projects.
How to Configure in Qeasy
In the Qeasy data integration platform, one strategy maps to one integration flow. Typical configuration points:
- Source and target: pick Kingdee Cosmic as the source (pulled via its open API by document type) and Wangdiantong as the target. Qeasy connectors already encapsulate pagination, signing, and throttling — no hand-written SDK needed.
- Trigger: scheduled pull (every N minutes), incremental on
FModifyDate > last cursor. - Field mapping: align the table above in Qeasy's field-mapping canvas, with function transforms (for example, FDocumentStatus = "approved" → status = 20).
- Code mapping: build dedicated mapping tables for materials, customers, warehouses, and organizations, maintained centrally in Qeasy's master-data module.
- Write strategy: idempotency on outer_no on the Wangdiantong side to avoid duplicate outbound orders on rerun.
- Exception handling: network timeouts, throttling, and field-validation failures route to retry and alerting channels; Qeasy alerts can be pushed to a DingTalk bot.
- Logs and replay: every document keeps the request/response payload, with one-click replay from the breakpoint.
Implementation Steps
We typically run this in three phases on customer sites to keep things stable:
- Phase 1: Align the incremental starting point. Pull the "last successful sync timestamp" from the Kingdee side and use it as the initial cursor in Qeasy, so the incremental flow begins from that moment rather than dumping history on first run.
- Phase 2: Full backfill (optional). If the business needs past return-material orders brought in once, set up a one-shot full task in Qeasy — pull in batches by document date, N documents per batch, and auto-close the full channel afterwards so only incrementals remain.
- Phase 3: Scheduling frequency and monitoring. A typical cadence is every 5–10 minutes incremental, easing to 30 minutes during off-peak (overnight). Once the schedule is attached in Qeasy, add three dashboards — document count, failure rate, average latency — and alert on anomalies automatically.
Lessons Learned
- A common mistake is hard-coding status mapping. Kingdee's FDocumentStatus has three states — draft, approved, closed — and Wangdiantong needs numeric codes where the post-push behavior differs per state. The safe approach is to keep a status-code table centralized in Qeasy's field mapping rather than burying it in scripts.
- Missing the batch field causes inventory allocation errors. Outsourced warehouse returns almost always involve batches, so FLot on the Kingdee side must reliably reach batch_number on the Wangdiantong side. We have seen projects go live for a week and have the outsourced warehouse ledger exceed the financial ledger by hundreds of thousands because of this one missing field.
- No idempotency on outer_no causes duplicate documents on rerun. Qeasy's write node deduplicates on the outer document number by default, but only if outer_no is wired into the unique key in the mapping.
- Code mapping scattered across scripts makes maintenance unclear. Move all code mapping into Qeasy's master-data / mapping-table module — one view shows all material, customer, and warehouse correspondences, and a single edit takes effect globally.
- Skipping the initial cursor causes history to flood in on first run, distorting warehouse stock immediately. The incremental starting point must be agreed with the business before configuration.
When It Applies and When It Does Not
Applies: enterprises where Kingdee is the ERP ledger of record, Wangdiantong manages outsourced or e-commerce warehouses, and return-material documents must close the loop on both sides; volume in the hundreds to thousands of documents per day. Does not apply: cross-entity complex transfers, scenarios requiring manual approval gates, or cases where master data is not yet aligned on either side — in the latter situation, fix master data governance first before tackling document sync.