Syncing Purchase Warehousing Orders from Jushuitan to Kingdee Cosmic: A Hands-on Guide with Qeasy

What This Strategy Solves

In one of our retail client projects, we kept seeing the same scene: warehouse staff completed scan-in warehousing in Jushuitan, while the finance team had to manually re-enter the same purchase warehousing order in Kingdee Cosmic. Otherwise cost accounting and accounts payable would drift apart.

The strategy "Jushuitan purchase warehousing order => Cosmic purchase warehousing order" turns this manual bridge into an automated sync, keeping inventory, amounts, and document status consistent on both sides.

Data Flow and Field Mapping

The overall flow is: Jushuitan (source) → Qeasy data integration platform (middleware) → Kingdee Cosmic (target).

The middleware is not a dumb pipe. We typically do three things there: code mapping, field standardization, and field enrichment.

Key field mapping overview:

One important note: code mapping must be centrally managed. For items, suppliers, and warehouses, always maintain a separate mapping table through independent master-data strategies. The purchase warehousing order strategy should only look up the table, never hard-code translation logic inside the document strategy—otherwise in three months the numbers on both sides will not match.

How to Configure in Qeasy

When we configure this strategy in the Qeasy data integration platform, we usually follow these key points.

1. Source system connector Use the Jushuitan adapter, pull incremental warehousing orders through the open API with a time window, and use "order number + business date" as the idempotency key to avoid duplicate documents on reruns.

2. Middleware orchestration

• The raw payload is first fed into a "field cleaning" node to strip Jushuitan's internal fields;
• Then it flows into a "code mapping" node that references the pre-maintained supplier, item, and warehouse mapping tables;
• Finally a "field enrichment" node fills in required fields for Kingdee Cosmic, such as department, currency, and settlement method.

3. Target system write Call Kingdee Cosmic's purchase warehousing order save interface, using a "header-then-line staged write": first submit the header to get the internal document id, then loop through and submit the line entries. This step is a major pitfall, covered below.

4. Exception handling and write-back Failed orders go into a retry queue; once the threshold is reached they are escalated to a manual ticket. Successful orders have Kingdee's document number written back to a custom field in Jushuitan to support reconciliation.

Implementation Steps

We recommend a three-phase rollout: "full sync first, then incremental, then stabilization."

Phase 1: Full trigger, verify the chain Manually trigger a one-time historical full sync. The goal is not to load data but to verify the chain works end-to-end. A typical approach is to select the last 7 days of warehousing orders for a small batch drill, then check quantity, amount, and supplier consistency. This step usually surfaces three classic issues: code mapping, units, and tax rate.

Phase 2: Determine the incremental starting point Confirm the "starting timestamp" field. On the Jushuitan side, "modification time" is usually the right incremental cursor. In Qeasy, set this field as the incremental starting point and persist it in the strategy config. We also recommend keeping a "full reload switch" for emergency full replays.

Phase 3: Scheduling frequency Warehousing orders are time-sensitive, so we usually configure an incremental schedule every 5–10 minutes, plus one catch-up run during the off-peak night window to make sure data is complete by next morning. In Qeasy, give the purchase warehousing order strategy its own schedule. Do not share a scheduler with sales outbound, otherwise resources will fight at peak time.

Lessons Learned from the Field

1. One-shot header-and-line submit drops line entries. Submitting header and lines together in a single payload for Kingdee Cosmic sometimes produces the strange result of "header saved, partial lines missing" under heavy load. The reliable approach is staged submission: header first, then write lines one by one.

2. Code mapping scattered across multiple strategies. During one client engagement, the supplier code in the purchase warehousing order was hard-coded in a transformation script, while the supplier sync strategy maintained a different copy. The mismatch was only discovered three months later. Centralizing mapping tables is a basic discipline for this kind of integration.

3. Wrong field chosen as incremental cursor. Using "creation time" as the cursor will miss modified orders. "Last modified time" is safer. Also, the cursor must be normalized to the source system's timezone, otherwise cross-day data will drift.

4. Unit and tax-rate semantics differ. Jushuitan's "piece" is not necessarily the same as Kingdee's "base unit", and tax-included unit prices must be recalculated per the target system's pricing rules. Passing values through directly will always break.

5. Retry storms take down the downstream. If failed warehousing orders retry forever, they will knock out the Cosmic interface within minutes. In Qeasy, configure stepped retries: once failure count hits the threshold, escalate to manual handling rather than looping forever.

When to Use and When Not

This strategy fits multi-entity retail or distribution scenarios where Jushuitan acts as the front-end business system and Kingdee Cosmic acts as the back-end financial system, with high requirements for warehousing timeliness and reconciliation consistency.

It does not fit scenarios where Jushuitan and Kingdee Cosmic share a direct database account, nor traditional enterprises whose purchasing is still paper-based. In the latter case, digitizing the offline documents should come first; only then does sync start to make sense.