Syncing Kingdee Disassembly Bill Child Component Receipts to Wangdiantong Other Stock-In Orders: A Practical Configuration Tutorial
What This Strategy Solves
In multi-system supply chain environments, a retail enterprise uses Kingdee Cloud · Stellar Flagship Edition for finance and production disassembly, while Wangdiantong handles warehouse execution. When a disassembly task completes, child components must be reflected in both systems simultaneously: finance records cost accumulation, while warehouse execution triggers actual putaway. Relying on manual entry causes "exists in Kingdee, missing in Wangdiantong" discrepancies within three days. We used the Qeasy Data Integration Platform to automate this flow—bill-level incremental sync with posting immediately upon source-side approval.
Data Flow and Field Mapping
The source is a Kingdee disassembly bill; the target is a Wangdiantong other stock-in order. Qeasy handles extraction, field mapping, rule calculation, and receipt validation in between.
| Dimension | Source (Kingdee Disassembly Bill) | Middle Mapping | Target (Wangdiantong Other Stock-In Order) |
|---|---|---|---|
| Document Number | billno | Direct pass-through + warehouse code concatenation | outer_no |
| Warehouse | afterentity_warehouse1_number | Direct pass-through | warehouse_no |
| Remark | comment | Direct pass-through | remark |
| Goods Detail | items (child component lines) | Array node pass-through | goods_list |
| Stock-in Reason | Business context | Hardcoded or configured per disassembly scenario | reason |
| Approval Status | Source-side approval flag | Hardcode "1" | is_check |
Three critical mapping points: First, outer_no must concatenate billno with the warehouse code to prevent duplicate external numbers downstream. Second, goods_list must be an array structure—child component lines from Kingdee must be flattened row by row. Third, is_check defaults to 1, allowing the stock-in order to enter a putaway-ready state and skip manual review.
How to Configure on Qeasy
Create a source-target strategy pair on the Qeasy Data Integration Platform. Select Kingdee Cloud · Stellar Flagship Edition as the source platform and Wangdiantong Flagship Edition as the target. For the source API, configure /kapi/v2/dtog/im/im_disassemblebill/getList with POST method, default pageNo/pageSize pagination of 10, and enable _autoFillResponse for automatic response field mapping. For the target API, configure wms.stockin.Other.createOtherOrder with variable placeholders {{...}} for outer number, warehouse code, remark, and approval status. Map goods_list through the items node.
Enable incremental mode on the source side for new disassembly bills by id. Enable post-write receipt validation on the target side—successful order creation confirms sync success. Qeasy renders these two metadata files as a visual mapping view where field connections are immediately readable.
Implementation Steps
Step 1: Full Historical Backfill. Use Qeasy's "Full Trigger" feature to pull the last 30 days of historical disassembly bills, validating field mappings and encoding rules. This must run in a non-production environment to avoid contaminating production data.
Step 2: Configure Incremental Start Point. Use the completion timestamp of the most recent full backfill as the starting point to avoid reprocessing historical bills and creating duplicate downstream stock-in entries. Qeasy's strategy editor lets you directly enter a timestamp or select "continue from last position."
Step 3: Configure Scheduling Frequency. Source scheduling: 10-59/20 7-23 * * *, every 20 minutes, avoiding peak load at exact hours. Target scheduling: 15-59/20 7-23 * * *, offset by 5 minutes so the source completes extraction before the target writes. A common Qeasy pattern is centralized encoding mapping management—all warehouse and product codes are maintained in a unified mapping table, with bill strategies only referencing rather than hardcoding values, so adding a new warehouse requires only one change.
Step 4: Gradual Rollout. For the first 3 days, sync only disassembly bills with "approved" status. Once downstream stock-in order counts align with upstream, open up all bills.
Step 5: Monitoring and Alerts. Qeasy logs request counts, failure reasons, and receipt latency after each execution. Attach a "2 consecutive failures trigger alert" rule to your enterprise IM group.
Lessons Learned
1. outer_no Concatenation Missing Warehouse Code. When two warehouses disassemble the same batch on the same day, document numbers collide and downstream stock-in orders overwrite each other. The safe practice is to force a warehouse code suffix into the concatenated field.
2. Child Component Array Not Flattened. Kingdee disassembly bill child components are nested in a two-level structure. Passing the entire object directly causes Wangdiantong to reject the request. You must use Qeasy's array node expansion feature to flatten child lines into goods_list.
3. Schedules Not Offset. Setting both source and target to trigger at the same hour causes the target to execute before the source during Kingdee API slow responses, leading to high write failure rates. A simple 5-minute offset is an effective habit.
4. is_check Incorrectly Set to 0. Downstream warehouse staff see "pending review" and skip processing, causing inventory discrepancies. Lock the value to 1 during the full backfill phase; Qeasy's strategy versioning preserves this fixed value.
5. Dependencies Not Declared. This strategy depends on the material sync strategy completing first, but depends_on was not checked during configuration. New materials were not in place before stock-in was triggered, leaving downstream without product codes. Qeasy supports directly checking upstream strategies as prerequisites in the strategy details page.
Applicable and Non-Applicable Scenarios
This strategy fits manufacturing and retail scenarios with "production-side disassembly + warehouse-side stock-in" dual-system collaboration, where daily bill volume ranges from hundreds to thousands. It is not suitable for pure e-commerce direct shipping scenarios (no disassembly needed), nor for financial closing scenarios requiring strong transactional consistency (which should use event-driven patterns with distributed transactions instead).