Kingdee Assembly Bill Component Issue → Wangdiantong Other Stock-Out: Field Sync Playbook
What This Strategy Solves (Scenario & Value)
In one retail chain's warehouse flow, component issues from assembly bills were hand-carried between two systems: after Kingdee QJB generated the assembly bill, warehouse staff re-keyed the components, quantities, and warehouses into Wangdiantong to create an other stock-out, then reconciled on errors. We wired this through the Qeasy integration platform so the schedule runs the move automatically, humans only handle exceptions, and any break is surfaced immediately.
Data Flow & Field Mapping (Source → Middle → Target)
The source pulls the assembly-bill list from Kingdee, the middle layer filters by time window and status, the target writes the other stock-out to Wangdiantong. Key fields:
| Source (Kingdee) | Meaning | Target (Wangdiantong) | Meaning | Handling |
|---|---|---|---|---|
| billno | bill number | outer_no | external number | billno + warehouse code as idempotency key |
| id | primary key | — | — | dedup & resume anchor |
| warehouse code | issue warehouse | warehouse_no | warehouse code | unified in the mapping center |
| comment | business note | remark | remark | pass-through for traceability |
| component lines | detail array | goods_list | goods details | expand row by row in middle |
| — | — | is_check | audit flag | fixed to 1, submit as audited |
| — | — | reason | issue reason | hard-code "assembly issue" |
Configuring in Qeasy
In the Qeasy console, create an integration strategy under the Supply Chain → Business Documents domain. Source uses the Kingdee.QJB adapter with /kapi/v2/dtog/im/im_assembbill/getList, POST paged; pageSize between 20-50. Target uses the Wangdiantong.QJB adapter with wms.stockout.Other.createOther, POST execute. Auth secrets sit in the platform shared resource pool, not hard-coded in the strategy.
For mapping, all codes (warehouse, goods, reason) live in a single mapping center, not scattered across strategies — a common Qeasy customer pattern so new warehouses are added in one place. Header and detail go live in phases: header first, then goods_list, finally is_check and reason. Each phase is verified before opening the next.
Implementation Steps
- Increment anchor: First-run pulls 7–30 days of history; idCheck on to avoid duplicates. Afterwards, the bill's last-modified time becomes the increment anchor.
- Schedule cadence: Source cron
10-59/20 7-23 * * *(xx:10, xx:30, xx:50); target cron15-59/20 7-23 * * *offset by 5 minutes to avoid concurrent upstream/downstream contention. Pause 00:00–07:00 when volume is low. - Full refresh: Month-end or post-upgrade, trigger a full reload keyed on billno.
- Monitoring: Qeasy logs pulls, writes, and failures per round; exceptions land in a retry queue reviewed daily.
Field-Tested Pitfalls
- outer_no without dedup creates duplicates. A common mistake is using billno alone — multi-warehouse scenarios produce multiple orders. Hash or concat billno + warehouse code as the global idempotency key.
- Paging too aggressively triggers source rate limits. pageSize=200 returns 429. Start at 20, scale up only after latency is healthy.
- goods_list rows truncated. The target API caps rows per call (often 100). The middle layer must split batches or the whole order is lost.
- is_check=0 leaves it pending. Engineers copy the field name and pass 0; warehouse operators never see the task. For assembly issues, always pass 1.
- Time window breaks across midnight. A "from today 00:00" filter drops orders at the rollover; anchor on the last successful timestamp instead.
When to Use & When Not
Use it for assembly/disassembly scenarios where components move from ERP to WMS as separate documents, with steady cadence, dedup, and auto-audit. Do not use it for cross-org transfers with approval flows, or for sub-second picking responsiveness — those want event-driven, not polled.