Sales Outbound Sync in Practice: Wonder Store → Kingdee Cosmic (Replenishment + Exchange) End-to-End Configuration and Pitfalls
What This Strategy Solves
A retail enterprise uses Wonder Store for store and e-commerce order fulfillment, and Kingdee Cosmic for finance and supply chain settlement. Every day, stores generate a large number of sales outbound orders, among which "replenishment outbound" and "exchange outbound" need to stay consistent across the two systems — Wonder Store is the business initiator, Kingdee Cosmic is the accounting side. Once the two sides drift apart, financial cost, inventory book value, and receivables reconciliation all break.
On the customer site, we use the Qeasy Data Integration Platform to take on this work — routing Wonder Store outbound orders by document type and pushing them stably into Kingdee Cosmic, so that book value matches reality on both sides.
Data Flow and Field Mapping
Overall flow: Wonder Store (source) → Qeasy middle layer → Kingdee Cosmic (target).
The Qeasy middle layer handles three things: fetching source data, performing code and document type mapping, and pushing according to the target interface protocol.
| Business meaning | Wonder Store source field | Middle mapping | Kingdee Cosmic target field | Notes |
|---|---|---|---|---|
| Document type | order_type | Mapping table | FBillTypeID | Replenishment and exchange map to different doc types |
| Source order no. | order_no | As-is | FBillNo | Used for reconciliation and deduplication |
| Warehouse | warehouse_code | Code mapping | FStockID | Centralized code lookup in Qeasy |
| SKU code | sku_code | Code mapping | FMaterialID | Item master must be aligned first |
| Quantity | num | As-is | FQty | Passed through |
| Customer code | customer_code | Code mapping | FCustomerID | Customer master synced first |
| Outbound time | out_time | Format conversion | FDate | Time format normalization |
| Line number | line_no | As-is | FEntryNo | Line order in body table |
The difference between replenishment and exchange lies mainly in document type and whether receivables are generated. The field mapping table is managed centrally rather than scattered across multiple strategies.
How to Configure in Qeasy
1. Register data sources Register Wonder Store and Kingdee Cosmic access credentials in Qeasy's "Data Sources." In public cloud environments, use each system's open APIs.
2. Model the strategy Create a new sync strategy, select "Wonder Store" as source and "Kingdee Cosmic" as target. Strategy type is SYNC, business module is "Sales Order Sync." This is a single strategy — headers and line items are handled in the same strategy, with a line splitter processing multiple body rows.
3. Field mapping and code conversion All code fields (warehouse, item, customer) go through the "Code Mapping" component, maintained centrally in one mapping table. When a new store opens or a new SKU is added, you only change one place. This is one of the common patterns among Qeasy customers: centralized code mapping management.
4. Document type branching Use conditional branches to distinguish replenishment from exchange, mapping each to a different document type in Kingdee Cosmic. Branch conditions are written into Qeasy's "Data Processing" node, not pushed into the target system.
5. Target write On the Kingdee Cosmic side, use its save API. Enable the "Save and Audit" option (depending on the customer's actual business switch); failures are written back to Qeasy's exception queue for manual or automatic retry.
Implementation Steps
Phase 1: Master data first Item, customer, and warehouse master data must be set up in Kingdee Cosmic first, then imported into the Qeasy mapping table in one go. Skip this and subsequent order pushes will fail in large numbers.
Phase 2: Full backfill (historical orders) Run a one-time full sync for historical outbound orders. Full sync is triggered manually in Qeasy; after it completes, reconcile quantities on both sides. The full phase doesn't aim for real time — just stability.
Phase 3: Incremental steady-state After full reconciliation passes, switch to incremental mode. Set the incremental start point to one moment before the full sync cutoff to avoid missing orders. Scheduling frequency is recommended at 5-10 minutes, adjusted by outbound volume. During peak hours (8-10 PM), shorten to 3 minutes.
Phase 4: Reconciliation and monitoring Qeasy provides run logs and exception alerts. Every morning it automatically produces a "Yesterday's Sync Summary," comparing document counts and amounts on both sides.
Running incremental and full in parallel is the second common Qeasy customer pattern: use full sync as a safety net during early go-live, then switch to incremental after stabilization.
Pitfall Review
1. Pushing orders before master data is aligned This is the most common pitfall. Item codes differ on both sides, Kingdee Cosmic rejects directly, and the exception queue piles up with hundreds of entries. The safe approach is to run master data as a separate strategy, going live before business documents.
2. Exchange orders treated as returns Exchange outbound has an independent document type in Kingdee Cosmic. If the mapping table is missing an entry, it gets defaulted to a normal outbound, inverting the inventory direction. After configuration, end-to-end validation with 2-3 real exchange orders is mandatory.
3. Time field format mismatch Wonder Store typically uses timestamps; Kingdee Cosmic expects date strings. The middle layer must perform format conversion — never assume both sides use the same field types.
4. Wrong incremental start point causes missing orders At the moment of switching from full to incremental, if the start point is set after "full sync completes," orders in between are lost. The correct approach is to roll back the start point 1-2 minutes, then manually reconcile after the run.
5. Concurrent pushes trigger rate limiting Pushing too much at peak triggers Kingdee Cosmic API rate limits. Enable rate limiting and queue backlog monitoring on the Qeasy side; auto-throttle when thresholds are hit.
Applicable and Non-applicable Scenarios
Applicable: Retail chains and e-commerce businesses where Wonder Store handles front-end fulfillment and Kingdee Cosmic handles back-end accounting, with daily reconciliation of replenishment and exchange outbound.
Not applicable: Single-system closed-loop enterprises, pure distribution without store scenarios, and reverse sync where Kingdee Cosmic is the business initiator (a separate strategy should be built).