Kingdee Assembly Sub-Component Outbound to WMS Production Outbound: A Single-Strategy Sync Walkthrough

What this strategy solves

The assembly document is a common business form in manufacturing: when a finished good is received into stock, sub-components must be deducted from the warehouse in BOM-defined ratios. In Kingdee Cloud this is reflected as the "Assembly Sub-Component Outbound" document, and the corresponding downstream action is the warehouse picking sub-components per the assembly. When warehouse operations run on WDT WMS, the Kingdee assembly sub-component lines must be pushed over as production outbound documents. This strategy keeps the "ERP deducts, WMS releases" ledger aligned, preventing sub-component book-to-floor drift.

Data flow and field mapping

The data flow is one-directional: Kingdee Cloud (source) → Qeasy (middleware, handling field mapping, incremental filtering, retry) → WDT WMS (target).

On the source side, executeBillQuery retrieves both header and sub-component lines. Key fields include FID, FBillNo, FDocumentStatus (C = audited), FStockOrgId.FNumber, FDate, FBillTypeID, and so on. The watermark for incremental sync is typically FModifyDate.

The middleware does three things: filter by document status (only push C), split header and body into two phases, and backfill missing values and codes.

On the target side, WDT_WMS_STOCKOUT_CREATE creates the production outbound document. The payload is wrapped in a deliveryOrder object, and the line items live under the orderLines array (with details as the array source).

Key field mapping (abbreviated):

How to configure on Qeasy

On the Qeasy Data Integration Platform, this strategy lives as an "integration scenario" with one source node, one mapping layer, and one target node.

Source node highlights: API = executeBillQuery, method = POST, autoFillResponse enabled; watermark field = FModifyDate; idCheck=true for dedup; include FDocumentStatus='C' in the filter so that draft, created, and in-audit documents are excluded.

Mapping layer: for sensitive codes — stock org, material, customer/supplier — we strongly recommend a single "code mapping table" maintained centrally, instead of scattered transforms inside every strategy. This is the most common and stable pattern among Qeasy customers. The header/body two-phase and incremental-plus-full hybrid patterns apply equally here.

Target node highlights: API = WDT_WMS_STOCKOUT_CREATE, method = POST; inject the header as an object and the lines as an array, with details as the line source; leave the response empty (the write API does not need to feed keys back to the source).

Scheduling: source side uses 1-59/2 * * * *, target side uses 1-59/3 * * * *, leaving a one-minute gap for the middleware to map and retry.

Implementation steps

We recommend three phases.

Phase 1 — Incremental kickoff. Pick a clear watermark on the Kingdee side (a specific date) and only push documents modified after that point. Do not start with a full historical backfill mixed into the live stream.

Phase 2 — Full backfill. Once incremental sync has been stable for a week, run a one-shot historical backfill (usually in batches by document date). After it completes, immediately switch the schedule back to the regular incremental mode.

Phase 3 — Schedule cadence. The source polls every 2 minutes for audited assembly changes; the target consumes from the middleware every 3 minutes. On rate limits or network hiccups, Qeasy's retry policy uses exponential backoff and re-queues automatically.

After go-live, monitor three metrics in Qeasy's operations dashboard: source-side row count, target-side write success rate, and the line-array expansion count (to catch missing details rows).

Pitfall retrospective

Pitfall 1 — Incomplete status filter. A common mistake is to filter only FDocumentStatus='C', but overlook D (re-audit). Documents in re-audit may have unstable fields and can cause quantity mismatches downstream. The safe move is to explicitly exclude D in the filter.

Pitfall 2 — Header and body collapsed into one layer. Kingdee's assembly document has a two-layer structure (header + sub-component lines), while WDT's outbound document requires the lines as an array. If FSubEntity is not declared as an array source on Qeasy, the write API will only receive the header and lose every line — visible on the floor as "outbound created, but with no lines."

Pitfall 3 — Scattered code mappings. If stock-org codes and material codes are translated per-strategy, a single code change in any org three to five months later forces edits across the entire network. A centralized mapping table turns this into a single edit.

Pitfall 4 — Using create time as the watermark. Using FCreateTime will miss documents that were un-audited and re-submitted. FModifyDate is the more reliable watermark.

Pitfall 5 — Target succeeds but source keeps re-sending. WDT returns success, but if Qeasy does not capture the receipt identifier, the next poll pulls the same document again. Use FBillNo as the idempotency key together with a middleware dedup table.

Where this fits and where it doesn't

This pattern fits manufacturing enterprises that run finance and BOM management on Kingdee Cloud while warehouse operations run on WDT WMS, and need to sync assembly/disassembly sub-component outbounds to WMS in near real time. It does not fit pure distribution scenarios, trading firms without BOMs, or strict "dual-write" consistency requirements — this is a one-way sync, and month-end reconciliation is still required to close any residual book-to-floor gap.