From LingXing Process Orders to Kingdee Assembly Orders: A Production Sync Strategy on Qeasy

What This Strategy Solves

The plant issues process orders in LingXing ERP, while finance and inventory reconciliation live in Kingdee Cloud. Once the two go out of sync, monthly costs and on-hand balances drift apart fast.

On the Qeasy Data Integration Platform, we built an incremental sync link — LingXing process orders → Kingdee assembly orders. Every day, completed process orders are pulled by a time window and pushed into Kingdee as assembly/disassembly documents. The header carries document number, inventory org, bill type, and affair type; the body carries components, finished goods, quantities, and warehouses.

The real value isn't "it works" — it's "it stays stable: no duplicates, no losses, fully traceable."

Data Flow and Field Mapping

The pipeline has three layers: source (LingXing) → middleware (Qeasy) → target (Kingdee).

Key source inputs (LingXing /erp/sc/routing/inventoryReceipt/StorageProcess/getOrderLists, POST + QUERY):

Key target outputs (Kingdee batchSave, POST + EXECUTE):

The body (FEntity) expands per component line — quantity, unit, warehouse, and BOM version all map directly from the LingXing detail. A common Qeasy pattern is centralized code mapping: keep org, warehouse, and SKU mappings in one table so that when a manufacturing client adds a new plant, only the table changes — not the code.

Configuring on Qeasy

In the Qeasy console, one strategy equals one integration scenario. Key points:

1. Source platform: LingXing ERP, authorization set up. Target platform: Kingdee Cloud, account created in Kingdee with assembly document permission.
2. Source API: fill in inputs as above; start_date / end_date use the built-in variables {{LAST_SYNC_TIME|date}} and {{CURRENT_TIME|date}} — never hardcode.
3. Target API: choose batchSave; fixed fields (bill type, affair type) as constants; dynamic fields via mapping.
4. Field mapping: prefer visual drag-and-drop; use JS scripts only for complex logic (date format, UOM conversion, component row splitting).
5. Runtime settings: enable dedup key = FBillNo and idempotent write = on; skip silently on document number conflict.
6. Alerts: email / WeCom after 3 retries, with source order number and error code.

Implementation Steps

We recommend three phases — don't jump straight into full sync.

Phase 1: Set the incremental starting point Fix the initial value of LAST_SYNC_TIME. Typical approach: roll back 30 days, hardcode into the strategy variable. First run does the backfill; from the second run onward, go incremental.

Phase 2: Full sync trigger (optional) If historical span is large, add a one-shot full sync task. Stop it once finished — never run full and incremental in parallel. That is a classic failure mode.

Phase 3: Stable scheduled operation Source cron: 30 10 * * * (pull yesterday's completed orders at 10:30). Target cron: 30 12 * * * (write to Kingdee at 12:30). The two-hour gap leaves room for batch review and troubleshooting on the Kingdee side.

After running smoothly for a week, review logs: error rate, document count, duration — only hand over to ops once stable.

Lessons Learned

• Wrong time dimension: querying by create_time for "completed" status drops orders; always use finish_time, with status fixed at 2.
• Wrong target bill type: Kingdee has multiple assembly bill types; ZZCX01_SYS is the standard assembly — one typo and the doc is rejected.
• Full and incremental collide: parallel tasks wrote the same doc twice; the safe pattern is phased — backfill, then switch to incremental.
• Component row split missed: a process order with multiple components, only the first line mapped — target returns "no components".
• Dedup key not set: network jitter causes retries and duplicate submissions; the platform supports idempotency, but the idempotency key must be configured explicitly — never trust defaults.

When This Applies — and When It Doesn't

Applies: daily incremental sync of completed process orders; stable document volume; existing mapping of orgs, warehouses, SKUs. Doesn't apply: LingXing status rolls back frequently; near-real-time (minute-level) push required; cost recalculation or component quantity override needed in Kingdee — for those, use a staging table with manual reconciliation.