Qeasy Cloud
Get Started

From Wangdiantong Sales Outbound to Kingdee Direct Transfer: An Inventory Sync Strategy on Qeasy

· 吕修远· Integration Solutions· 12 views· 4 min read

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 meaningWangdiantong source fieldKingdee target fieldNotes
Outbound order no.order_noF_kd_GyBillNoDocument number, template composition
Document type(per business rule)FBillTypeIDStandard: ZJDB01_SYS; Consignment: ZJDB02_SYS
Business type(constant)FBizTypeNORMAL
Transfer direction(constant)FTransferDirectGENERAL
Transfer type(constant)FTransferBizTypeInnerOrgTransfer
Sales orgshop_noFSaleOrgIdCode mapping, centralized
Warehousewarehouse_noFStockOrgId / FOutStockIdCode mapping
Unique keystockout_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

  1. Source connector: Use Wangdiantong Qimai Qimen's wdt.wms.stockout.sales.querywithdetail API, POST method, with stockout_id as the idempotency key and order_no as the business number.
  2. Target connector: Kingdee Cloud's batchSave API, submitted according to the direct transfer template.
  3. Filter conditions: Filter by outbound order status and time window—only approved, not-yet-pushed orders—to avoid dirty data.
  4. Business routing: Use a Qeasy script node to determine the "reconciliation" and "consignment" branches, mapping FBillTypeID to ZJDB01_SYS and ZJDB02_SYS respectively. This is a typical header/body phased approach.
  5. Code mapping: Stores, warehouses, organizations, and customers all go through the mapping table; do not hardcode inside strategies.
  6. 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

  1. Consignment decision at the header, body forgotten: A typical mistake is changing FBillTypeID while 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.
  2. Store code not in the mapping table: Stuffing shop_no directly 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.
  3. Wrong idempotency key: Using order_no as the idempotency key causes duplicate posting when OMS repushes; switching to stockout_id makes the problem disappear.
  4. Unpaged batch saves: Kingdee's batchSave has a limit on lines per call; stuffing too many in one shot gets truncated. Always paginate.
  5. 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.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/strat-wdt-kingdee-cloud-7251-a-oms-c-oms-4d47afd4

Comments