Kingdee Cloud Transfer Orders Pushed to Wangdian Other-Issue-Out: A Single-Strategy Walkthrough

What This Strategy Solves

In a multi-warehouse retail operation, transfer orders are routine business: once a transfer order is approved in Kingdee Cloud, it must immediately become an "other-issue-out" order in Wangdian so picking and shipping can be triggered. On the surface it looks like a simple two-document handshake, but in practice three things tend to block progress: warehouse codes do not match between the two systems, a wrong incremental starting point causes lost orders, and a poorly chosen schedule collides with peak hours on the source. The Qeasy data integration platform tackles all three in a single strategy.

Data Flow and Field Mapping

The flow is strictly one-way: Kingdee Cloud (source) → Qeasy middle layer → Wangdian·QiMenh (target). The source side calls executeBillQuery to fetch approved transfer orders; the middle layer cleans fields and applies code mappings; the target side calls wdt.stockout.order.push to write the other-issue-out order.

Key field mapping:

Configuring on Qeasy

In the Qeasy console the strategy is structured as source integration + target integration + middle mapping. The source integration is a WebAPI query against executeBillQuery, exposing FBillNo, FID, FDocumentStatus, FStockOrgId_FNumber, FDate. The target integration is a WebAPI execution against wdt.stockout.order.push, binding outer_no to {{FBillNo}}, warehouse_no to {{FSrcStockId_FNumber}}, and routing line items into the detail_list array node.

The middle layer is where the real work happens. We lean on Qeasy's built-in "centralised code mapping" capability to keep every warehouse and SKU mapping in a single maintainable table. The source side reads from it, the target side writes through it, and neither system needs to change. This decoupling between master-data governance and sync logic is a pattern we see often among Qeasy customers — adding a warehouse or changing a code later on does not require touching the integration itself.

One small but useful detail: is_check is hard-coded to "1", which means the source side only fetches approved orders while the target side is marked as checked in a single constant. No conditional logic is needed.

Implementation Steps

Step 1 — Run a full sync first. Temporarily change the crontab to a one-shot trigger and push the last 90 days of transfer orders to Wangdian. The goal here is not go-live, but validation: once a header-body inventory sync is wrong, debugging becomes painful. Full volume first lets you catch it early.

Step 2 — Switch to incremental. After full sync succeeds, clear the test other-issue-out orders in Wangdian, set the incremental starting point to the latest FDate on the source, and adjust the crontab to */5 8-22 * * *, covering business hours. The source polls every 5 minutes; the target side is offset by 2 minutes (2-59/5 8-22 * * *) so both endpoints never hammer the source database at the same instant.

Step 3 — Stabilise and observe. Run for three consecutive business days, verify alignment on document number, warehouse, and SKU, then remove the full-volume trigger from the runbook. This is the classic "incremental plus full-volume dual track" approach: full volume for drills and emergencies, incremental for daily operation.

Lessons from the Field

• Mistake 1: choosing FID instead of FDate as the incremental cursor. In an early version we used the internal document ID for simplicity, but after a source-side re-numbering event the cursor jumped and we silently lost a full week of orders. A compound cursor of FDate + FBillNo, configured directly as the query condition in Qeasy, is the safer option.
• Mistake 2: pushing header and body together, retrying on failure, and producing duplicate lines. Retrying the whole document on header failure is fine, but once body lines are partially written, a retry duplicates them. We moved to a "header-then-body, phased" pattern: write the header first, then the body, and only retry the body segment on failure.
• One source code, multiple warehouses. When one Kingdee organisation maps to several logical warehouses in Wangdian, relying solely on the source FStockOrgId is not enough. The middle layer must apply an additional business rule, otherwise the transfer direction is correct but the destination warehouse is wrong.
• Crontab colliding with peak hours. The source system sees a concentration of approvals around 9 a.m. If the source-side query runs at the same moment, approvals slow down. The two-minute offset looks trivial in theory but pays off clearly in production.
• Idempotency by outer_no alone is not enough. Wangdian deduplicates by outer_no, but if the same external number is changed (quantity or warehouse), the target side rejects the update. In Qeasy we hash outer_no together with the detail_list content as a secondary idempotency key.

When This Applies and When It Does Not

Applies to: multi-warehouse retail and distribution scenarios where cross-warehouse transfers must trigger downstream picking in near real time, and where both sides already have a reasonable baseline of master-data governance. Does not apply to: scenarios that require bidirectional inventory availability back-writing (this strategy is one-way), or customers whose source-side organisational structure has not yet been frozen — in the latter case, master-data governance should come first.