Kingdee Disassembly Bill Sub-item Inbound → Wangdiantong Other Inbound Order: Outsourced Warehouse Inventory Sync in Practice
What This Strategy Solves
In an outsourced warehouse scenario, one retail enterprise uses Kingdee QJB for finance and inventory, and Wangdiantong for store and e-commerce fulfillment. When the warehouse team finishes a disassembly, the sub-items need to be received — in Kingdee this is a "disassembly bill — sub-item inbound", and it must be pushed to Wangdiantong as an "other inbound order". The two systems use different document types and coding systems, and manual re-entry easily causes missed or wrong entries. This strategy links the two, so one disassembly produces consistent inbound records on both sides.
Data Flow and Field Mapping
Data flows from Kingdee (B side) to Wangdiantong (A side), passing through Qeasy for field translation and document conversion.
| Business Meaning | Kingdee QJB (Source) | Wangdiantong (Target) | Notes |
|---|---|---|---|
| Document No. | billno | order (external no.) | billno used as external unique key; Wangdiantong dedupes by external no. |
| Doc primary key | id | — | Internal cursor, not written to target |
| Sub-item lines | disassembly entries | order_details | Array, mapped line by line |
| SKU code | sub-item material code | order_details.sku_id | Depends on material→goods upstream strategy |
| Quantity | sub-item qty | order_details.num | Units must be unified — common pitfall |
| Warehouse | outsourced warehouse code | warehouse code | Outsourced warehouse mapping; centralize maintenance |
| Business date | billdate | order.order_time | Date format conversion |
Tip: The material→goods mapping must be ready first, otherwise downstream inbound orders can't find the SKU and get silently dropped. Use Qeasy's "centralized mapping management" pattern: keep material-goods, warehouse, and unit mapping tables together, and reference them from all downstream strategies.
How to Configure in Qeasy
In the Qeasy data integration platform, this strategy consists of a source pull connector and a target write connector, chained via strategy orchestration.
Source side (pull Kingdee disassembly bills)
- Connector type: RESTful, endpoint
/kapi/v2/dtog/im/im_disassemblebill/getList, method POST, effect=QUERY. - Pagination:
pageNo/pageSize, default 1/10; recommend 50/100 in production to reduce page-turns. - Cursor:
number=billno,id=id, enableidCheckfor accurate incremental start. - Sample schedule:
10-59/20 7-23 * * *— every 20 minutes during business hours.
Target side (write Wangdiantong other inbound orders)
- Connector type: WebAPI, endpoint
wms.stockother.In.push, method POST, effect=EXECUTE. - Request:
orderheader +order_detailsline array. - Bind
order_detailsdirectly to source sub-item lines; SKU resolved via mapping function.
Strategy orchestration
- A common Qeasy customer pattern is "header and body in two phases": pull the disassembly header first, then trigger per-line conversion, so failures can be localized more precisely.
- Another common pattern is "incremental + full dual-track": on go-live day, do a full historical backfill, then switch to
billnoincremental cursor afterwards. - In Qeasy, use a data processing node for unit conversion, warehouse mapping, and date formatting before the target write.
Implementation Steps
1. Preparation: mapping tables and dictionaries
In Qeasy, prepare material-goods, warehouse, and unit mapping tables first. If the upstream uses special outsourced warehouse codes, create a dedicated "outsourced warehouse mapping" table. Centralize these mappings in one "base data management" strategy.
2. Incremental start: pick the starting billno
Before go-live, align with the Kingdee team: use disassembly bills after a specific point in time as the baseline. Set the billno starting cursor to avoid re-pulling historical documents.
3. Full backfill (optional)
If the outsourced warehouse has already run for a while and some inbound was manually recorded, do a one-time full backfill. Click the full button in Qeasy; it pulls by pageNo/pageSize and stops automatically.
4. Scheduling and staggering
Source: 10-59/20 7-23 * * *. Target: 15-59/20 7-23 * * *. Stagger by 5 minutes to avoid both sides hammering the outsourced warehouse inventory API at the same instant. Skip overnight non-business hours.
5. Go-live observation: reconciliation and alerts
For the first three days after go-live, we usually attach a temporary "end-of-day reconciliation" task in Qeasy: compare the day's total sub-item inbound qty in Kingdee vs the day's total other-inbound qty in Wangdiantong; alert via SMS if the difference exceeds a threshold. Remove the reconciliation task after three days.
Lessons Learned
Pitfall 1: material-goods mapping not ready first
Sub-item inbound depends on material mapping. If it's not ready, the SKU field is empty at write time, Wangdiantong rejects, but Kingdee has already deducted the inventory — accounts become inconsistent. Safe approach: run the material sync strategy once, then verify code consistency on both sides via SQL or a Qeasy data query node before enabling this strategy.
Pitfall 2: unit mismatch
Kingdee disassembly sub-items might be in "boxes", Wangdiantong wants "pieces". In one real project we didn't add unit conversion in mapping, quantities were inflated/deflated by 10x and only caught at outsourced warehouse counting. Unit conversion must be forced in the data processing node; never trust source fields are uniform.
Pitfall 3: warehouse code confusion
Outsourced warehouses often have multiple virtual warehouses (raw materials, semi-finished). Kingdee and Wangdiantong each name their own, easy to mix up. Maintain one "outsourced warehouse mapping" table in Qeasy, referenced by all inbound/outbound strategies, not hard-coded per strategy.
Pitfall 4: wrong incremental start
A typical mistake is setting incremental start to "today 00:00", causing all earlier-day disassembly bills to be missed. Safe approach: set start to "previous working day 23:59:59" or a specific billno, leave some redundancy; downstream dedupe by external no. handles the rest.
Pitfall 5: target API idempotency
For Wangdiantong's wms.stockother.In.push, repeated pushes of the same external no. produce two inbound orders on some versions. We usually add a dedupe check in front of the target write node in Qeasy: if external no. exists, skip. This way duplicate source pulls don't pollute data.
When to Use and When Not
Use when: outsourced warehouse business with Kingdee as finance/inventory book of record and Wangdiantong as fulfillment; daily document volume from hundreds to thousands; latency tolerance up to one hour.
Don't use when: Kingdee and Wangdiantong are in the same organization and can connect directly to each other's database (views/stored procedures are simpler); or business needs per-document real-time sync (<1 minute), which requires event-driven rather than polling scheduling.