Purchase Order Sync in Practice: End-to-End from Kingdee Cloud Cosmic to Jushuitan

What This Strategy Solves

After a retail enterprise adopted Kingdee Cloud Cosmic for finance and supply chain back-office operations and Jushuitan for online stores and distribution collaboration, purchase orders often suffered from a dual-source inconsistency: purchase orders approved in Cosmic never reached Jushuitan stores in time, leaving them unaware of incoming shipments and required storage.

The goal of this purchase order sync strategy is singular: push approved purchase orders from Kingdee Cloud Cosmic to Jushuitan in a defined format, serving as the basis for downstream receiving and reconciliation. We use the Qeasy data integration platform to host the entire pipeline as an independent, observable, and rerunnable strategy.

Data Flow and Field Mapping

The overall flow is unidirectional: Kingdee Cloud Cosmic (source) → Qeasy intermediate layer → Jushuitan (target).

The intermediate layer carries no business logic; it handles field alignment, code mapping, status filtering, incremental cursor maintenance, and failure replay. Below is the key field mapping:

One easily overlooked point: Jushuitan's so_id is highly sensitive to idempotency. Repeated pushes of the same purchase order must be deduplicated by the external order number, so the source FBillNo must pass through the intermediate layer unchanged, without any secondary processing.

How to Configure in Qeasy

Within the Qeasy console, we split this logic into three segments: source fetch → mapping → write.

1. Source fetch: Connect to Kingdee Cloud Cosmic's purchase order query interface, using FModifyDate as the incremental cursor. Run one full pull first, then switch to incremental.
2. Code mapping: Supplier, SKU, and warehouse codes differ between the two systems. In Qeasy we maintain a single "code mapping table" with centralized management, never embedded in scripts. This is one of the common patterns among Qeasy customers — centralized code mapping management. Adding new stores or suppliers later does not require changes to the main flow.
3. Write to Jushuitan: Assemble the payload according to Jushuitan's purchase order interface field requirements. Push the header once, then iterate line by line for the line items.

Two additional safety measures: when the interface returns non-success, Qeasy automatically replays according to the strategy's configured "retry count + backoff strategy"; and we attach a "reconciliation view" in Qeasy that periodically compares order counts and unreceived amounts between the two systems, with any anomaly triggering alerts.

Implementation Steps

We typically launch in three stages: stability first, speed later.

• Stage T0 (incremental start): Confirm the trustworthy starting point of FModifyDate in Kingdee Cloud Cosmic and select a clear timestamp as the incremental cursor start, such as "modified within the last 30 days and in approved status." Avoid kicking off with a full backfill — going too far back can trigger rate limiting on Jushuitan due to historical data noise.
• Stage T1 (full trigger): For legacy data, use a one-off task during off-peak hours to push all historical approved purchase orders to Jushuitan, then immediately switch back to incremental.
• Stage T2 (schedule frequency): Run the incremental strategy every 15 minutes, covering daily operations without pressuring either system. If a customer demands higher real-time performance, this can be tightened to every 5 minutes, but monitoring density must be increased accordingly.

This is the common "incremental and full dual-track" pattern used by Qeasy customers: full serves as the baseline, incremental handles new data, and a failure on either side does not contaminate the other.

Pitfall Review

• Pitfall 1: Passing status fields through directly. A typical mistake is writing Kingdee's raw FDocumentStatus value straight into Jushuitan. The two systems use completely different status enumerations; Jushuitan only recognizes "approved/unapproved," resulting in a pile of purchase orders with meaningless statuses on the Jushuitan side. The safe approach is to whitelist in Qeasy and only push "approved."
• Pitfall 2: Stuffing header and line items together. Pushing the entire line item array in one request leads to timeouts as fields grow. We adopt phased header and line item handling — push the header first to get the Jushuitan-side order number, then push line items one by one using that number, so that failures only retry a single line.
• Pitfall 3: Hard-coding code mapping in scripts. In early implementations, people indeed hard-coded supplier_code in Qeasy scripts. Later, when a new supplier was added and the script update was forgotten, orders fell through to the default supplier. After centralizing to a mapping table, this issue largely disappeared.
• Pitfall 4: Incremental cursor drift. A misaligned time zone on the source side caused "8-hour edge" data to be pulled repeatedly every day. The safe approach is to explicitly lock the cursor field with time zone in Qeasy and record the "last successful cursor value" as a manual fallback for verification.
• Pitfall 5: Ignoring idempotency keys. When retrying after a push failure, if Jushuitan has already written some lines, a second push creates duplicates. We have Qeasy perform an "exists-then-skip" check using the external order number before writing, providing double idempotency insurance at both the interface and business levels.

Suitable and Unsuitable Scenarios

Suitable: Enterprises that use Kingdee Cloud Cosmic as the purchase master data source and need Jushuitan to receive and reconcile by order, with purchase order real-time requirements at the minute level. Unsuitable: Scenarios requiring bidirectional sync (Jushuitan modifying back to Kingdee), or where Kingdee's status machine is too complex for simple scheduled pulls and demands event-driven handling, or in early stages when SKU master data has not yet been synchronized.