Syncing Kingdee Assembly Bill Sub-Item Outbound to Wangdiantong Other Outbound Orders via Qeasy

What This Strategy Solves

In a subcontracted-warehouse setup, a retail enterprise runs Kingdee Cloud Galaxy for finance and supply-chain accounting and Wangdiantong Flagship Edition for WMS operations. Once an assembly bill is approved on the Kingdee side, its sub-items must generate "other outbound orders" on the WMS side for the physical outbound process. Because the two systems use different document models, manual entry is slow and error-prone. The core value of this strategy is to push the header and line items reliably through the Qeasy Data Integration Platform, so vouchers remain traceable and stock never drifts.

Data Flow and Field Mapping

Overall flow: Kingdee Cloud Galaxy (source) → Qeasy middleware → Wangdiantong Flagship Edition (target).

On the source side, the platform calls /kapi/v2/dtog/im/im_assembbill/getList, paginating via pageNo and pageSize. The primary key is id, and the business document number is billno. On the target side, data is written to wms.stockother.Out.push, which accepts two main objects: order (header) and order_details (an array of line items mirroring the sub-item entries on the Kingdee side).

Key field mapping (typical; adjust to the customer's actual schema):

Business Meaning	Kingdee Field	Wangdiantong Field	Handling Notes
Document number	billno	order.order_no	Pass through; used as the idempotency key
Business date	Business date field	order.order_date	Normalize to yyyy-MM-dd HH:mm:ss
Warehouse code	Warehouse code	order.warehouse_no	Resolved via a code-mapping table
SKU code	Sub-item material code	order_details.sku_no	Managed centrally via code mapping
Quantity	Sub-item quantity	order_details.qty	Keep two decimal places
Remark	Remark / note	order.remark	Truncate to the API's allowed length

A common Qeasy customer pattern is to centralize warehouse and SKU code mapping in the platform's code-mapping module, so downstream strategies reference one shared table instead of duplicating logic across scripts.

How to Configure in Qeasy

Register two data sources: pick the Kingdee Cloud Galaxy adapter for the source, fill in the API endpoint and credentials; for the target, choose the Wangdiantong Flagship Edition adapter and complete the WebAPI onboarding.
Build the source dataset: point the API at /kapi/v2/dtog/im/im_assembbill/getList, set pageSize to 10, keep idCheck=true for incremental recognition, and buildModel=false so no physical table is created here.
Build the target dataset: select wms.stockother.Out.push as the write API, and explicitly declare order_details as the array type items so line items can be expanded downstream.
Configure mappings and scripts: header fields map one-to-one; sub-item line items are expanded via Qeasy's batching mechanism. Encoding replacements live in a unified script block rather than being rewritten per strategy.
Storage strategy: with autoFillResponse=true and number=billno, the platform automatically returns the document number for troubleshooting and write-back.

Implementation Steps

Incremental starting point: pick an approval timestamp as the starting point on first go-live. The platform deduplicates on id to avoid duplicate pushes.
Full backfill: run a one-off full backfill for historical assembly bills during off-peak hours, writing in batches.
Schedule frequency: the source crontab is 10-59/20 7-23 * * *, and the target is offset to 15-59/20 7-23 * * *. The 5-minute offset prevents both ends from contending for the API at the same moment.
Monitoring and alerts: enable Qeasy's document tracing, search the full chain from source to target by billno, and notify the owner through an alert channel on failure rather than waiting for the business to complain.

Lessons Learned

A typical mistake is using billno directly as the idempotency key. Some Wangdiantong interfaces do not strictly enforce uniqueness, and duplicate pushes can produce multiple other outbound orders. The safer approach is to use Kingdee's id as the idempotency key and store it in Qeasy's dedup table.
Sub-item quantity precision gets truncated. Kingdee quantities may carry four decimals while the target API only accepts two, leading to a long-term 0.01 drift. It is safer to explicitly call toFixed(2) in the mapping script and validate the difference.
Warehouse codes are not mapped. The warehouse code systems on the two sides are entirely different; passing them through directly triggers "warehouse does not exist" errors on the target side. Most customers end up centralizing this mapping in Qeasy's code-mapping module.
Header and body pushed in one go. When header and lines are pushed together, any single line failure rolls back the entire document. A safer pattern is to land the header first, then write lines in batches so that failed rows can be retried without affecting already-successful ones.
Schedule clashes. Both source and target pulling near the top of the hour can hammer the API. Offsetting the two ends by 5 minutes is a detail that is easy to miss in early go-live.

When to Use and When Not to

Use it when: the subcontracted-warehouse / assembly business volume is moderate, document structure is stable, and the customer demands tight consistency between the inventory ledger and the physical count. Do not use it when: assembly bills need manual confirmation on the WMS side before being pushed, or when the target side requires splitting by bin location with complex sub-warehouse logic — those scenarios deserve a dedicated strategy of their own.