Kingdee Purchase Receipt → Wangdiantong Other Inbound: A Sync Strategy for Inter-Org and Ad-hoc Inbound Scenarios
What This Strategy Solves
In multi-org, multi-warehouse supply chains, Kingdee Cosmic typically owns finance and procurement settlement, while Wangdiantong WMS owns physical inbound and inventory ledger. For inter-org transfers, ad-hoc replenishments, and returns-to-stock, Wangdiantong has no native "purchase receipt" document type — they must land as "other inbound orders." This strategy splits Kingdee purchase receipts by document type and pushes them into Wangdiantong other inbound orders.
Data Flow and Field Mapping
Flow: Kingdee Cosmic (source) → Qeasy middleware → Wangdiantong WMS (target).
Key field mapping (business-level):
| Business Meaning | Kingdee (Source) | Qeasy Middleware | Wangdiantong (Target) |
|---|---|---|---|
| Document No. | FBillNo | bill_no | order_no |
| Document Type | FDocumentType | doc_type | inbound type enum |
| Org / Warehouse | FStockOrgId | org_code | warehouse_code |
| SKU | FMaterialId | sku_id | goods_id |
| Quantity | FQty | qty | num |
| Batch | FBatchNo | batch_no | batch_no |
| Supplier | FSupplierId | supplier_code | supplier_code |
| Business Date | FDate | biz_date | biz_date |
Note: actual physical field names depend on each system's open API; map by business meaning first, then align field names.
How to Configure on Qeasy
We deliver this on the Qeasy Data Integration Platform. Typical configuration points:
- Source fetch: call Kingdee's open query interface, filter
document type = purchase receipt AND status = approved AND modify_time >= last_success_time. - Centralized code mapping: SKU, org, and supplier codes almost never match 1:1. We maintain them in Qeasy's mapping table module — one place to update when a new org or SKU lands. This is the most common Qeasy customer pattern.
- Target write: call Wangdiantong's other inbound create interface, routing by
doc_typeto either "inter-org purchase" or "ad-hoc inbound." - Header vs. body phased rollout: ship header + required body fields (SKU, qty, batch, warehouse) first; defer optional fields like remarks and attachments until reconciliation is stable.
- Exception routing: enable Qeasy's built-in retry and dead-letter queue. Per-document failures should never block the batch.
Implementation Steps
We follow a "full backfill, then incremental steady-state" dual-track approach — another common Qeasy customer pattern:
- Phase 1 — Full trigger: on go-live, pull the last N days (e.g., 30) of approved receipts by business date, manually trigger a full run to seed history.
- Phase 2 — Incremental start: after the full run, capture the last successful timestamp and switch to incremental mode.
- Phase 3 — Schedule frequency: purchase receipts are low-frequency; schedule every 10–15 minutes. High volume can go to 5 minutes, but never below 2 minutes to protect the source.
- Phase 4 — Closing and reconciliation: daily close — mark source-side docs as "synced" once the target-side doc is approved; weekly stock reconciliation with threshold-based alerts.
Lessons Learned
- Classic mistake: pushing inter-org purchase receipts as ordinary purchase receipts. Inventory lands under the wrong document type on Wangdiantong, and Kingdee's inter-org settlement no longer reconciles. Fix: split by document type at the source — never infer at the target.
- Classic mistake: pushing records with empty batch fields. When Wangdiantong enforces batch management, an empty batch becomes "no batch," polluting the ledger. Fix: route empty-batch rows to the dead-letter queue; require manual completion before retry.
- Classic mistake: failing to capture the incremental watermark before a full run, causing duplicates. Fix: persist
last_success_timeon Qeasy and force-refresh after every full run. - Classic mistake: 1:1 mapping between Kingdee org codes and Wangdiantong warehouse codes. Kingdee orgs are financial; Wangdiantong warehouses are physical. Fix: explicit conversion in Qeasy's mapping table, not hardcoded in scripts.
- Classic mistake: wrong close condition — e.g., closing when target is "saved" instead of "approved." Fix: align the close field with the target's actual status field, and run a dry-run on Qeasy first.
When to Use and When Not
Use: multi-org/multi-warehouse Kingdee + Wangdiantong setups with inter-org transfers, ad-hoc replenishments, or returns-to-stock that need document-level traceability and reconciliation. Don't use: simple environments where Wangdiantong already supports a native "purchase receipt" type with fully aligned codes (use the standard sync instead); also don't use for sub-second real-time requirements — this strategy runs on minute-level schedules.