Syncing JKY Assembly/Disassembly Orders to Kingdee Cloud Stellar: A Single-Strategy Integration Playbook

What This Strategy Solves

Assembly and disassembly orders are a classic supply-chain business document: finished goods inbound, raw materials outbound, and inventory state all change in a single transaction. In a recent project, a retail enterprise ran front-end operations on JKY and kept back-end finance and inventory accounting in Kingdee Cloud Stellar, with mismatched codes, organizations, and transaction types across both sides. When the two systems relied on manual double entry, within three months the front end had documents the back end never posted, or quantities matched but amounts did not. We used the Qeasy Data Integration Platform to take this on, building a single sync strategy dedicated to assembly/disassembly orders: pulling completed orders from JKY over a time window, translating them into a form Kingdee Cloud Stellar understands, and writing them back in batch.

Data Flow and Field Mapping

The overall flow is: JKY (QUERY) → Qeasy middleware layer → Kingdee Cloud Stellar (EXECUTE batchSave).

The source calls erp.combined.get to fetch the list of assembly/disassembly orders. Input uses modifyStartDate and modifyEndDate as the incremental window, defaulting to "from one day ago to 30 minutes before now," with status=2 so that only completed orders are pulled and we never push drafts or in-review documents downstream.

Key field mapping (selected, based on the source material; fields not present are not listed):

Two design points stand out: first, environment-level fields like organization, document type, and owner are not mapped dynamically; they are written as constants in the middleware to reduce later operational surface. Second, assembleType is translated into Kingdee's transaction type enum via a case when function — a textbook example of "centralized code mapping management."

How to Configure on Qeasy

Source strategy: pick the erp.combined.get API, POST request, and package the three fields modifyStartDate, modifyEndDate, and status into the request body. The incremental window is controlled by the built-in {{DAYS_AGO_1|datetime}} and _function from_unixtime({{CURRENT_TIME}}-1800,'%Y-%m-%d %H:%i:%s'). The 1800-second look-back buffer covers upstream write latency — emphasized again in the pitfall section below.

Target strategy: use Kingdee Cloud Stellar's batchSave, still POST. The middleware does two things: first, write header fields (document number, organization, document type, transaction type, owner) according to the mapping above; second, handle the body — material, quantity, batch number, and so on — in phases, using the source document number as an idempotency key to avoid duplicate writes.

This setup reflects common Qeasy customer patterns quite completely: code mapping is centralized in the middleware script, header and body are maintained on two parallel tracks, and incremental sync runs on a time window while full sync relies on manual triggers.

Implementation Steps

Phase 1, align the incremental starting point. First, go back to the latest historical modifyDate on the source side and run a full backfill of existing assembly/disassembly orders. This step is usually completed with a manual full-trigger, after which the flow switches to the incremental window.

Phase 2, enable incremental scheduling. The source crontab is set to 4-59/10 6-22 * * *, meaning every 10 minutes at the 4-minute mark between 6:00 and 22:00 daily. The target is offset by 4 minutes: 8-59/10 6-22 * * *. The two are staggered so the source has enough time to land data in the middleware layer. Stopping at 22:00 avoids dirty writes during the upstream system maintenance window overnight.

Phase 3, exception handling. We recommend configuring an internal strategy on Qeasy — something like an "Operations Manager Bot" — to watch failed documents and trigger manual handling or automatic retries. After the full flow has run for one to two weeks, verify that document numbers and inventory ledgers align on both sides.

Pitfall Retrospective

First, never skip the look-back window. In the source material, modifyEndDate uses "current time minus 30 minutes." A typical mistake is to write {{CURRENT_TIME}} directly. When an upstream document hits status=2, the back end may still be doing 5 to 10 minutes of asynchronous writes, so boundary values get dropped, and the next day's reconciliation shows missing documents.

Second, do not filter by status alone based on the "completed" state. Pulling only status=2 looks clean, but if the upstream review flow includes a terminal state like "closed=3," those documents still need to land in Kingdee — otherwise you get the awkward case where the front end closes the document but the back end never posts it. The reliable approach is to write status as a configurable multi-value parameter and adjust it after go-live based on the actual state machine.

Third, never carry organization and owner constants from the source side. They are tenant-level configuration in Kingdee. Following source-side fields leads to the embarrassment of "identical organization codes with different meanings on both sides." A common on-site failure is that the source-side organization field is null, the middleware has no default, and the data drops into Kingdee with an error.

Fourth, keep idempotency keys stable. Using JKY's assNo directly as an idempotency key works, but note that once Kingdee writes back the id, if subsequent incremental syncs re-fetch the same document (with no status change), the conflict will hit because idCheck=true. The safe approach is to write back only when the status actually changes.

Fifth, write the body in phases. Pushing an entire assembly/disassembly document via a single batchSave means many fields with deep nesting, and failure debugging is expensive. The recommended approach is to write the header alone first, confirm FBillNo is in the database, and then push body details in batches.

When This Fits — and When It Does Not

Fit: enterprises where the front-end business system handles assembly/disassembly operations and the back-end ERP is the inventory and accounting point of consolidation, with mismatched codes and organization structures between the two. Not fit: scenarios requiring sub-second real-time shop-floor coordination, complex multi-org assembly workflows, or large-scale historical backfill and recomputation.