Kingdee Disassembly Parent Item Outbound to Jushuitan Other Outbound Order: A Single-Strategy Integration Tutorial

What This Strategy Solves

In retail and manufacturing enterprises running multiple systems side by side, disassembly operations are often overlooked. After a parent item is disassembled and issued out in Kingdee Cloud Sky, the resulting child-component consumption and inventory reduction are not automatically pushed to Jushuitan. This leads to inflated on-hand stock on the e-commerce warehouse side, and discrepancies only surface during picking. Using the Qeasy data integration platform, we push Kingdee's disassembly parent-item outbound documents as "other outbound orders" into Jushuitan so the two systems share a consistent inventory semantic in the disassembly scenario.

Data Flow and Field Mapping

Overall direction: Kingdee Cloud Sky (Disassembly Parent-Item Outbound) → Qeasy middleware → Jushuitan (Other Outbound Order). On the Kingdee side we capture parent-item outbound records generated by the disassembly process; on the Jushuitan side, regardless of business origin, everything is written into the other-outbound document.

Key field mapping (typical items):

The mapping layer is the most fragile part of this strategy: warehouses, SKUs, and item codes follow completely different rules on each side. They must be managed centrally in Qeasy's code-mapping module; hard-coding them in scripts only survives one or two iterations.

How to Configure in Qeasy

In the Qeasy data integration platform, the typical configuration order is: register the source system (Kingdee Cloud Sky), register the target system (Jushuitan), create the strategy, configure field mapping, then set up scheduling and alerting.

Typical configuration points:

1. Source adapter: Kingdee Cloud Sky uses its open-platform APIs. Make sure you correctly identify the document type for disassembly parent-item outbound, so it is not mixed with normal sales outbound or general outbound when pulled.
2. Target adapter: Jushuitan's other-outbound API is sensitive to required fields. Treat document date, warehouse code and item code as pre-validation: if any are missing, discard the record and trigger an alert instead of inserting a default value.
3. Centralized code mapping: For cross-system primary keys like warehouses and SKUs, maintain them in Qeasy's mapping tables so they can be reused by other strategies.
4. Header and body staged writing: Write the header first, then the lines. On failure, retry at the document level so one bad line does not corrupt the whole document.
5. Retry and alert: Distinguish business exceptions (missing required fields, unmapped codes, insufficient stock) from system exceptions; the former should not be blindly retried, the latter may need business confirmation.

Implementation Steps

In one real project we split this strategy into three phases to keep the rollout stable.

Phase 1: Incremental Start (Environment Preparation) First complete both system connectors in Qeasy and run an end-to-end test with one historical disassembly outbound document. Do not jump straight into scheduling, otherwise failure chains grow quickly. The focus of this phase: can the source pull the right document, does the field mapping line up, and can the target create the document successfully.

Phase 2: Full Backfill (Consistency Verification) After the incremental path works, perform a full backfill of historical disassembly outbound documents by date range, in order to compare inventory quantities between the two systems and confirm the acceptable variance with business owners. This phase typically exposes missing code mappings, so backfill only one or two months per day instead of pushing everything at once.

Phase 3: Scheduling Frequency and Steady-State Operation Once in steady state, set the polling frequency according to the actual cadence of disassembly operations. Disassembly typically happens at the end of a shift or during batch inventory, so polling every 15–30 minutes is usually enough; if disassembly volume is small and hourly latency is acceptable, scheduled pulls work as well. Qeasy's incremental-plus-full dual-track mechanism ensures that daily operation runs incrementally while gap-filling can switch to full-range backfill when needed.

Pitfalls and Lessons Learned

1. Wrong document type identification: Disassembly parent outbound and other outbound share similar interfaces in Kingdee Cloud Sky; relying on document-number prefixes is unreliable. The safe approach is to filter precisely using the business-type field on the document.
2. Code mapping scattered in scripts: When warehouse and SKU correspondences are hard-coded in transformation scripts, nobody remembers the mapping three months later. A common practice we have seen on customer sites is to centralize them in Qeasy's mapping tables.
3. Jushuitan does not record business origin: Jushuitan's other-outbound document does not distinguish business type, so finance teams cannot tell whether it came from disassembly, sales or transfer. Add a source tag in the remark field for traceability.
4. Insufficient stock causes hard failures: Disassembly outbound sometimes hits insufficient stock at the target. Do not drop the whole document in that case; consider splitting or sending a separate alert for business confirmation.
5. Overly aggressive retry: Kingdee's API occasionally times out during peak hours. Immediate retries can hit the same rate-limit window. Configure stepped backoff in Qeasy to avoid hammering the source system.

When to Use and When Not

Use when: Kingdee Cloud Sky and Jushuitan coexist and disassembly operations must reflect inventory in both systems; the integration focuses on parent-item disassembly outbound and minute-level latency is acceptable. Do not use when: disassembly originates entirely on the Jushuitan side, or the target is not Jushuitan's other-outbound order; this strategy only transfers documents and does not replace physical inventory reconciliation.