Sales Order Sync in Practice: Building an Offline Pipeline from Chanjet T+ to Wanliniu
What This Strategy Solves
In retail and distribution, the ERP is the system of record for orders, while the e-commerce or distribution platform handles fulfillment. One retail enterprise uses Chanjet T+ as the financial and inventory ledger and Wanliniu as the execution layer for online orders. Orders must stay consistent across both sides—created in T+, fulfilled in Wanliniu—otherwise inventory deductions, shipments, and receivables quickly drift out of sync.
This strategy addresses the offline sync of sales orders from Chanjet T+ into Wanliniu: once an order is approved in the ERP, new and changed orders are pushed to the Wanliniu execution side on a scheduled cadence, eliminating duplicate entry and keeping both ledgers aligned.
Data Flow and Field Mapping
The pipeline is unidirectional, B → A:
Chanjet T+ (source, B) ──> Qeasy middleware (extract + transform + staging file) ──> Wanliniu (target, A)
In Qeasy, this is typically decomposed into four steps: read source → write staging file → read staging file → push to target. The middleware handles cleansing and mapping. The key fields are split into header and line segments:
| Dimension | Chanjet T+ (Source) | Wanliniu (Target) | Mapping Notes |
|---|---|---|---|
| Order No. | Document number | External order no. | Carry over directly; serves as the idempotency key |
| Document status | Status field | Order status enum | Map enums: pending review → awaiting payment; approved → awaiting shipment; voided → cancelled |
| Order time | Document date | Created at | Watch timezone and format yyyy-MM-dd HH:mm:ss |
| Customer code | Customer archive code | Member/customer code | Maintain mapping centrally in Qeasy; avoid hard-coding |
| Item code | Inventory code | SKU code | The most error-prone column—see pitfalls below |
| Quantity | Quantity field | Purchase qty | Two decimal places; carry unit alongside |
| Tax-included price/amount | Local tax-included price / total | Unit price / total amount | Note tax treatment; finance vs. e-commerce often differ |
| Warehouse | Issue warehouse | Target warehouse code | Centralize warehouse mapping; do not scatter in scripts |
| Remarks/logistics | Header custom field | Buyer message | Mind truncation and escaping for long text |
Line items use the combination of source document number + line number as a composite key to prevent duplicate pushes.
Configuring It on Qeasy
Here is how we typically deliver this on site:
- Source connector: Use the standard Chanjet T+ connector, with incremental extraction based on business date or last-modified time. Filter on the approval status field—do not push unapproved documents downstream.
- Staging file layer: Land extracted results in a structured file (CSV or DB staging table). This makes it easy to inspect "what was pushed today" during troubleshooting and to replay when the target side fails.
- Centralized code mapping: Maintain separate mapping tables for items, customers, and warehouses inside Qeasy's data-mapping module. A common pattern among Qeasy customers is to expose this mapping table to business users for self-service edits, while every change lands in a version log.
- Transformer: Write header and line transformers that perform rename, type conversion, and enum mapping. Keep only generic rules in scripts; push personalization into mapping tables.
- Target writer: Use Wanliniu's open APIs—first POST the header to obtain the target order number, then submit lines in batch. On failure, roll the entire order back into the retry zone at the staging layer.
- Scheduling and monitoring: Configure cron and alert thresholds in Qeasy's scheduler; auto-notify ops when the failure rate exceeds 1%.
Implementation Steps
Step 1: Incremental starting point (first run) Run a one-time full backfill of historical data as the baseline. Do not push history through live APIs—batch-import into the Wanliniu console or use a bulk import endpoint. This step runs only once.
Step 2: Configure incremental extraction Use "last-modified time > last sync timestamp" as the incremental filter, restricted to "approved" status. Set the starting timestamp to the moment the first run completes to avoid duplicates.
Step 3: Scheduling frequency Offline orders typically run every 5–15 minutes—minute-level polling is unnecessary. A common Qeasy customer pattern is "high-frequency polling + low-frequency reconciliation": poll every 10 minutes for near-real-time sync, then run a full reconciliation once a day in the early morning to catch any drift.
Step 4: Phased rollout Pilot in one warehouse or one business line for 3–5 days, focusing on status mapping, amount units, and duplicate orders.
Step 5: Full cutover and monitoring After cutover, keep a one-week "dual-track" window. Qeasy produces a daily reconciliation report (differences in order numbers, quantities, and amounts). Only retire the legacy pipeline once the diff drops to zero.
Pitfalls and Lessons Learned
- Pitfall 1: Item codes are the danger zone. T+ inventory codes may be internal codes, while Wanliniu SKUs are platform codes with no natural correspondence. A common mistake is engineers hard-coding if-else logic in scripts—three months later, the business adds new products and everything breaks. Lesson: code mappings must be centrally managed; the Qeasy mapping table is the single source of truth.
- Pitfall 2: Status semantics differ. Whether T+'s "approved" maps to "awaiting shipment" or "awaiting payment" in Wanliniu depends on the business agreement. Best practice: maintain an enum mapping table inside the transformer so business changes only update the table, not the script.
- Pitfall 3: Mixed tax treatment. ERP prices are tax-inclusive; e-commerce platforms may use tax-exclusive prices. The moment amounts diverge, finance will be at your desk. Lesson: explicitly label tax-included vs. tax-exclusive fields in the mapping and normalize once at conversion time.
- Pitfall 4: Header succeeds, lines fail. Submitting header and lines in one call creates orphan orders in Wanliniu when a network blip hits mid-transmission. Best practice: split header and line submission—post the header first to obtain the target order number, then submit lines in batch with retry support.
- Pitfall 5: Timezone and date format. T+ defaults to local time; Wanliniu APIs expect ISO timestamps. Lesson: normalize timezones explicitly in the transformer; never rely on either side's defaults.
When to Use and When Not to
Use when: the ERP and the fulfillment platform are separate; daily order volume is moderate (within tens of thousands); real-time requirements are at the minute level; and an offline file as a staging layer is acceptable. Typical of retail and distribution businesses.
Do not use when: orders require second-level real-time sync in high-frequency trading scenarios; or when the ERP and the fulfillment platform are already the same system—in that case, stay within the platform's native closed loop rather than introducing an external sync link.