Overwrite Sync of Wangdiantong Other-Outbound Orders to Kingdee Staged Transfer-Out: Inventory Sync Tutorial

What This Strategy Solves

In one retail deployment, the front-end warehouse runs on Wangdiantong while Kingdee Cloud handles back-end finance and inventory accounting. Other-outbound documents (transfers, scrapping, internal consumption) generated in Wangdiantong must land as Kingdee Staged Transfer-Out documents. Otherwise, inventory and document numbers will never reconcile across the two systems. We used the Qeasy Data Integration Platform to implement an overwrite-write strategy where the source document number overwrites the target side, ensuring consistent, traceable records.

Data Flow and Field Mapping

Data flow: Wangdiantong Flagship Qimen (Query) → Qeasy middle layer → Kingdee Cloud (Execute, batchSave). The source uses wdt.wms.stockother.outquery.querywithdetail to pull other-outbound details; the target writes them via batchSave into the STK_TRANSFEROUT (Staged Transfer-Out) form.

Key field mapping table:

Source idCheck=true means the source document number acts as an idempotency key, preventing duplicate writes.

How to Configure in Qeasy

Four key configuration points in Qeasy:

1. Source metadata: Declare metadata.type=QUERY, number/id=other_out_no, enable autoFillResponse so the response structure auto-aligns, set buildModel=false to use the standard fetch path.
2. Target metadata: metadata.type=EXECUTE, FormId=STK_TRANSFEROUT, Operation=BatchSave, IsAutoSubmitAndAudit=false (save first, audit manually as a safety net). FID is extracted via the function RIGHT(remark, INSTR(REVERSE(remark),'-')-1) from the tail of the document number—this is the precondition for overwrite to work.
3. Field mapping: Bind source detail directly to FSTKTRSINENTRY, map header fields one by one, route dates and personnel through centralized code mapping.
4. Scheduling: Source cron 0-59/30 7-22 * * * (every 30 minutes, 7am–10pm); target cron 1-59/30 7-22 * * * (offset by 1 minute to avoid concurrent collisions).

In Qeasy, code mapping is centrally managed—stores, products, warehouses, and personnel are all maintained in one mapping table. Change once, propagate everywhere.

Implementation Steps

We roll out this strategy in four phases:

Phase 1: Incremental baseline. Pull only the last 7 days on first run to validate the link and confirm target-side writes are correct. Focus on mapping logic, not volume.

Phase 2: Full backfill. Once incremental is stable, trigger a historical full backfill to write legacy documents into Kingdee in one pass. After that, the system settles and only incremental runs.

Phase 3: Steady-state scheduling. Source pulls incremental data every 30 minutes; target writes with a 1-minute offset, forming a near-real-time sync cadence.

Phase 4: Exception fallback. Qeasy automatically logs failed documents and provides a rerun entry. idCheck ensures reruns overwrite existing documents with the same number rather than duplicating.

This is the common "dual-track incremental and full sync" pattern in Qeasy: full backfill as safety net, incremental as the throttle, rerun as the fallback.

Lessons from the Field

1. Don't take the FID expression for granted. We initially used other_out_no directly as FID, but Kingdee's document-number format validation rejected it. The safe approach is to slice from the remark tail using RIGHT + INSTR(REVERSE(...))—it satisfies Kingdee rules and ensures overwrite hits existing documents.
2. Headers and lines must be processed in stages. Write the header first, then the lines, linked by FID. Submitting in one shot means any single material mapping error kills the whole document, making troubleshooting painful.
3. Don't align crons on the same tick. Source 0-59/30 and target 1-59/30 offset by 1 minute may seem trivial, but during peak campaigns this is the key to avoiding target-side congestion spikes.
4. Be cautious with IsAutoSubmitAndAudit. Once set to true, any field anomaly directly produces an audited dirty document that finance can barely reverse. Keep it false in production; let humans audit. Much safer.
5. Centralize code mapping. Store, warehouse, product, and personnel mappings must live in Qeasy's unified mapping table, not scattered across strategies. Three months later when a store code changes, you update one place instead of all 27 strategies.

When This Applies and When It Doesn't

Applies: Private-deployment supply chain projects where Wangdiantong is the front warehouse and Kingdee is the back office; moderate document volume, need to overwrite-write source document numbers, hourly-level reconciliation requirements.

Does not apply: Bidirectional real-time warehouse operations (need bidirectional inventory locking, not one-way overwrite); compliance audit scenarios where Kingdee prohibits overwrite writes and requires strict trace retention.