Practical Tutorial on Synchronizing Warehouse Transfer Orders to Sales Delivery Orders

What This Strategy Solves

A warehouse transfer order is fundamentally an internal document for moving goods between warehouses, while a sales delivery order is a shipping voucher directed at customers. In one real project, the operations team of a retail enterprise required that transfer scenarios initiated by stores between warehouses be unified into sales delivery orders in the downstream ERP, so they could share the same inventory deduction, receivables accounting, and reporting dimensions as normal sales documents. We used the Qeasy data integration platform to handle this link. The core goals are: semantic conversion of the document, automatic posting, and zero loss of detail lines.

Data Flow and Field Mapping

The entire link is one-way: source system (JiandaoYun side) → Qeasy data integration platform middleware → target system (Kingdee Cloud Cosmic).

The middleware does not implement business; it only performs "translation." All encoding conversions are consolidated into a single mapping table, which is the only reliable reference for subsequent troubleshooting.

How to Configure on Qeasy

In the Qeasy data integration platform, we implement this strategy as an independent data integration flow. The main configuration points are:

1. Source data source: Select the "Warehouse Transfer Order" on the JiandaoYun side as the trigger dataset, and use the "fetch by update time incremental" approach.
2. Target data source: Configure the write API for "Sales Delivery Order" on the Kingdee Cloud Cosmic side, using the platform's built-in target system adapter.
3. Field mapping: Complete the mapping table above in Qeasy's visual mapping canvas; for complex encoding translations, use the "lookup transform" component rather than hard-coding them in JS scripts.
4. Data filtering: Only synchronize transfer orders with "Document Status = Completed"; leave the approval workflow to be handled upstream.
5. Write strategy: The target system uses an action chain of "Save and Approve" to reduce manual secondary operations.
6. Exception handling: Enable Qeasy platform alerting; if any line write fails, the entire document rolls back and triggers a retry.

Implementation Steps

We break this strategy into three phases for scheduling, which is both stable and lightweight:

1. Incremental starting point. During initial go-live, run a "full initialization" on Qeasy first to push all historical open transfer orders; then switch to the "fetch by update time" incremental mode. This step is critical and directly determines whether the two sides reconcile after go-live.
2. Full trigger. Configure a manual "full rerun" trigger button in Qeasy, reserved for operations colleagues when data discrepancies occur; incremental runs are sufficient for daily operations.
3. Scheduling frequency. Warehouse transfers are high-frequency and small-volume, so we recommend setting the scheduling interval to every 5-10 minutes, triggered by Qeasy's scheduled dispatcher; enterprises with large document volumes can compress it to 1-3 minutes, but they need to monitor the write throughput of the target system.

Lessons Learned from the Field

1. Typical mistake: writing encoding mappings inside JS scripts. When we first implemented this strategy, the warehouse code translation logic was scattered across multiple script nodes. Three months later, the two sides did not reconcile, and troubleshooting was extremely painful. The safer approach is to extract all encoding mappings into a unified "lookup transform" component on Qeasy for centralized management.
2. Destination warehouse is incorrectly written. Sales delivery orders have no "destination warehouse" field at all. If you do not explicitly ignore it in the mapping, some target systems will report an error treating it as an abnormal field.
3. "Approval takes effect" semantics lost. Once a source transfer order is approved, inventory is not deducted immediately, but sales delivery orders are often posted directly upon being written. If you do not explicitly configure "Save and Approve" or "Hold" actions in Qeasy, the inventory timing on the two sides will be inconsistent.
4. Wrong time field chosen as incremental starting point. The JiandaoYun side has both "creation time" and "update time" fields. Initially, we chose creation time, which caused retrospectively modified transfer orders to never be fetched. Only after switching to update time did the issue close the loop.
5. No idempotency added to document numbers. Repeated pushes will generate multiple sales delivery orders in the target system. We recommend using the source document number as the idempotency key in Qeasy's source deduplication component to avoid duplicate imports.

Applicable and Non-Applicable Scenarios

Applicable: Enterprises with multiple warehouses that need to unify internal transfers and external sales into the same delivery document; scenarios with moderate document volume and real-time requirements that allow a 5-10 minute delay. Not applicable: Scenarios where the source transfer process itself is temporary, and the internal and sales dimensions differ significantly (for example, transfer prices far below market prices). Forced merging will distort financial reports. In such cases, it is recommended to use standard internal stock transfer orders rather than sales delivery orders.