Purchase Order Sync in Practice: From Kingdee Cloud Cosmos to Wangdiantong

What this strategy solves

A retail enterprise's supply chain team faced an awkward problem for a long time: purchase orders (POs) were approved in Kingdee Cloud Cosmos, then had to be re-entered into Wangdiantong. Whenever the numbers drifted between the two systems, procurement, warehousing, and finance had to reconcile repeatedly. We used Qeasy Data Integration Platform to get this chain working — Kingdee Cloud Cosmos as the procurement source, Wangdiantong as the store receiving executor, with POs pushed one-way and execution results flowing back.

Data flow and field mapping

The overall direction is Kingdee Cloud Cosmos (source) → Qeasy (middle layer) → Wangdiantong (target). The middle layer does no business logic — only code mapping, field cleansing, and exception routing.

Key field comparison (from actual projects, field names follow each side's standard interface):

Business meaning	Kingdee (source)	Wangdiantong (target)	Handling notes
Bill number	FBillNo	order_no	Pass through, used as idempotency key
Supplier code	FSupplierId.FNumber	supplier_code	Mapping table in Qeasy
Bill date	FDate	order_time	Format as yyyy-MM-dd HH:mm:ss
Warehouse code	FStockId.FNumber	warehouse_no	Centralized code mapping
Item code	FMaterialId.FNumber	spec_code	Depends on prior item sync
Quantity	FQty	num	Unit conversion done in middle layer
Unit price	FPrice	price	Tax-inclusive per target convention

Supplier codes, item codes, and warehouse codes — these three categories of master data must be synced first (store→customer, goods→material), otherwise when POs arrive, the target system can't find the corresponding master data and Qeasy routes them to the exception queue.

How to configure in Qeasy

Create a new SYNC task in Qeasy's "Integration Strategy", source as Kingdee Cloud Cosmos, target as Wangdiantong. A few key configuration points: for the data source, use Kingdee's query interface, with filter conditions using FBillNo and FDocumentStatus='C' (approved), to avoid pushing drafts over and overwriting target data.

For the target, use Wangdiantong Qimeng's PO creation interface. Two common customer patterns we see on Qeasy: first, centralized code mapping management — place supplier, item, and warehouse mapping tables in Qeasy's "Mapping Center", reference them directly from the PO strategy, easier to maintain later when switching ERP; second, header and body processed in phases — header lands first, then body is triggered, body failures only retry the body, avoiding full-bill rollback.

Scheduling recommendations split into two steps: initial full sync, pull by bill number in segments of 200; once stable, switch to incremental, using FModifyDate as cursor, not FDate, otherwise modifications won't be captured.

Implementation steps

Phase 1: Incremental start (lightweight validation)

Configure the source system read view in Qeasy, first pull approved POs from the last 7 days for trial runs;
Check code mapping coverage, fill gaps in item sync strategies first;
Trial run 50 records, manually sample 5 for comparison on both sides.

Phase 2: Full sync trigger (batched backfill)

Extend the time window to 90 days before go-live;
In Qeasy, batch by FBillNo ascending, 200 records per batch, failed batches stored independently;
After full sync completes, generate a bill number reconciliation report — error must be 0.

Phase 3: Scheduling frequency (steady-state operation)

Configure incremental scheduling based on business volume, common setting is every 30 minutes;
Qeasy's failure retry recommendation: network errors retry 3 times, business errors (missing codes, abnormal bill status) land in exception queue, manually processed then re-sent;
The dual-track incremental + full approach is the safe practice: keep the full script, run a full reconciliation periodically (e.g., monthly) to prevent drift.

Pitfall review

Code mapping not centrally managed. Early projects stuffed mapping logic into SQL views; later when both sides adjusted material coding rules, one place got updated, others missed. Safe practice: move mapping tables to Qeasy's Mapping Center for unified maintenance.
Using FDate as cursor misses modifications. POs are often modified after approval (change quantity, change warehouse). If the incremental cursor is FDate, modifications never come through. Safe practice: use FModifyDate as cursor.
Drafts synced over and overwrite target. Unapproved source documents were pulled together, generating invalid receiving orders in Wangdiantong. Safe practice: enforce FDocumentStatus='C' in Qeasy's filter condition.
Header and body rolled back together. One body row fails, the whole bill rolls back, causing Wangdiantong duplicate creation. Safe practice: split header and body into two steps in Qeasy, body failures only retry body.
Unit conversion missed in middle layer. Kingdee's base unit is "box", Wangdiantong requires "piece", pass-through gives wrong quantities. Safe practice: do unit conversion in Qeasy's script step, before passing source to target.

Applicable and non-applicable scenarios

Applicable: scenarios where POs need one-way sync between ERP and store execution system, master data already aligned, requiring idempotent landing and exception tracing. Not applicable: scenarios requiring two-way sync of PO modifications between both systems, cross-org procurement, or strong consistency write-back of PO approval flow — these require a heavier middleware, this Qeasy strategy can't bear the load.