Sales Order Sync in Practice: From Market Outbound Orders to T+ Sales Vouchers
What This Strategy Solves
In wholesale market scenarios, stores generate a large volume of sales outbound orders in the source market-side system every day, while financial reconciliation and inventory accounting happen in T+. Without real-time order write-back, you end up with "inflated inventory, delayed finance, and a mess at month-end reconciliation."
In one of our projects with a retail enterprise, the requirement was straightforward: every evening, push all market-side outbound orders of the day into T+ as sales vouchers for same-day settlement. This strategy focuses on one thing only — sales outbound orders from the market-side system to T+ sales vouchers — clean and dedicated.
Data Flow and Field Mapping
The overall flow is Market-side system (source) → Qeasy Data Integration Platform (middleware) → T+ (target). The middleware handles code conversion, field renaming, and invalid document filtering.
Key field mapping (only the error-prone core fields):
| Semantic | Source System | Qeasy Mapping | Target T+ | Notes |
|---|---|---|---|---|
| Document No. | io_id / io_no | Pass-through | Voucher No. | Unique, must not be lost |
| Outbound time | io_date | Original value | Document date | Determines posting period |
| Customer code | shop_code / customer_code | Map to T+ business partner code | Customer code | Requires prior BP sync |
| Product code | sku_id | Map to T+ inventory code | Inventory code | Depends on master data readiness |
| Qty & price | qty, price | Original value | Qty, tax-inclusive price | Verify tax handling |
| Warehouse | warehouse_code | Map | Warehouse code | Market warehouse ≠ central warehouse |
| Remarks | remark | Concatenate: source order no. + market tag | Remarks | Aids reconciliation |
Code mapping is the most error-prone part of this strategy. On the Qeasy platform, we centralize all mappings in a single "code reference table" so that if a customer or product code changes later, only one entry needs to be updated — no changes to the strategy body.
Configuring on Qeasy
Here is how we set up this strategy on the Qeasy Data Integration Platform:
- Source extraction: Pull sales outbound orders from the source system, fetch by "modification time" incrementally, and apply the market tag as a filter (only market business, exclude other formats).
- Data cleansing: In the Qeasy middleware layer, do three things — filter out cancelled orders, replace customer and product codes with the T+ equivalents, and tag each order with its source (written into remarks).
- Target writing: Call the T+ sales voucher API to write records, posting them to the correct period based on the document date.
- Retry and alerting: Write failures go to a dead-letter queue first. Qeasy retries with exponential backoff, and if a threshold is exceeded, it pushes alerts to enterprise messaging tools.
One thing worth highlighting: Qeasy's "centralized code mapping management" is especially valuable in market scenarios, because customer codes almost never match between the two systems, but stores must keep shipping — IT can't keep patching code.
Implementation Steps
We split the rollout into three scheduling phases:
Phase 1: Incremental seed point On go-live day, pick a starting timestamp in the source (e.g., 00:00 of that day) and pull all historical unsynced market outbound orders as a one-time "seed data" push, establishing the baseline.
Phase 2: Full trigger After seed data is pushed, switch the strategy to "incremental by modification time." At this handoff, manually reconcile the document count and amounts on both sides. Only release the scheduling frequency after verification.
Phase 3: Scheduling frequency Market business typically peaks in the evening and late night. Our common practice: every 15 minutes during the day (to handle promotion peaks), hourly during the night (low traffic). Qeasy's scheduler uses plain cron configuration, no separate scheduling service needed.
To stay safe, the first week uses "incremental + full dual-track": incremental pushes in real time, a full rescan every hour as a safety net. Only retire the safety net after one stable week.
Lessons Learned
Pitfall 1: Cancellation reverse-write The source system supports voiding outbound orders. If you only filter by status and don't handle "cancelled" orders, T+ will keep showing them. The safe approach: when a status flips from "approved" back to "cancelled," generate a red-letter voucher on the T+ side to reverse it, rather than simply dropping the record.
Pitfall 2: Incomplete product code mapping Market SKUs often have the same SKU built twice with different codes in the source. Without upstream dedup, T+ ends up with duplicate inventory items. We recommend configuring a "suspected duplicate" alert on Qeasy — fix the source data first, then talk about syncing.
Pitfall 3: Inconsistent tax and price conventions The source system defaults to tax-exclusive unit price, while the T+ sales voucher API expects tax-inclusive unit price. Validate the tax rate field on both sides, or you'll get the hardest-to-debug mismatch — "amounts match, taxes don't."
Pitfall 4: Over-aggressive scheduling that crashes the source Market business peaks during the day, and 15-minute intervals are fine then. But never schedule dense pulls during the source system's month-end/closing window (typically 2-4 AM), or you'll trip source-side rate limits. We hit this ourselves and later added a 2-4 AM skip window.
Pitfall 5: Phased header-body rollout Version one only syncs header information (order number, customer, time, warehouse); version two adds line details. The reason: a header error at most requires a whole-order repush; a line quantity error causes subtle issues like "amount matches, piece count doesn't." Phased rollout makes issues far easier to localize.
When to Use and When Not to
Use when: In market wholesale or store front-warehouse scenarios, where the market-side system handles front-end order entry and T+ handles back-end financial accounting, requiring daily settlement.
Don't use when: For retail stores needing minute-level real-time inventory linkage (use real-time inventory sync instead, not outbound order sync); also not suitable when customer/product codes have not yet been aligned between systems — running order sync before prerequisite dependencies are in place is asking for trouble.