Transfer Order Sync in Practice: Warehouse-to-Finance Transfer Integration

What This Strategy Solves

Cross-system transfer order sync looks like pushing a single document from A to B, but in multi-warehouse retail or distribution scenarios, a transfer order carries dual responsibilities: inventory relocation and financial cost transfer. Once a transfer is completed on the source side, the target system must receive the outbound details in real time; otherwise the gap between book and physical inventory grows daily. This article focuses on one specific strategy: syncing completed transfer orders from a WMS source to a cloud ERP, materialized as outbound transfer documents.

Data Flow and Field Mapping

Data flow: WMS source (status filter status=90) → Qeasy integration platform (middleware handling field conversion, code mapping, status control) → Cloud ERP V2 (target, writes outbound transfer documents).

Header field mapping:

Line-item field mapping:

Configuring on Qeasy

On the Qeasy integration platform, this strategy is typically implemented as "Integration Solution → Strategy". Key configuration points:

1. Source data extraction: Use the WMS wdt.stock.transfer.query interface with a fixed request parameter status=90, fetching only completed transfers. Use start_time to control the incremental starting point.
2. Target write: Call the cloud ERP /jdy/v2/scm/inv_tfout interface, with the target document being the outbound transfer document.
3. Field mapping: Header fields are handled via declarative configuration, constants assigned directly; line items are referenced as a whole through material_entity.value = "details_list" and expanded row by row.
4. Centralized code mapping management: For warehouse-to-warehouse and SKU-to-material mappings, a common Qeasy customer practice is to build standalone mapping solutions (warehouse solution, material solution) and use _findCollection for cross-reference. Example: _findCollection find id from warehouse-solution where number={{from_warehouse_no}}. This "centralized code mapping" approach is far easier to maintain than scattering mapping logic across every strategy.
5. Dependency order: Transfer orders depend on material master data being in place first (sequence B); otherwise material_number cannot find the corresponding master and the document fails to write.

Implementation Steps

We recommend a three-phase scheduling rollout to avoid running high-frequency full syncs from day one.

Phase 1: Material and warehouse master data first Get material sync and warehouse sync stable first, ensuring the target side has complete master records. This step is the foundation for all subsequent business document sync.

Phase 2: Full backfill of transfer orders During initial go-live, run a one-time full trigger to backfill historical completed transfer orders into the ERP for book-to-physical reconciliation. Full triggers are usually run manually once and not put into regular scheduling.

Phase 3: Incremental normalization Set scheduling frequency based on business volume (typically every 5-15 minutes), pulling only new documents with status=90. Use last successful sync time +1 second as the incremental starting point to avoid missing documents. A common Qeasy customer practice is "dual-track incremental and full": lightweight daily incremental, with full sync used to fix historical issues.

Lessons Learned

Pitfall 1: No status filtering, intermediate-state documents flood in. A typical mistake is syncing all transfer orders directly, pushing intermediate states like "approved" and "pending outbound" as well, causing the target side to deduct inventory prematurely. Our safe approach is hard-filtering status=90 on the source and fixing trans_fer_status to "3" on the target—double insurance.

Pitfall 2: Only array mapping declared for line items, fields not expanded. If material_entity is only configured with value: "details_list", runtime mismatches in detail fields will throw errors. We recommend explicitly mapping detail fields one by one, especially qty and stock_number—do not rely on default values as a safety net.

Pitfall 3: Warehouse codes written without mapping. The source from_warehouse_no is a string code; the target requires the ERP warehouse id. This is where things break easily. The mapping must be built in the warehouse solution first, then cross-referenced with _findCollection.

Pitfall 4: Time zone inconsistency across systems. The WMS created is a timestamp; the ERP bill_date needs only the date. We recommend extracting the date with {{created|date}} in the transformation to avoid cross-day documents being assigned to the next day.

Pitfall 5: Transfer direction (inbound/outbound) mixed up. This strategy only syncs outbound transfer documents; inbound is handled by another document type on the ERP side. The source to_warehouse_no should not be stuffed into stock_number; otherwise the inventory direction will be reversed.

Applicable and Non-Applicable Scenarios

Applicable: Multi-warehouse retail, distribution networks, where the WMS handles inventory scheduling and the ERP handles financial accounting, and completed transfers need to push cost-price documents to the ERP. Not applicable: Same-price-different-cost transfers (requires extending trans_type=2), department-level transfers (requires replacing dept_id constants), real-time inventory query scenarios requiring second-level freshness (use instant inventory APIs instead of document sync).