From Wangdiantong Sales Outbound to Kingdee Direct Transfer: An Inventory Sync Strategy on Qeasy
What This Strategy Solves
A retail enterprise's OMS (Wangdiantong) generates a large number of sales outbound orders every day. The ERP (Kingdee Cloud) needs to reflect these outbounds as direct transfer documents so they can be posted and reconciled. On the surface it looks like "moving outbound orders around," but two real challenges hide underneath: first, OMS and ERP have different reconciliation definitions, so some orders must take a "reconciliation" branch; second, consignment business must be identified separately, otherwise it gets posted as a normal transfer.
On the customer's site we used the Qeasy data integration platform to take on this strategy, splitting outbound orders by business type so that normal outbounds land as standard direct transfer documents while consignment orders are recognized and handled separately.
Data Flow and Field Mapping
Overall flow: Wangdiantong sales outbound order → Qeasy middle layer (cleaning, routing, code mapping) → Kingdee Cloud direct transfer document.
| Business meaning | Wangdiantong source field | Kingdee target field | Notes |
|---|---|---|---|
| Outbound order no. | order_no | F_kd_GyBillNo | Document number, template composition |
| Document type | (per business rule) | FBillTypeID | Standard: ZJDB01_SYS; Consignment: ZJDB02_SYS |
| Business type | (constant) | FBizType | NORMAL |
| Transfer direction | (constant) | FTransferDirect | GENERAL |
| Transfer type | (constant) | FTransferBizType | InnerOrgTransfer |
| Sales org | shop_no | FSaleOrgId | Code mapping, centralized |
| Warehouse | warehouse_no | FStockOrgId / FOutStockId | Code mapping |
| Unique key | stockout_id | (idempotency key) | Used to prevent duplicates |
Code mapping is maintained in Qeasy's centralized mapping table. When a customer adds a new store or warehouse, only one place needs to change—each strategy does not need to be touched. This is one of the common patterns seen among Qeasy customers.
How to Configure on Qeasy
- Source connector: Use Wangdiantong Qimai Qimen's
wdt.wms.stockout.sales.querywithdetailAPI, POST method, withstockout_idas the idempotency key andorder_noas the business number. - Target connector: Kingdee Cloud's
batchSaveAPI, submitted according to the direct transfer template. - Filter conditions: Filter by outbound order status and time window—only approved, not-yet-pushed orders—to avoid dirty data.
- Business routing: Use a Qeasy script node to determine the "reconciliation" and "consignment" branches, mapping
FBillTypeIDtoZJDB01_SYSandZJDB02_SYSrespectively. This is a typical header/body phased approach. - Code mapping: Stores, warehouses, organizations, and customers all go through the mapping table; do not hardcode inside strategies.
- Idempotency and writeback: After successful push, write back to a Wangdiantong custom field; failures enter the retry queue; alert when the upper limit is hit.
Implementation Steps
- Incremental start point: At first go-live, use a specific Wangdiantong timestamp as the start point for incremental pulls, verify document counts and samples, then backfill a period of historical full data.
- Full trigger: Full loads are usually scheduled in the early-morning low peak, backfilled in one shot while watching Kingdee's save success rate.
- Scheduling frequency: For the source we recommend every 15 minutes (a window-style expression like
0-59/15 1-3 * * *works well in the post-low-peak period). Target batch saves are concentrated between 4 and 5 a.m. to avoid contention with other Kingdee jobs. - Go-live rhythm: Run the "reconciliation" branch for a few days before opening the "consignment" branch; once both are stable in parallel, consider increasing frequency.
Running incremental and full tracks together is a common, safe approach for Qeasy customers rolling out multi-strategy integrations.
Lessons Learned
- Consignment decision at the header, body forgotten: A typical mistake is changing
FBillTypeIDwhile the body line items still go through the normal transfer logic, causing Kingdee to reject the save. The safe approach is to judge header and body together. - Store code not in the mapping table: Stuffing
shop_nodirectly into the organization field works short-term, but three months later when a store is renamed the two systems no longer agree. The centralized mapping table is mandatory. - Wrong idempotency key: Using
order_noas the idempotency key causes duplicate posting when OMS repushes; switching tostockout_idmakes the problem disappear. - Unpaged batch saves: Kingdee's
batchSavehas a limit on lines per call; stuffing too many in one shot gets truncated. Always paginate. - Time zones and date boundaries: Wangdiantong timestamps use the local time zone while Kingdee uses the server time zone, so cross-day orders can be missed. We recommend unifying on business date inside Qeasy.
Suitable and Unsuitable Scenarios
Suitable: Enterprises where OMS and ERP are separate and need to generate transfer documents from outbounds for accounting, with consignment/reconciliation routing; private deployments that want unified orchestration and visible reconciliation.
Not suitable: Scenarios where the OMS is itself part of the ERP and does not need a transfer-document middle step, or where the business does not require generating transfer documents from outbounds and can go directly through sales outbound.