Inventory Transfer Outbound to Kingdee Stepwise Transfer-Out Sync: A Single-Strategy Implementation Guide

What This Strategy Solves

When transfer orders flow across multiple organizations and warehouses, a missing or unstable handoff between the source transfer-outbound document and the target stepwise transfer-out document often leads to mismatched document numbers, mismatched line items, and mismatched statuses. In one retail distribution project we worked on, inter-store transfers happened constantly: the source system generated documents at the order level, while the target system advanced them through a stepwise workflow, and the two systems used entirely different code systems and state machines. We used the Qeasy Data Integration Platform to stabilize this single strategy first, then used it as a reference template for 40+ other sync tasks.

Data Flow and Field Mapping

The data flows as source system → intermediate layer → target system. The source side is the transfer-outbound document; the target side is the stepwise transfer-out document. The intermediate layer is the core responsibility carried by the Qeasy platform: it first lands the source payload as standardized records, then transforms them into the structure required by the target save API.

The key field mapping is roughly as follows:

In practice, the warehouse, organization, and SKU code systems are completely different on the two sides. We therefore adopted the common Qeasy pattern of centralized code-mapping management: mappings such as src_warehouse_code → FOutStockOrg and sku_code → FMaterialId are stored in a Qeasy mapping dataset, and the strategy reads them by version number at runtime so that nothing is hard-coded inside the script.

How to Configure It on Qeasy

A typical strategy on the Qeasy platform is configured in four parts:

1. Data source registration: the source uses the flagship WMS's standard open API to pull transfer-outbound documents at the document level; the target calls the ERP's document-save API. Both are registered and authorized under Data Sources on the platform.
2. Data modeling: the intermediate layer is modeled with source-side fields as the baseline, plus redundant target-side fields such as dest_wh_code and FMaterialId to make troubleshooting easier.
3. Field mapping and transformers: configure source → intermediate → target mappings in Qeasy's mapping canvas. Encoding replacement, date formatting, and status translation are attached as transformer nodes.
4. Execution strategy: use the staged header-then-lines pattern. First write the header (document number, date, warehouses, reason) to the target and obtain the FBillNo; then, using that FBillNo, push the line items; finally, write back the intermediate layer's status field as generated.

Implementation Steps

We generally bring a strategy like this online in three phases:

Phase 1 — Define the incremental bootstrap. Pick 1–2 recently approved transfer documents from the source, manually trigger a full trial run on Qeasy, and verify that FBillNo, warehouses, SKUs, quantities, and batch numbers line up one-to-one on the target.

Phase 2 — Configure a full reload. In the platform's schedule center, configure a one-shot full reload with the time window set to "recent N days, status = approved and not yet pushed to target". Once validation passes, disable it.

Phase 3 — Set the schedule cadence. In the first two weeks of production, poll every 15 minutes (the source provides a last_modified_time field for incremental cursors). After two weeks of stability, relax to every 30 minutes. No missed runs at night, and use the source's last_modified_time cursor as the incremental boundary.

Lessons Learned

• Typical mistake: only handling the approved status. The source has additional statuses such as partially shipped and completed, while the target stepwise document only accepts a two-state machine (pending transfer / transferred). We added a status whitelist; source documents outside the whitelist are skipped with a warn log entry.
• Typical mistake: confusing warehouse codes with organization codes. The source has Warehouse A, but the target ERP splits that into inventory organization + warehouse. The safe approach is to maintain two sets of mappings in the mapping table — src_warehouse_code → FOutStockOrg and src_warehouse_code → FOutWarehouse — and fill them in at the line-item dimension at runtime.
• Typical mistake: header succeeds but lines fail, and there is no rollback. The intermediate layer should add a target_doc_status field on every target document record. When the header has been generated but the lines fail, a scheduled compensation task should retry, rather than re-pushing the entire document.
• Typical mistake: the batch/lot field is empty in the source, which causes the target to error out. Non-batch-managed items have an empty batch_no in the source, but the target treats it as required. We added a transformer that writes a default placeholder when batch_no is empty and logs an info entry.
• Typical mistake: hard-coding the incremental bootstrap to "now". If the source has no new documents when the strategy first runs, subsequent increments will skip any documents whose approval time falls between the strategy start and the first scheduled run. The safe approach is to make the incremental bootstrap configuration default to a 7-day look-back with a bootstrap=true flag, then switch the schedule to the normal incremental cursor.

When This Applies and When It Doesn't

Applies to: multi-organization, multi-warehouse retail and distribution scenarios where the source already has an approval flow, the target advances documents stepwise, and daily transfer volumes are in the hundreds to low thousands. Does not apply to: scenarios where the source has no approval flow, the target requires real-time second-level write-back, or the two sides have no rule-based encoding system that can be captured in a mapping table.