Transfer Order Sync from Wangdiantong to Yonyou BIP: A Hands-On Inventory Replenishment Guide

What This Strategy Solves (Scenario and Value)

In a multi-warehouse replenishment project for a retail enterprise, we ran into a very typical pain point: the source system keeps refreshing the transfer order status based on outbound progress (from "pending outbound" to "partially outbound" to "transfer complete"), while the target ERP, acting as the backend finance and inventory accounting system, needs the same transfer order to perform inter-organization settlement. If the two systems rely on manual export and import, the books stop balancing within a week. The essence of this strategy is to treat the "transfer order" as a cross-system business object, performing near-real-time one-way sync on the Qeasy data integration platform, so that key information such as the outbound organization, inbound organization, transaction type, and line quantities remain consistent across the two systems.

Data Flow and Field Mapping

The overall flow is one-way: Wangdiantong (Enterprise Qimen) → Qeasy middle layer → Yonyou BIP. The source side pulls incrementally via wdt.stock.transfer.query based on start_time / end_time, and the target side writes transfer orders via /yonbip/scm/transferapply/save. The following table shows the core field mapping.

Worth highlighting is outorg. It is not a simple field, but a lookup expression: it reverse-looks up the organization code in Yonyou BIP from the organization-warehouse mapping collection based on the source-side from_warehouse_no and to_warehouse_no. This is the typical Qeasy approach to "centralized encoding mapping management"—collecting the many-to-many warehouse-to-organization correspondences into a single mapping table rather than scattering them across each strategy.

How to Configure on Qeasy

When configuring the source API, start_time uses {{LAST_SYNC_TIME|datetime}} to take the last sync time, and end_time uses {{CURRENT_TIME|datetime}} to take the current time, achieving a true incremental window. status here defaults to 90 (transfer complete), meaning only the final state is pushed to Yonyou BIP for settlement, avoiding repeated overwriting of intermediate states that would corrupt the target system.

For the target write API, both number and id are set to transfer_no, and idCheck is enabled, so that the same document is recognized as an update rather than an insertion the second time it enters the system, preventing one document from being pushed as two.

There are two details worth enabling on Qeasy: first, autoFillResponse, which lets the platform auto-complete the response structure and saves you from hand-assembling JSON when troubleshooting; second, keep buildModel off, because the transfer order request structure is fixed and does not require dynamic modeling by the platform.

Implementation Steps

We break the rollout into three phases to move forward steadily:

1. Incremental starting point calibration. First initialize LAST_SYNC_TIME in Qeasy to a historical point in time, run a one-time full backfill to bring all historical completed transfer orders into Yonyou BIP. This step must be done in an environment where the target system is empty or can be idempotently overwritten.
2. Phased scheduling. The source side crontab = 4-59/10 * * * *, pulling every 10 minutes with an intentional 4-minute offset to avoid colliding with the target side's write peak; the target side crontab = 9-59/10 6-23 * * *, landing every 10 minutes during business hours (6:00–23:00) and pausing at night to reduce pressure on Yonyou BIP.
3. Incremental and full dual-track operation. The incremental strategy keeps running at the above rhythm, while a "full reconciliation" task is triggered on a weekly schedule to re-fetch completed transfer orders from the past 7 days and perform idempotent replay to make up for missed records.

Lessons from the Trenches

• The cascading effect of a missing outorg: outorg and outaccount are resolved by _findCollection. If a warehouse is missing from the mapping collection, the entire document will throw an error on the Yonyou BIP side, and the error will not point to a field name. The safe approach is to validate before going live, using select count(*) to verify that every from_warehouse_no / to_warehouse_no combination that has appeared on the source side has a value in the mapping collection.
• The hidden cost of status=90: By syncing only the completed state, intermediate states (such as partially outbound) become invisible in Yonyou BIP. Some finance reconciliation requires intermediate states, so "phased header and body" fits very well here—the header only pushes the completed state, and line quantity changes are pushed by a separate strategy.
• Time window too narrow loses records: The incremental window is only 10 minutes. If one extraction attempt fails and skips a beat, the documents in that time window are lost. The dual-track full reconciliation exists precisely as a safety net for this.
• Encoding rule conflicts: The Yonyou BIP code field allows customization, while Wangdiantong's transfer_no is generated by the platform. Direct passthrough may result in non-compliant prefixes. It is recommended to add a transfer_no → internal document number conversion function in the middle layer rather than feeding it directly to the target.
• Empty-body documents: The source side occasionally returns "shell transfer orders" with only a header and no line items. Writing them over will cause Yonyou BIP to report empty line items. Adding a line of if line_items.length == 0 then skip in the Qeasy script is the lowest-cost safety net.

Applicable and Non-Applicable Scenarios

Applicable: in a multi-warehouse network, the source ERP/OMS already runs transfer business, but the target finance/accounting system needs structured transfer orders for inter-organization settlement, with minute-level real-time requirements. Not applicable: the target system needs to see the full transfer process (the complete state machine from creation to outbound to inbound), or source-side transfer orders will be manually modified and need to be written back. In these two cases, a bidirectional sync or event-driven solution is required.