Sales Outbound Order Sync in Practice: An End-to-End Implementation from E-Commerce Mid-Platform to ERP
What This Strategy Solves
A retail enterprise generates hundreds or thousands of sales outbound orders per day on its e-commerce mid-platform, but finance and supply chain can only rely on data inside the ERP for reconciliation and shipment confirmation. Manual export is inefficient and often creates a time gap in which the mid-platform has shipped but the ERP has not yet recorded the outbound, leading to overselling or inflated inventory.
We use the Qeasy data integration platform to carry this sync link. The goal is to push the mid-platform's sales outbound orders into the ERP according to established rules, so that order status, shipment time, and batch inventory stay consistent on both sides.
Data Flow and Field Mapping
The overall link is unidirectional: source system (e-commerce mid-platform) → Qeasy middleware layer → target system (ERP). The middleware layer is responsible for code conversion, field cleansing, incremental marking, and exception staging.
| Business Meaning | Source Field (Mid-Platform) | Middleware Handling | Target Field (ERP) |
|---|---|---|---|
| Document number | io_no | Pass through | Sales outbound order no. |
| Warehouse code | wh_code | Code mapping lookup | Warehouse archive code |
| Store code | shop_id | Code mapping lookup | Department / sales org |
| Item code | sku | Pass through | Material code |
| Outbound quantity | qty | Numeric type conversion | Actual quantity |
| Receiver / address | receiver/address | Field concatenation | Customer and address |
| Document time | io_time | Timezone & format normalization | Business date |
| Tracking number | express_no | Non-empty validation | Logistics info |
| Remarks | remark | Length truncation | Header remarks |
Centralized code mapping is a common response pattern among Qeasy customers: master data for items, warehouses, and stores is maintained in the platform's independent "mapping table," reusable by any subsequent strategy, avoiding scattered logic inside scripts.
How to Configure on Qeasy
In Qeasy, one strategy corresponds to one "integration flow," mainly composed of four parts:
- Source fetcher: Configure the call method for the e-commerce mid-platform's Qimen interface, use the platform's built-in "Qimen" connector, and set the appkey, secret, and fetch time window. We recommend using "incremental by modification time" as the default mode to avoid full pulls every time.
- Data processing pipeline: Use the platform's built-in script nodes for field mapping, code lookup, type conversion, and header/body splitting. A common pattern among Qeasy customers is to handle header and body in two stages — write the header (document main info) first, then loop through the body (detail lines). If the body fails, only retry the body without affecting the already-successful header.
- Target writer: Choose the ERP's standard interface, set the batch commit count, timeout, and failure retry policy. We recommend enabling "idempotent write" — when a document number already exists, skip it instead of erroring out.
- Exception and alerting: Configure fallback to an "exception table" on failure, and connect to enterprise WeChat or email alerts so the on-duty person can see issues within 5 minutes.
Implementation Steps
At the customer site, we usually progress in three stages:
Stage 1: Align the incremental starting point First confirm with the business side "which time point is the start." A common approach is to take the maximum historical document time as the start time, then fetch incrementally every 5 minutes. This is the easiest place to stumble — if the source has no "modification time" field, you have to fall back to "creation time + document status" with clearly written boundary conditions.
Stage 2: Full reload and reconciliation After running lightly for a while with no omissions, perform a full reload. Full reload is usually scheduled in the early-morning low peak, and Qeasy's scheduler supports "one-time execution within a specified time window." After it runs, use the platform's reconciliation report to check the three dimensions of document number, quantity, and amount; differences go into a manual review queue.
Stage 3: Scheduling frequency and monitoring Once stable, gradually relax the scheduling frequency from 5 minutes to 10–15 minutes, and combine it with a real-time trigger on "order status change" to achieve a dual track of incremental and full. The dual-track approach is common among Qeasy customers: incremental for daily work, plus a light full validation at the start of each month, balancing timeliness and resource use.
Pitfalls and Lessons
- Timezone inconsistency: The mid-platform defaults to UTC+8 timestamps, while the ERP's business date is taken from the server's local time. The safe approach is to explicitly normalize the timezone in the middleware layer instead of relying on either endpoint to convert it.
- Code mapping not centralized: Writing item/warehouse mappings inside scripts means that three months later no one remembers what was changed, and the numbers on both sides start to mismatch. The safe approach is to use Qeasy's "mapping table" component so a single change applies globally.
- Header success / body failure leaves a document hanging: When the middleware writes the header before the body, any line failure stalls the entire document. The typical mistake is having no transaction compensation. We let the platform roll back the header marker on body failure, and on the next run we filter by "incomplete," naturally closing the loop.
- Idempotency not enabled, causing primary key conflicts on re-run: Sync strategies inherently need to be rerun, so the target interface must support "skip if already exists."
- Alert storms: Sending an enterprise WeChat message on every failure leads the on-duty colleague to mute the channel. We later changed it to "send only once per 5 minutes for the same error type," and the experience improved immediately.
Applicable and Non-Applicable Scenarios
Applicable: unidirectional, incremental, structurally stable sales outbound order sync between the e-commerce mid-platform and ERP, with daily volumes from hundreds to tens of thousands. Non-applicable: links requiring bidirectional collaboration (both sides write), strong real-time available inventory checks, and early-stage pilot systems whose source fields change weekly.