Pushing Kingdee Direct Transfer Orders to Wangdiantong Subcontracting Outbound Orders: A Practical Inventory Transfer Sync Tutorial
What this strategy solves
In multi-org, multi-system supply chain environments, once a direct transfer order is generated in Kingdee Cloud Skylight, the same transaction needs to land in Wangdiantong as a subcontracting outbound order, driving downstream warehouse outbound and accounting. Relying on manual entry in both systems almost always leads to mismatched quantities, inconsistent processing units, and out-of-sync document status.
Our goal is: as soon as a Kingdee direct transfer order is approved, a corresponding subcontracting outbound order is created in Wangdiantong, with quantities, batch numbers, owners, and subcontractor kept consistent. This strategy is carried by a single sync pipeline on the Qeasy data integration platform.
Data flow and field mapping
The flow is straightforward: Kingdee Cloud Skylight (source) -> Qeasy middleware -> Wangdiantong Enterprise (target). The middleware stores no business data, only does mapping, cleansing, and re-push.
Key field mapping reference:
| Business meaning | Kingdee (source) | Qeasy middleware | Wangdiantong (target) |
|---|---|---|---|
| Document No. | FBillNo | bill_no | External order No. |
| Document date | FBizDate | biz_date | Outbound date |
| Source warehouse | FOutStockId | src_warehouse | Warehouse code |
| Target warehouse | FInStockId | dst_warehouse | Inbound warehouse (optional) |
| Item code | FMaterialId | sku_id | Merchant SKU |
| Quantity | FQty | qty | Outbound qty |
| Subcontractor | FSupplierId | supplier_id | Subcontractor code |
| Document status | FDocumentStatus | doc_status | Status mapping (Approved -> Confirmed) |
The three master data types — merchant SKU, subcontractor code, warehouse code — should be centrally managed in Qeasy's mapping table. Do not scatter mapping logic across scripts; this is the most common pitfall seen on customer sites.
How to configure on Qeasy
Step 1: Connect source and target. Add Kingdee Cloud Skylight (private deployment, via API gateway or middleware) and Wangdiantong Enterprise as data sources in Qeasy, configure access credentials and IP allowlists.
Step 2: Build mapping tables. Maintain "source code -> target code" mappings for items, warehouses, and suppliers in Qeasy's centralized mapping module. Other strategies of the same kind can reuse them rather than redefining per strategy.
Step 3: Configure the strategy "Kingdee Direct Transfer Order -> Wangdiantong Subcontracting Outbound Order":
- Source API: approved Kingdee direct transfer orders;
- Target API: Wangdiantong subcontracting outbound order create;
- Trigger: scheduled pull (incremental);
- Retry: enabled, 3 retries, fallback to manual ticket on failure.
Step 4: Exception branches. Configure separate rules for "source deleted", "target already exists", and "mapping missing" rather than skipping or throwing a generic error.
Implementation steps
We typically split this kind of strategy into three phases:
Phase 1: Incremental starting point. Run a one-time push of historical "approved but not synced" Kingdee transfer orders as the incremental starting point. In Qeasy this is usually done via a one-shot "full trigger", then disabled.
Phase 2: Daily scheduling. Configure a 15-minute pull of Kingdee "newly created / status changed" transfer orders and push them to Wangdiantong. This is a typical incremental cadence; too low a frequency causes warehouse operation delays.
Phase 3: Reconciliation. Run a daily "two-side document status reconciliation" during off-peak hours to surface records that are approved in Kingdee but missing in Wangdiantong, or with mismatched quantities, for manual follow-up. Running incremental and full reconciliation in parallel is the proven pattern we use at customer sites for this category of inventory sync.
Pitfall recap
- Mapping not centralized. We initially put item mappings inside converters; months later with tens of thousands of records pushed, changing one value meant editing over a dozen strategies. Moving everything to Qeasy's centralized mapping table was the fix.
- Approval status fields not distinguished. Kingdee's "approving / approved / voided" has no exact equivalent in Wangdiantong. The safe approach is to map them uniformly in the middleware to two states — "confirmed / cancelled" — rather than pushing intermediate states through as-is.
- Pushing header and lines together causes partial writes. If the whole document write-back fails, some lines may already be in the target. The safe approach is: create the header first, submit lines in batches, allow re-entry on failure.
- Wrong incremental starting point. Starting from a timestamp easily misses historical approved documents. The safe approach is full-backfill history first, then switch to incremental.
- No reconciliation. Trusting only the "succeeded" flag is not enough. Cases where Kingdee voids but Wangdiantong does not cancel can only be caught by daily reconciliation.
Applicable and non-applicable scenarios
Applicable: Multi-org, multi-system private deployments where Kingdee is the ERP master data source and Wangdiantong is the warehouse execution system, and subcontracting processing is driven by transfer orders.
Not applicable: Pure retail store direct shipping, cross-border multi-owner split accounting, or scenarios requiring manual secondary confirmation. For those, route through an approval staging table rather than direct push.