Transfer-In from Jushuitan to Kingdee Cloud Direct Transfer Order: A Practical Breakdown of One Inventory Sync Strategy
What This Strategy Solves (Scenario and Value)
In a multi-warehouse retail operation, the front-end e-commerce warehouse runs on Jushuitan while the back-end finance and supply chain accounting runs on Kingdee Cloud. Every day, cross-warehouse transfers happen, and the transfer-in documents generated in Jushuitan must be reflected in Kingdee as direct transfer orders for bookkeeping and cost accounting. If the two sides drift apart, inventory vs. book variances can balloon within three months and become very hard to reconcile. We use the Qeasy data integration platform to bridge this link, pushing transfer-in documents from Jushuitan into Kingdee reliably so both sides stay aligned.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The overall flow is: Jushuitan (Transfer-In) → Qeasy Integration Platform (cleaning and mapping) → Kingdee Cloud (Direct Transfer Order). The platform does two jobs: translating Jushuitan's open-platform fields into a document structure that Kingdee can understand, and centralizing the mapping of master data such as codes, warehouses, organizations, and units of measure.
Key field mapping:
| Business Meaning | Jushuitan (Source) | Qeasy (Middle Layer) | Kingdee (Target) |
|---|---|---|---|
| Document Number | Transfer-in No. | Platform unique key | BillNo |
| Transfer Direction | Type (in/transfer_in) | Standardized as transfer_in | Business Type (Direct Transfer) |
| Source / Destination Warehouse | src_warehouse_id / dest_warehouse_id | Warehouse code mapping | Issue Warehouse / Receive Warehouse |
| Item Code | sku_id | SKU → Material code mapping | Material Code |
| Quantity | qty | Converted to base UOM | Actual Received Qty |
| Business Date | business_time | Normalized to yyyy-MM-dd HH:mm:ss | Business Date |
How to Configure on Qeasy
We usually split this strategy on Qeasy into three configuration segments so a single long flow does not bury problems too deep.
1. Source-side Jushuitan connection Pull from Jushuitan's open platform using the transfer-in API incrementally by business time. The trigger should be placed after the transfer-in document has been approved. Configure a reasonable page size and use last_modify_time as the cursor to avoid missing records.
2. Middle-layer mapping and cleansing This is where things go wrong most often. We centralize all code mappings in a mapping table on the platform, covering item codes, warehouse codes, and organization codes. Qeasy allows the mapping logic to live in scripts so that later changes do not require modifying the flow itself—this is a common on-site pattern: centralize code mappings, and updating a mapping is far cheaper than updating a flow.
3. Target-side Kingdee writing On the Kingdee side, use the standard direct transfer order API. Write the header first, then the body, in two stages. Header failures should alert immediately; body failures should retry per row, so a single bad line does not void the entire document.
Implementation Steps
We recommend going live in three phases: incremental start point → full reload trigger → scheduling cadence.
Phase 1: Incremental Start Point Set a clear incremental start time. Data before that point should be backfilled manually; from that point onward, push incrementally by last_modify_time. Do not set the start point too early, otherwise historical dirty data from Jushuitan will be pulled in as well.
Phase 2: Controlled Full Reload In the first week after go-live, run one controlled full reload covering only the most recent N days (depending on volume) to verify inventory vs. books. After the full reload completes, switch back to incremental-only and never run full reloads again—the safe approach is "full reload controlled, incremental steady-state."
Phase 3: Scheduling Cadence Transfer operations usually need higher real-time performance than cost accounting. We recommend a 5–10 minute polling interval, extending to 30 minutes during low-traffic nighttime hours. The Qeasy scheduler supports time-segment differentiated configuration, which is more flexible than manual crontab.
Lessons from the Field
-
Warehouse code mismatch. Jushuitan's warehouse ID is an auto-incrementing number, while Kingdee uses organization-dimension named code strings. On the first go-live, no mapping table was built, and Jushuitan IDs were pushed straight into Kingdee, resulting in every document landing in the wrong warehouse. After all warehouse codes were routed through a mapping table, the issue was resolved at once.
-
Base unit conversion missed. The quantity on Jushuitan documents is recorded in the sales unit, while Kingdee's direct transfer order requires the base unit. The middle layer must perform unit conversion; the typical mistake is to pass qty straight through, which misaligns the cost accounting basis.
-
Approval status not filtered. Jushuitan transfer-in documents have three statuses: Pending / Approved / Voided. Pushing only Approved documents is the baseline; pushing Voided ones into Kingdee will create reverse variances. Add a status filter in the middle layer.
-
Idempotency. If the same transfer document is re-pushed due to network jitter, Kingdee will create duplicate documents. The safe approach is to use the Jushuitan document number as an idempotency key in the middle layer: check first, then write.
-
Time zone and date boundaries. Cross-day transfers (for example, approved at 23:50, synced at 00:05 the next day) often land on the wrong business date. The middle layer should consistently use business_time rather than sync time to avoid this trap.
When to Use and When Not to Use
Use this pattern when: a multi-warehouse retail or distribution enterprise runs e-commerce systems on the front end (represented by Jushuitan) and ERP (represented by Kingdee Cloud) on the back end, and needs cross-warehouse transfers synced to financial accounting in real time or near real time. Do not use it when: the enterprise is single-warehouse with no transfer operations, or transfers are fully closed-loop inside the ERP; and do not use it for strict real-time needs—this strategy runs at minute-level polling, not event-stream level.