From LingXing Split Orders to Kingdee Disassembly Orders: A Single-Strategy Sync Playbook

What This Strategy Solves

A retail customer's supply-chain hub runs on LingXing ERP, while finance and inventory accounting sit in Kingdee Cloud. Every day the warehouse produces a large number of split orders out of one-step process orders: a bundle SKU is broken down into several basic components, and on the books the parent must be deducted while the children are added. If these documents are only recorded on the LingXing side, inventory and cost numbers in Kingdee will silently drift.

The single question this strategy answers is: pull LingXing's finished split orders incrementally by completion time, transform them into Kingdee Cloud disassembly orders (transaction type Dassembly), and write them back, so the two sides stay aligned. It is essentially a mirror of an inventory transaction, not master-data synchronization.

Data Flow and Field Mapping

The overall direction is LingXing ERP → Qeasy middle layer → Kingdee Cloud.

On the source side (LingXing), the integration calls the process-order query API /erp/sc/routing/inventoryReceipt/StorageProcess/getOrderLists, with document type fixed to 2 (split order), process status filtered to 2 (finished), and the time dimension set to finish_time. Records are pulled incrementally between start_date and end_date.

On the target side (Kingdee), the integration calls batchSave for batch writes, with document type ZZCX01_SYS (standard assembly/disassembly) and transaction type hard-coded to Dassembly.

Key field mapping (simplified):

Code mappings should be centrally managed in Qeasy's mapping table rather than scattered across every strategy — they can then be reused when similar strategies are cloned.

How to Configure It on Qeasy

On the Qeasy integration platform this strategy is split into two flows: a source QUERY flow plus a target EXECUTE flow, chained through the same staging table or message topic.

Configuration essentials:

1. Source flow: HTTP POST to LingXing's query API. start_date is bound to {{LAST_SYNC_TIME|date}}, end_date to {{CURRENT_TIME|date}}, replaced automatically by the platform. Pagination parameters (offset / length) keep their defaults and rely on Qeasy's built-in paginator to loop.
2. Middle layer: in the data-transformation step, flatten LingXing's parent and child rows into Kingdee's disassembly entry structure. The most common pitfall here is unit and sign handling — children are positive, parents are negative. Centralize this in an expression node.
3. Target flow: call batchSave and push the transformed array into the Model array. Qeasy's execution node supports partial-success semantics — a single-document failure won't fail the whole batch, but you must turn on the document-number idempotency switch to prevent duplicate disassembly orders on retries.
4. Scheduling: source flow 30 10 * * * (10:30 daily), target flow 30 12 * * * (12:30 daily). The 2-hour gap is intentional — it absorbs cross-day data and retry windows.

Implementation Steps

We split rollout into three phases:

• Phase 1: Incremental starting point. On the first run, only the last 7 days are processed so we can verify one-to-one matching of document numbers. Qeasy allows manually setting LAST_SYNC_TIME, no code changes required.
• Phase 2: Full backfill trigger. Temporarily override start_date in the source flow to the business go-live date and run a one-shot historical backfill. As soon as it completes, switch LAST_SYNC_TIME back to incremental mode, otherwise the next run will pull everything again.
• Phase 3: Stabilize scheduling frequency. After a week of observation with no latency and no duplicates, lock the crontab at source 10:30 / target 12:30. If volume grows, switch to a 2-hour micro-batch cadence and make the dual-track incremental + full pattern normal.

Pitfalls We Hit in the Field

1. Wrong time field, silent data loss. The classic mistake is filtering on create_time, which means back-dated or revised orders can never catch up. The reliable approach is to filter by finish_time and use it as the idempotency key.
2. Sign flipped on split documents. LingXing returns both parent and child quantities as positive. The middle layer must explicitly turn the parent quantity negative, otherwise Kingdee will over-stock on every posting.
3. Re-runs produce duplicates. The source API is not naturally idempotent. You need both Qeasy's document-number mapping table and the target-side idCheck switch. We have seen sites forget idCheck and discover hundreds of duplicate disassembly orders only three weeks later during reconciliation.
4. Inconsistent org codes. LingXing warehouse IDs and Kingdee FStockOrgId are not the same dictionary. A mapping table is mandatory, and it must be kept in sync with org changes — otherwise documents stall at org validation.
5. Header and body written in one shot. If a single call fails on a header+body payload, retry cost is significant. Qeasy supports a "header first, body later" pattern that fits this scenario well — we recommend staged header/body commit.

Where This Applies and Where It Doesn't

Applies: retail/distribution scenarios where child components are fixed, parent volume is stable (tens to hundreds of documents per day), and the inventory org is single; also projects that have already synchronized master data from LingXing to Kingdee and now need to close the business-document loop.

Does not apply: manufacturing scenarios where parent decomposition rules change frequently and BOMs must be generated dynamically; scenarios where Kingdee enforces a strong approval workflow that requires human intervention before posting; and the early gray-release phase of an unstable source API — in that case, land documents into a staging table first, then drive downstream asynchronously.