Syncing Kingdee Disassembly Sub-Items to Jushuitan Other Inbound Orders: A Qeasy Supply Chain Integration Guide
What This Strategy Solves
In a real retail scenario, a company often needs to handle product disassembly: in Kingdee Cloud Galaxy, a disassembly order represents breaking a finished good into component parts. Jushuitan, used as the front-end e-commerce and WMS system, needs to record these components into inventory through "other inbound orders." Without a connection between the two, inventory counts gradually drift and financial cost reconciliation breaks down.
In one actual project, we used the Qeasy Data Integration Platform to handle this integration, stably pushing disassembly sub-items from Kingdee into Jushuitan. Below is the full breakdown.
Data Flow and Field Mapping
The overall chain is: Kingdee Cloud Galaxy (disassembly order / sub-items) → Qeasy Integration Platform (transformation layer) → Jushuitan (other inbound order).
The source end pulls sub-item details from the disassembly order, while the target end writes into both the header and body of Jushuitan's other inbound order. The key field mapping is roughly as follows:
| Dimension | Kingdee Cloud Galaxy (Disassembly Sub-item) | Qeasy Middle Layer | Jushuitan (Other Inbound Order) |
|---|---|---|---|
| Document Number | Disassembly Order No. | Pass-through | External Order No. |
| Business Date | Document Date | Normalized date format | Inbound Date |
| Component Code | Material Code | Encoding mapping lookup | Product Code |
| Component Name | Material Name | Pass-through | Product Name |
| Quantity | Disassembled Quantity | Unit conversion | Inbound Quantity |
| Warehouse | Source Warehouse | Warehouse code mapping | Warehouse Code |
| Remarks | Business Remarks | Concatenated with source order | Remarks |
Encoding mappings should be centrally maintained in Qeasy's mapping tables, so when new warehouses or materials are added, a single edit applies everywhere.
How to Configure in Qeasy
In the Qeasy Data Integration Platform, create a new sync strategy: select Kingdee Cloud Galaxy's disassembly order interface as the source, and Jushuitan's other inbound order interface as the target.
Key configuration points:
- Source filtering: limit document type to "disassembly order" and status to "approved," so that drafts are not pushed.
- Encoding mapping: material codes and warehouse codes should all be maintained in Qeasy mapping tables; do not hardcode them in scripts.
- Header and body phased: land the header first, retrieve the Jushuitan inbound order number, write it back into Kingdee, then push the body. This is one of the common patterns used by Qeasy customers, avoiding dirty data caused by body writes when the header fails.
- Idempotency control: use Kingdee disassembly order number + line number as the idempotency key, so pushed records are not re-pushed.
- Exception handling: failed documents go into Qeasy's exception queue for manual or automatic retry, never silently dropped.
Implementation Steps
We usually break this sync into three phases:
Phase 1: Initialize the incremental starting point. Run a one-time full sync for all historically approved disassembly sub-items into Jushuitan, establishing the starting point for incremental syncs. Record the maximum timestamp once it completes.
Phase 2: Incremental scheduling. Configure scheduled polling by last-modified time to sync new and changed disassembly sub-items. The schedule is typically every 5–15 minutes; during peak hours it can be tightened, but never below 1 minute to avoid pressure on the source system.
Phase 3: Reconciliation and backfill. Run a reconciliation job during the daily business low-peak window, comparing cumulative quantities of Kingdee disassembly sub-items against cumulative inbound quantities in Jushuitan, and auto-generating backfill tasks for any discrepancies.
Running incremental and full sync in parallel is a well-established practice among Qeasy customers, balancing historical data completeness with daily real-time sync.
Lessons Learned
- Disassembly sub-item quantity direction is easy to flip. A disassembly order means "finished good decreases, components increase"; only the component lines (the increasing side) should be pushed to the inbound order, not the finished good line.
- Unit mismatch is a classic pitfall. Kingdee might use "piece" while Jushuitan might use "each" or a packaged unit; unit conversion must be done at the mapping layer, otherwise inventory counts can differ by multiples.
- Warehouse codes are two different systems. The same physical warehouse may have different names on each side. Centralize the mapping in Qeasy's mapping tables rather than scattering it across scripts.
- The idempotency key must include the line number. Using only the document number as the idempotency key will cause duplicate inbound entries when a disassembly order is approved multiple times or reversed. Adding the line number makes it stable.
- Status changes must retrigger the sync. A disassembly order is only valid once it moves from draft to approved; do not poll by creation time, or drafts will enter the queue.
When to Use and When Not to Use
Suitable for scenarios where finished goods are disassembled into components and those components need to be recorded back into inventory. Not suitable for reverse assembly orders, or for complex scenarios where disassembly cost accounting must drill down to the material layer.