Transfer Order Sync Strategy Tutorial: Designing the Inventory Transfer Pipeline from YonBIP to Wangdiantong

What This Strategy Solves

Transfer order sync addresses the problem of "cross-system inventory transfer business that cannot close the loop automatically." In one retail engagement, business users created transfer applications in YonBIP as the back-end ERP, and after approval, store or e-commerce warehouses needed executable transfer-out and transfer-in orders in Wangdiantong to drive physical movement. When the two systems are not synchronized, the typical symptoms are: the same transfer order is keyed into both sides, numbers do not match, responsibility is unclear, and there is often a delay where "BIP is approved but Wangdiantong has not been pushed."

We used the Qeasy data integration platform to take over this segment of the pipeline. In essence, it pulls transfer application orders from BIP on a scheduled cadence, cleans them, and writes them into Wangdiantong so the inventory semantics stay consistent on both sides.

Data Flow and Field Mapping

Overall flow: YonBIP (source) → Qeasy integration platform (middleware) → Wangdiantong (target). The source side pulls transfer application orders through POST /yonbip/scm/transferapply/list, and the target side pushes them via wdt.stock.transfer.push.

Below is the key field mapping (desensitized and generalized):

Business meaning	YonBIP source field	Wangdiantong target field	Middleware handling
Order number	code	outer_no	Substituted directly with `{{code}}` as the external order number to prevent duplicates
Source warehouse code	outwarehouse (source context)	from_warehouse_no	Looked up via `_findCollection` against a mapping table for warehouse code conversion
Target warehouse code	inwarehouse (source context)	to_warehouse_no	Same as above; the target side maintains its own warehouse dictionary
Contact phone	Phone field	telno	Defaults to empty and can be filled in later
Remark	bustype_name + memo	remark	Concatenated as `YS{{bustype_name}}{{memo}}` for human traceability
Transfer type	Business type	transfer_type	Mapped to the target's enum values

The middleware is more than a field shuttle. It does three things: deduplication (outer_no idempotency), code conversion (especially for master data such as warehouses, where each system maintains its own dictionary), and enumeration alignment for transfer types.

How to Configure in Qeasy

In the Qeasy console, this strategy is modeled as two chains: a "source query" and a "target execute."

Source configuration: Choose POST /yonbip/scm/transferapply/list. Set pagination pageSize to 100, and let the platform auto-paginate pageIndex. Use open_vouchdate_begin / open_vouchdate_end as the document time window for incremental pulling. Enable autoFillResponse so the platform auto-fills the response structure. Set idCheck to true to avoid pulling the same document twice.
Target configuration: Choose wdt.stock.transfer.push. The key point is that the warehouse fields reference our pre-maintained mapping table via _findCollection (centralized code mapping is a common Qeasy customer practice). The remark field uses a template string for concatenation. outer_no references the source order number directly.
Schedule configuration: The source cron is */2 * * * * and the target cron is 1-59/2 * * * *, staggered to avoid resource contention. Enable exception retry and alerting.

Implementation Steps

We recommend a three-phase rollout, which is a relatively safe rhythm among Qeasy customers:

Phase 1: Incremental starting point. Start with a monthly time window (for example, the most recent 7 days) to bootstrap incrementals and catch up on historical transfer orders that have not been pushed. The focus of this phase is to verify that the deduplication field outer_no works correctly and avoid duplicate pushes.
Phase 2: Full-volume trigger. During a business off-peak window (for example, early morning), catch up on historical data in one shot, then return to the incremental cadence.
Phase 3: Stable operation. Change the cron to a 2-minute polling cycle. The source pulls and the target pushes run in a staggered fashion. Meanwhile, enable phased processing of headers and line items—first get the headers running, then layer in the line items, to reduce the initial failure rate.

Lessons Learned

Here are some of the pitfalls we have hit together with customers:

Warehouse codes concatenated directly without mapping. A typical mistake is to put BIP's warehouse code into from_warehouse_no as-is, which results in the Wangdiantong side being unable to find the warehouse and the order being silently discarded. The safe approach is to maintain a two-sided warehouse code mapping centrally in Qeasy, so changes apply across the entire pipeline from one place.
outer_no not actually preventing duplicates. If a document is repaired manually in the middle, the same code may be pushed multiple times, causing duplicate transfer orders on the Wangdiantong side. We recommend adding an idCheck layer at the platform level: pull only once on the source side and deduplicate by outer_no on the target side.
Transfer type enums do not line up. BIP's business types and Wangdiantong's transfer_type are not 1:1. Without mapping, the value will either fall through or be mismatched.
Headers and line items handled in one batch. Mixing header and line item changes in a single sync makes it hard to locate the failure level. Phased and split processing for headers and line items improves troubleshooting efficiency significantly.
Cron contention. When the source and target fire at the same second, they can saturate the partner's interface under heavy data volume. Staggering by 30 seconds to 1 minute is empirically more stable.

Applicable and Inapplicable Scenarios

Applicable: Retail or distribution companies where BIP serves as the ERP for primary approval and Wangdiantong serves as the store or e-commerce warehouse execution system, and where transfer applications need to automatically land in Wangdiantong as executable orders, with real-time requirements at the minute level. Inapplicable: Scenarios that require strict real-time second-level linkage (these should use message queues rather than polling). It is also not suitable for complex transfer business flows that are entirely different and require two-way collaborative approval; in such cases we recommend splitting the work into multiple strategies modeled separately.