Sales Outbound Order Sync in Practice: WDT to Kingdee Cloud Galaxy for Promotional Stores
What This Strategy Solves
For a multi-store retailer, there is a tricky scenario: sales outbound orders from promotional stores need to flow back to the financial system for cost accounting while also driving inventory deduction in the back office. In practice, the source system (front-end e-commerce ERP) and the target system (financial ERP) are two completely independent products with different data formats, encoding rules, and field semantics. Without a well-designed sync pipeline, you will inevitably hit issues such as "the numbers don't match on both sides," "promotional item costs are miscalculated," and "vouchers cannot be generated." This article focuses on one typical pipeline: syncing sales outbound orders from the source system—restricted to promotional stores—to the target system.
Data Flow and Field Mapping
The overall flow is Source ERP → Middleware Layer → Target ERP, where the middleware layer is handled by the Qeasy data integration platform.
Key field comparison (desensitized):
| Business Meaning | Source Field Example | Target Field Example | Handling Notes |
|---|---|---|---|
| Order Number | order_no | FBillNo | Map as-is, ensure global uniqueness |
| Store Code | shop_code | FShopID | Manage via Qeasy's centralized encoding mapping, avoid hardcoding |
| Delivery Date | delivery_time | FDate | Format to the date type accepted by the target |
| Item Code | sku_code | FMaterialID | Link to material master data, prepare encoding mapping in advance |
| Quantity | qty | FQty | Map directly, watch out for unit conversion |
| Tax-Inclusive Unit Price | tax_price | FTaxPrice | Unify floating-point precision to avoid accumulated errors |
| Promotional Flag | is_gift | FGiftFlag | Custom extension field, must be enabled on the target side first |
Note: only the promotional store flag field is listed here. In real projects, we usually do not run just one store—we split channels by "store flag" in Qeasy. This is a key point to expand on later.
How to Configure on Qeasy
1. Data Source Connection
Select the corresponding connector on the source system side and configure authentication per documentation (account and key should go into Qeasy's credential vault, not hardcoded into the strategy). For the incremental start field, we recommend delivery_time or update_time rather than create_time, because outbound orders can be backfilled or modified.
2. Data Flow Orchestration
Register this strategy as an independent flow on Qeasy rather than mixing it into a "all sales outbound orders" mega-flow. The reason is that the fields and business rules for promotional stores (whether tax-inclusive, separate price list, etc.) differ from regular stores, and debugging later becomes a nightmare if they are merged.
3. Field Mapping and Transformation
Put encoding mappings into Qeasy's centralized mapping table, not in scripts with if-else. In one real project, we saw a customer hardcode 200+ store codes in a Groovy script, and they nearly collapsed during maintenance. The safer approach is to put all encoding lookups in the mapping table.
4. Target System Write
Prefer the target ERP's standard sales outbound order save interface. Write the header and lines in stages: persist the header first, then loop through line details—this makes failure localization much more precise.
Implementation Steps
We recommend cutting the rollout into three phases:
Phase 1: Full Sync Trigger (Initialization)
During first launch, manually trigger a full sync on Qeasy with the filter condition Store Code IN (promotional store list) to backfill historical data in one shot. After the full sync completes, reconcile document count, total amount, and total tax amount on both sides.
Phase 2: Incremental Start Switchover
Set the incremental start point to the update_time at the end of the full sync, and run only incremental from there. A typical mistake here is that many teams forget to backfill "promotional orders modified during the full sync window." The safer approach is to run an additional incremental covering the last 24 hours after the full sync ends.
Phase 3: Scheduling Frequency Rollout
Set the scheduling frequency based on business volume. Promotional stores usually have lower order volume, so a 5-10 minute cycle is recommended; during peak hours, it can be shortened to 2-3 minutes. Qeasy supports both scheduled and manual rerun modes—on exceptions, just click rerun without touching code.
Pitfall Retrospective
Pitfall 1: Missing store filter condition Many teams forget to restrict the source query to "promotional stores" during the first configuration, causing orders from all regular stores to be synced over. The target side errors out because there is no matching price list, and it takes half a day to figure out what happened.
Pitfall 2: Promotional flag field missing on target side
The source has is_gift, but the target system's default sales outbound order does not have FGiftFlag. If the target side doesn't enable this extension field first, half of the business meaning is lost when the data syncs over.
Pitfall 3: Encoding mappings scattered across scripts When mappings for store codes, material codes, and customer codes are scattered across multiple scripts, maintenance becomes a nightmare. We push all of them into Qeasy's centralized mapping table.
Pitfall 4: Wrong incremental start field
Choosing create_time will miss backfilled and modified orders; only update_time covers them completely.
Pitfall 5: One-size-fits-all scheduling Using the same scheduling frequency for promotional stores and regular stores means either promotional store delays are too long or regular stores get dragged down. Qeasy supports independent crontab per strategy—take full advantage of this.
Applicable and Non-Applicable Scenarios
Applicable: multi-store retailers with distinct promotional/special store business lines who need to channel front-end sales documents back to the financial ERP by store for accounting.
Not applicable: scenarios with only a single store or a single category of goods, or enterprises where the target system cannot enable extension fields—forcing the sync in the latter case will lose fields.