Purchase Order Sync in Practice: A Single-Strategy Rollout from WST to Kingdee Cloud Xingchen
What This Strategy Solves
Pushing purchase orders from WST into Kingdee Cloud Xingchen sounds like "copy a doc after ordering," but one retailer's rollout exposed the real issues: each store had its own supplier codes on both sides, and three months later the reconciliation numbers didn't match. On top of that, when order status changed in WST, the change never propagated to Kingdee, so incoming goods couldn't find the original PO. This single strategy has a tightly scoped mission—treat WST as the source of record and push to Kingdee Cloud Xingchen incrementally, normalizing codes, keeping status aligned, and guaranteeing a one-to-one relationship between header and lines.
Data Flow and Field Mapping
The flow is unidirectional: WST (source of record) → Qeasy Data Integration Platform (middleware for cleansing and mapping) → Kingdee Cloud Xingchen (target). The middleware carries no business logic—only format normalization and code translation.
Key field mapping (abbreviated; extend with the customer's master data in real projects):
| Business meaning | WST (source) | Kingdee Cloud Xingchen (target) | Handling notes |
|---|---|---|---|
| Document number | trade_no | FBillNo | Direct mapping; source-unique |
| Supplier code | provider_code | FSupplierId | Route through supplier mapping table, centrally managed |
| Material code | sku_code | FMaterialId | Route through material mapping table; SKU and material ID separated |
| Order status | order_status | FDocumentStatus | Status enum translation |
| Line number | line_no | FEntryEntity_LineNo | Keep order consistent |
| Qty / Price | qty / price | FQty / FPrice | Units must be unified |
How to Configure It on Qeasy
We use the Qeasy Data Integration Platform as the carrier. The configuration breaks into four pieces.
Piece one: source connector. Pull purchase orders through WST's open API or a database view. Don't pull full loads blindly—confirm whether the source exposes a "last updated" field. If yes, use incremental; if not, add a shadow field first.
Piece two: target writer. Call Kingdee Cloud Xingchen's PO save endpoint via the web open capability.
Piece three: centrally managed code mapping. Keep the supplier and material mapping tables as Qeasy dictionary tables so other strategies (sales orders, inbound deliveries) reuse the same tables. This is what one retailer relied on most when expanding later.
Piece four: scripts and cleansing. In Qeasy's script node, write unit conversion, status mapping, and split-phase header/line handling—write the header first, capture the target document number, then write the lines against it.
Implementation Steps
We roll this out in four phases.
Phase one: confirm the incremental anchor. Choose a clear start timestamp on the source and snapshot the order status at that moment. Every subsequent push uses this as the baseline so historical data never leaks into incremental runs.
Phase two: full trigger. On first go-live, do a full backfill that writes historical POs to Kingdee in time-sliced batches.
Phase three: switch to incremental after full load completes. Once full load finishes, switch scheduling to incremental mode and continuously pull where "last updated > last successful timestamp."
Phase four: scheduling cadence. Recommend a 15-minute incremental interval with an additional overnight full reconciliation. This is the common "incremental + full dual-track" pattern among Qeasy customers—incremental guarantees freshness, full catches divergence.
Pitfall Recap
Pitfall 1: status machines out of sync. WST's "pending ship" maps to Kingdee's "approved," and Kingdee's "closed" may just be "voided" in WST. Map every status enum in script—never rely on default values.
Pitfall 2: line write order. Submitting header and lines in one shot means a target-side error leaves the header already written. The safe approach is split-phase: write the header, capture FBillNo, then write lines against it.
Pitfall 3: inconsistent units. WST uses "pieces," Kingdee defaults to "base unit." In one project we were burned because carton and base-unit conversion was missing, inflating inbound quantity 12x.
Pitfall 4: time zone and time format. Timestamps must be unified to ISO with time zone; if the source emits "yyyy-MM-dd HH:mm:ss," patch the time zone in script.
Pitfall 5: no retry on failure. Under network jitter or target-side throttling, configure exponential-backoff retries in Qeasy so orders don't get stuck in middleware.
When This Applies and When It Doesn't
Applies: Retail or distribution businesses that use WST as the main PO system and Kingdee Cloud Xingchen for finance and inventory master data; daily order volume under several thousand; sub-15-minute latency acceptable.
Doesn't apply: Bidirectional scenarios where POs are edited in Kingdee and written back to WST; multi-org, multi-ledger complex approval flows; and use cases demanding second-level real-time sync—the latter should use event-driven lightweight integration instead of a periodic strategy.