Transfer Inbound Order Sync in Practice: From WMS to Kingdee Cloud

What This Strategy Solves

The transfer inbound order is generated after a warehouse-to-warehouse transfer is confirmed received at the destination warehouse. In real projects, the most common pain point is this: once a transfer in the e-commerce WMS completes both outbound and inbound, the data must flow back into the ERP for accounting. If the WMS receipt confirmation is not synced to the ERP in time, the inventory accounts on both sides drift apart, leaving piles of variances at month-end closing.

This strategy does one thing: it lands the transfer inbound order from the WMS into Kingdee Cloud as a "miscellaneous receipt" with document type DBRKD, then auto-submits and audits it, aligning both inventory accounts and document flow across the two systems. Paired with the transfer outbound order strategy, it forms a complete transfer loop.

Data Flow and Field Mapping

Data flow: Source WMS → Qeasy (middleware layer) → Kingdee Cloud (target).

The middleware layer transforms the source document structure into the format accepted by Kingdee's STK_MISCELLANEOUS form according to the field mapping rules, and uses the idCheck mechanism to ensure incremental sync without duplicates.

Header field mapping (key fields):

Detail line field mapping (source detail_list → target FEntity, one-to-one per row):

How to Configure in Qeasy

In the Qeasy strategy canvas, this strategy mainly configures three blocks: source query API, target save API, and field mapping.

Source: API wdt.wms.stockin.transfer.querywithdetail, type QUERY, POST method. Set the primary key field to stockin_id, the business number field to order_no, enable idCheck=true, autoFillResponse=true, buildModel=false. Use crontab */50 7-20 * * * to cover business hours.

Target: API batchSave, type EXECUTE, POST method. Set FormId to STK_MISCELLANEOUS (miscellaneous receipt), Operation to Save, and tick IsAutoSubmitAndAudit=true and IsVerifyBaseDataField=true so documents are auto-submitted and audited without manual steps. Set both number and id to the Kingdee-returned primary key id.

Field mapping: Configure header and detail mappings per the tables above using DIRECT / CONSTANT / TRANSFORM. For the date field check_time → FDate, use the expression {{check_time|datetime}} for format conversion to avoid errors when a raw string lands in a date field. There are no cross-strategy _findCollection or _mongoQuery lookups here, so the code mapping stays clean.

Implementation Steps

On customer sites, we usually follow four phases: build connections → configure strategy → shadow run → go live.

1. Build connections: In Qeasy, create data source connections to the WMS and Kingdee Cloud, then verify connectivity and authentication.
2. Configure strategy: Drop this transfer inbound strategy into a single strategy and configure source, target, and field mappings as described above. Make sure idCheck is enabled on both sides for incremental sync.
3. Scheduling: Use the high-frequency crontab */50 7-20 * * *, basically polling every 50 seconds during business hours. If round-the-clock is needed, simply expand the hour range to *, but assess source-system load first.
4. Shadow and full sync: Incremental start point — begin with transfer inbound orders created after deployment day; the source idCheck naturally filters out historical data. Full sync trigger — when historical data needs backfill, temporarily disable idCheck or run a one-off backfill script, then restore incremental mode once done.

Lessons from the Field

1. Wrong warehouse field: A typical mistake is taking from_warehouse_no (source warehouse) and stuffing it into Kingdee's FStockId. This is where things go wrong — the transfer inbound order is confirmed received at the destination warehouse, so FStockId must come from to_warehouse_no. from_warehouse_no is business reference only and does not participate in mapping.
2. Date field passed as raw string: check_time is a string on the source side; passing it directly causes Kingdee to reject it with a date format error. The safe approach is to use TRANSFORM with {{check_time|datetime}} to produce a date Kingdee can recognize.
3. Missing owner/keeper codes on detail lines: If only the header FOwnerTypeIdHead is configured but the detail-level FOwnerTypeId / FKeeperTypeId are forgotten, Kingdee will fail basic data validation on save. Fill in both groups as CONSTANT on the detail lines.
4. Duplicate pushes: Both sides must have idCheck enabled. Source deduplicates by stockin_id, target deduplicates by the Kingdee-returned id. If either is missing, the same document gets pushed twice. IsAutoSubmitAndAudit will catch it, but the logs will pile up duplicates.
5. Document type vs. inventory direction mismatch: FBillTypeID=DBRKD (transfer inbound) pairs with FStockDirect=1 (normal inbound direction). These two constants are bound together. Do not change one without the other, or Kingdee will reject the save due to type-direction inconsistency.

When to Use and When Not to

Use when: WMS and ERP are deployed separately and you need automatic accounting after destination-warehouse receipt confirmation; scenarios where manual audit is undesirable and real-time inventory alignment is required.

Do not use when: For transfer outbound (requires a separate transfer outbound strategy, this one does not cover it); cross-org or cross-entity transfers (this strategy fixes inventory org and owner to code 100 — multi-org scenarios need per-org strategies); transfers that require batch/bin-level granularity (this strategy only goes down to warehouse level).