Sales Order Sync in Practice: Deep Dive into a Single Strategy from Changjietong T+ to Wanliniu

What This Strategy Solves (Scenario & Value)

In the supply chain integration of a retail enterprise, the ERP side is the authoritative source for order settlement and inventory deduction, while the e-commerce side is the basis for fulfillment and shipping. If the two sides drift apart for the same sales order, the warehouse does not know which side to ship from, and customer service does not know which side to reconcile payments against.

This strategy is designed to address exactly that: taking Changjietong T+ as the authoritative source, extracting sales orders according to the business definition, processing them in the Qeasy Data Integration Platform as a middle layer, and then writing them into Wanliniu. In essence, one sync aligns order ownership, codes, and status. In real projects, we have seen that without this alignment, after three months the two sides no longer match on order counts, and the return/exchange chain turns into chaos.

Data Flow and Field Mapping (Source → Middle Layer → Target)

The data flow has three segments: Changjietong T+ (source) → Qeasy Data Integration Platform (middle layer) → Wanliniu (target). The source side is a query, the middle layer performs mapping and cleansing, and the target side performs the write.

The table below lists only the fields that are easy to get wrong:

Note: on the source side, selectFields specifies the returned field set, pageIndex / pageSize control pagination, and paramDic_1 is used for filter conditions (e.g., by date, by customer). The "write empty operation" on the target side is a middle-layer anchor, and the actual write is completed in a follow-up strategy. This is the common Qeasy pattern of "phased processing".

How to Configure on Qeasy

On the Qeasy Data Integration Platform, the source operation of this strategy is a WebAPI query, and the target operation is an empty write anchor. There are four configuration points to pay attention to:

1. Select WebAPI for the source interface, method = POST, and configure /tplus/api/v2/SaleOrderOpenApi/FindVoucherList as the API path; effect = QUERY indicates this is a pull action.
2. Three-part request body: selectFields lists the fields to return (commonly VoucherCode, ID, etc.); pageIndex starts from 0; pageSize is set according to the source system's rate limit, and is usually safe within 100.
3. Fill number with Code, fill id with ID, and set idCheck = true — this tells the platform to use the voucher code as the idempotency key and the voucher ID for uniqueness validation.
4. Anchor the target side with an "empty write operation" first, landing the data in the middle layer; the actual write into Wanliniu is done in the next strategy. This is the typical "header and body phased" approach — solve one layer at a time, and problems are easier to locate.

Code mapping must be managed centrally rather than scattered across every strategy. The most common failure we have seen at customer sites is that customer codes are hardcoded in strategy A and rewritten in strategy B, so when the ERP changes the customer master, neither side stays in sync and all orders go wrong.

Implementation Steps

Proceed in three phases to stay safe:

Phase 1: Incremental starting point. Anchor last_sync_time to a clear point in time, such as 00:00 of the current day. Run a full sync the first time, and immediately update last_sync_time to the maximum value of this run; subsequent increments advance from this value.

Phase 2: Full trigger. In the sandbox environment, set pageSize to 5 (just like the default value in the source material), manually trigger a full pull, and verify the returned structure and fields; only after confirmation, switch pageSize to the production value.

Phase 3: Scheduling frequency. Set crontab to 0 23 * * * to run once a day at 23:00. The reason is: during daytime business peaks the ERP is under heavy load, so it is better to run at night; at 23:00, the vast majority of orders have been reviewed and are fully landed. If the customer demands more real-time behavior, it can be tightened to every 30 minutes, but watch the source system's rate-limit threshold.

The dual-track of incremental and full sync is a common pattern among Qeasy customers: incremental by default, and a full reconciliation once a week in the early hours of Sunday morning to prevent missing orders.

Pitfall Review

1. Typical mistake: going full sync on the first run. The source system returns hundreds of thousands of records at once, the middle layer gets stuck, and all subsequent strategies queue up. The safe approach is to validate the structure with a small pageSize first, then gradually enlarge it.

2. Typical mistake: leaving idCheck off. Without idempotency validation, any source-side retry causes duplicate landings, and duplicate orders appear on the target side. Always configure idCheck = true.

3. Typical mistake: writing the target system directly from the source. Source data is not landed in the middle layer, so when something goes wrong, a re-check has to start from scratch by pulling again. Landing once in the middle layer makes troubleshooting ten times more efficient.

4. Typical mistake: code mapping scattered everywhere. Customer codes, inventory codes, warehouse codes — each strategy defines its own. When the customer's ERP is adjusted, every strategy has to be modified. Central management is the only sustainable approach.

5. Typical mistake: ignoring pagination. pageIndex is not incremented, so only the first page of data is fetched. It looks like a successful sync, but everything after that is lost. Always confirm in configuration that the pagination logic is actually active.

Applicable and Non-Applicable Scenarios

Applicable: scenarios where ERP and e-commerce/OMS need order alignment, both sides expose open APIs, and a daily batch is sufficient for the business rhythm.

Not applicable: scenarios that require minute-level real-time sync; scenarios where the source system does not expose a WebAPI and only allows direct database access; scenarios where order structures differ drastically and require heavy business-rule rewriting in the middle layer — the latter should be split into multiple strategies rather than crammed into one.