Practical Guide: Syncing Transfer-In Orders from Wangdiantong to Kingdee Cloud Starry Sky as Distributed Transfer-In Documents

What this strategy solves

In multi-org, multi-warehouse retail and distribution businesses, stock transfers happen daily: once the source-side warehouse confirms receipt in the Wangdiantong WMS and generates a transfer-in order, the inventory organization needs to be booked in Kingdee Cloud. Because the two systems use different coding schemes, org structures, and owner dimensions, documents can easily drift — orders arrive on one side but no ledger entry appears on the other, and the numbers stop matching. This strategy converts audited transfer-in orders from Wangdiantong into structured distributed transfer-in documents in Kingdee, so the books and the reality stay aligned.

Data flow and field mapping

End-to-end flow: Wangdiantong flagship Qimeng (source) → Qeasy data integration platform (middleware: cleaning, mapping, enrichment) → Kingdee Cloud Starry Sky (target: distributed transfer-in document).

Key field mapping:

The source calls wdt.wms.stockin.transfer.querywithdetail (POST, QUERY) and pages through audited orders with details; the target posts via Kingdee's batchSave (POST, EXECUTE) to submit distributed transfer-in documents in batch. Detail rows (SKU, quantity, batch, owner, etc.) are expanded in the middleware into the Kingdee entry structure.

How to configure it in Qeasy

1. Source platform: pick Wangdiantong flagship Qimeng, configure authorization (private deployment uses an internal endpoint), call stockin.transfer.querywithdetail, and let Qeasy handle paging cursors automatically.
2. Target platform: pick Kingdee Cloud, configure batchSave, and select the distributed transfer-in document form.
3. Field mapping: rules such as "warehouse → inventory org" and "owner type → constant" should be centralized in Qeasy's coding-mapping module rather than scattered across each strategy. Kingdee's org and owner values are reverse-looked-up by warehouse code — no hardcoding.
4. Data cleansing: convert the source check_time (milliseconds) using a _function FROM_UNIXTIME(...) in the middleware; filter empty fields against Kingdee's nullable constraints; deduplicate barcodes and batch numbers.
5. Write-back and reconciliation: enable a header-body staged pattern — submit the header to obtain Kingdee's internal document ID, then fill the body entries and submit a second time. On failure, only the body retries, so rollback cost stays low.

Implementation steps

1. Incremental starting point: run a full sync the first time, pulling from the business go-live date using check_time; afterwards switch to incremental, using the source-side maximum audit time as the watermark stored in Qeasy's offset store.
2. Full sync triggers: in a private-deployment environment, run a full catch-up at month start or cut-over date, ideally during the low-peak window (early morning).
3. Scheduling cadence: the source cron is something like 5-59/5 7-22 * * * (every 5 minutes, 07:00–22:00); offset the target by a few minutes, e.g. 10-59/5 7-22 * * *, so the two ends don't fight for the same window.
4. Retry and notifications: configure exponential-backoff retries on the Qeasy side; after 3 failures, route to a "needs human" queue, and send alerts to the team's IM channel.
5. Reconciliation: at end of each business day, diff the Kingdee inventory ledger against the Wangdiantong stock-in stream; if the variance exceeds a threshold, auto-generate a ticket.

Pitfalls and lessons learned

• Common mistake: using source created_time as the business date. The gap between order creation and audit can cross days; transfer bookings should use check_time, otherwise period-crossing documents appear at month end.
• Common mistake: hardcoding inventory org and owner as constants. In multi-org tenants, the org and owner corresponding to the receiving warehouse are dynamic; the safe approach is to maintain a warehouse–org–owner mapping table centrally in Qeasy.
• Common mistake: writing header and body in one shot. Kingdee's distributed transfer-in body depends on the header's internal ID; a combined submission rolls back entirely on failure. With header-body staged submission, problems are localized and retries are granular.
• Common mistake: ignoring post-audit edits. Wangdiantong transfer-in orders can still be edited after audit (e.g. quantity adjustment); the source pull must reflect the latest audited version. Use document number as an idempotency key in the middleware to avoid double-posting.
• Common mistake: private-network jitter leading to timeouts on long transactions. On the Qeasy side, split batchSave into small batches (one header plus a bounded number of entries), staying within the limits the target database tolerates. Long transactions disappear.

When this applies — and when it doesn't

Applies: multi-org transfer processes already running offline; you need to convert Wangdiantong WMS stock-in flows into distributed transfer-in documents in Kingdee with daily reconciliation.

Does not apply: the source has not enabled the transfer-in order module, or the target org/owner dimensions are not yet set up. Nor is it suitable for hard-real-time use cases requiring sub-second latency — this strategy is minute-level incremental.