Syncing Outsourced Stock In/Out Orders from Wangdiantong to MySQL: A Practical Guide on Qeasy

What This Strategy Solves

In a retail company's outsourced processing scenario, the in/out stock orders at the consignor warehouse are the single source of truth for financial reconciliation, inventory accounting, and supplier settlement. These orders live in Wangdiantong, but the downstream MySQL data warehouse has no access to them. As a result, monthly reconciliation drifts, and operations spend half a day each week manually filling the gaps. The goal of this strategy is to use the Qeasy data integration platform to pull outsourced stock in/out orders from Wangdiantong into MySQL on an incremental basis, so that data lands as soon as it is created and reconciliation requires no manual work.

Data Flow and Field Mapping

The overall flow is Wangdiantong (source) → Qeasy integration platform (middle layer) → MySQL (target). The source side is a query API on Wangdiantong's enterprise gateway; the target side is an executable SQL; the middle layer handles field cleansing, code mapping, and child-table expansion.

Business Meaning	Source (Wangdiantong)	Middle Layer (Qeasy)	Target (MySQL)
Order status	status (int: 10–80)	Pass-through	`status`
In/out category	order_type (1 out / 2 in)	Pass-through	`order_type`
Warehouse code	warehouse_no	Direct mapping	`warehouse_no`
External order no. / API external no.	outer_no / api_outer_no	Direct mapping	`outer_no` / `api_outer_no`
Master order no.	order_no	Direct mapping	`order_no`
Receiver address fields	receiver_*	Push down as a block	receiver_*
1:N item details	details_list (nested array)	Expanded to child table	`jry_wdt_stock_outside_wms_details_list`
Batch and location	batch_no / position_no	Direct mapping	Same-name fields

The master table and the child table are joined on order_id. The target side uses REPLACE INTO for idempotent writes, preventing duplicate accumulation.

How to Configure on Qeasy

Step 1: Connect the source platform "Wangdiantong · Enterprise Gateway." Select the API wdt.vip.stock.outside.wms.query, method POST, with warehouse_no, status, order_type, and outer_no as input parameters. Bind the order-number field to order_no and the primary key to order_id.

Step 2: Connect the target platform MySQL. Map the JSON returned by the source into two SQL statements: the main statement writes the master table; the extended statement writes details_list. Use named placeholders (:order_id, :order_no, etc.). The master and child tables share :order_id for the join.

Step 3: Apply code mapping and constant handling in Qeasy. Strong foreign keys such as warehouse code and product code are maintained centrally in the mapping layer. Status codes and in/out category are passed through as-is and left to downstream reporting systems to interpret.

Step 4: Attach the whole strategy to the scheduler. Use */11 * * * * for the source side and 3-59/11 * * * * for the target side, offset by 3 minutes, so the target does not read an empty result immediately after the source finishes.

Implementation Steps

We typically roll this out in three phases:

Incremental starting point: First run a full pull in Qeasy and confirm the master + child row counts match the source. Then narrow the status input to states after "60 pending out / 65 pending in" as the incremental starting point, avoiding the backflow of stale historical data.
Full re-pull trigger: Around reconciliation day, temporarily clear the inputs to trigger a full re-pull and reconcile differences; restore incremental mode after reconciliation.
Scheduling frequency: Run every 11 minutes day-to-day, with the source offset by 3 minutes. On reconciliation day, temporarily tighten to every 5 minutes, then restore the original cadence after reconciliation.

A lesson from the field: trigger full re-pulls in Qeasy by re-executing the write once; do not change source inputs such as order_type, otherwise cancelled orders will also be pulled back.

Pitfalls and Lessons

No offset between source and target: The target reads mid-snapshot when it runs right after the source finishes. Setting the two crons 3 minutes apart in Qeasy eliminates this.
1:N child table not bound: If details_list from the source is not explicitly bound to extend_params_2, the child table ends up empty. Always hard-bind extend_params_2 = details_list on the target side.
REPLACE INTO changed to INSERT INTO: Some clients change it to INSERT INTO to keep historical rows visible, which causes the whole batch to fail on primary-key conflicts. For idempotent scenarios, stick with REPLACE INTO—this is the recommended Qeasy standard.
Translating status codes: Translating Wangdiantong's status = 80 completed into the downstream's "settled" creates inconsistent reconciliation semantics and burns a full day on debugging. Pass raw values through and let the downstream interpret.
Cancelled orders dragged into full re-pulls: When the status input is left empty, the source returns orders with status = 10 cancelled. We later added a filter node in Qeasy that only lets orders with status >= 20 flow downstream.

When to Use and When Not to Use

Use when: Outsourced warehouse in/out volume is high, order status must land in the data warehouse in near real time for reconciliation and reporting, the source is Wangdiantong, the target is a relational database such as MySQL, and an 11-minute latency is acceptable.

Do not use when: Sub-second real-time inventory is required (use a message queue instead), or the source order structure changes frequently and field names are unstable (freeze the schema in Qeasy first).