Syncing Sales Outbound Orders from Wandiantong to Kingdee Cloud Cosmos: A Practical Breakdown of One Strategy
What This Strategy Solves (Scenario and Value)
In a real project with a retail company, the e-commerce fulfillment system (Wandiantong) generates a large number of sales outbound orders every day, and these documents need to flow into the ERP (Kingdee Cloud Cosmos) for cost accounting, receivables confirmation, and general ledger posting. It may look like simple "document搬运," but the fields involved in an outbound order are far more complex than expected: warehouse, owner, inventory organization, exchange rate, batch, serial number, line-level fees, and order-level discounts. Any mismatch in interpretation will blow up during the month-end reconciliation.
The core value of this strategy is to bridge "real outbound from fulfillment" with "accounting perspective from finance" through a traceable and replayable synchronization link. On the customer site, we used the Qeasy data integration platform to build this link, with the goal: configure once, run stably long-term, and reconcile cleanly at month-end.
Data Flow and Field Mapping (Source → Middle Layer → Target)
Wandiantong serves as the outbound order generator, Kingdee Cloud Cosmos as the accounting receiver, and the data passes through Qeasy's integration middleware for field mapping and unit conversion. The key field mapping is as follows:
| Business Meaning | Wandiantong Side | Middle Mapping | Kingdee Cloud Cosmos Side |
|---|---|---|---|
| Document Number | Outbound order number (platform order number) | Pass through as idempotency key | BillNo |
| Document Date | Outbound time | Format to yyyy-MM-dd | Business Date |
| Customer Code | Store code | Converted via customer mapping table | Customer Code |
| Warehouse | Warehouse code | Converted via warehouse mapping table | Inventory Org + Warehouse |
| Product Code | Merchant code/SKU | Converted via product mapping table | Material Code |
| Quantity | Outbound quantity | Unit conversion | Base unit quantity |
| Unit Price/Amount | Actual transaction price | Tax-inclusive/exclusive converted per target | Sales price, total price-tax |
| Remarks | Buyer message/system remarks | Concatenated | Remarks |
Centralized management of code mapping is a clear advantage of middleware like Qeasy over raw scripts—product, customer, and warehouse mapping tables are maintained centrally in the mapping center, taking effect everywhere with a single change, avoiding scattered maintenance across multiple sync tasks.
How to Configure on Qeasy
On the Qeasy data integration platform, this strategy is implemented as an "integration solution → sync strategy." Typical configuration points are as follows:
- Source System Access: Select the Wandiantong Enterprise Edition adapter and pull approved sales outbound orders via API.
- Target System Write: Select the Kingdee Cloud Cosmos adapter and use the standard save interface for sales outbound orders.
- Data Filtering: Filter at the source by "document status = shipped" to avoid pushing draft documents to Kingdee.
- Field Mapping: In the visual mapping canvas, map fields one-to-one per the table above, and write formulas directly in the canvas for computed fields (price-tax total, tax amount).
- Code Mapping: Maintain customer, product, and warehouse mapping tables in the mapping center; reference them in the strategy.
- Idempotency Control: Use "outbound order number" as the business primary key, and enable "update if exists, create if not" write strategy on the target side.
- Logging and Alerting: Enable full-link logging, and write failed rows separately into an "exception table" for easy rerun.
Implementation Steps (Phased Scheduling)
In on-site implementation, we typically break the rhythm into three phases: "incremental starting point → full trigger → steady-state scheduling."
Phase 1: Incremental Starting Point (Cold Start) Choose a business off-peak time point as the starting line, e.g., 2:00 AM. First use a one-time full sync to backfill historical outbound orders before the starting line into Kingdee, ensuring data consistency. This step uses "one-time full trigger" on Qeasy and is turned off after completion.
Phase 2: Full Trigger (Verification) After cold start, use a "scoped full sync" to verify again—for example, rerun the most recent 7 days of data around the starting line to validate code mapping, unit conversion, and tax-inclusive interpretation. A common pitfall here: Wandiantong's "merchant code" and Kingdee's "material code" differ in coding style, requiring line-by-line verification in the mapping table.
Phase 3: Steady-State Scheduling (High-Frequency Incremental) After going live stably, use a "incremental + full dual-track" mode:
- Incremental: Run every 15 or 30 minutes, pulling new or changed outbound orders after the starting line;
- Full: Run a scoped full sync once daily in the early morning (e.g., the previous day) as a fallback for missed increments.
This "high-frequency incremental + full fallback" dual-track is a common pattern among Qeasy customers and can significantly reduce the risk of missed orders.
Pitfall Review
-
Do not scatter code mapping in scripts: A typical mistake is hard-coding product/customer mapping in transformation scripts. Three months later, numbers on both sides don't match, and the mapping version can't be found during troubleshooting. The safe approach is centralized management in the middleware mapping center, with registration for any change.
-
Recommend phased rollout for header and line items: If you push the header plus multiple line item types (fee lines, serial numbers, batches) all at once, problem diagnosis will be very painful. It is recommended to first stabilize the header + main quantity line, then layer in fees, batches, and serial numbers in batches.
-
Idempotency keys must use business primary keys: Do not use platform-provided temporary IDs. Use business composite keys such as "platform order number + store code" to avoid order number collisions between different stores causing wrong overwrites.
-
Time zone and date conventions must be aligned in advance: Wandiantong's outbound time is a time-stamp with time zone, while Kingdee's business date only accepts yyyy-MM-dd. Explicitly perform time zone conversion and truncation in the mapping layer; otherwise, cross-day orders will land on the wrong accounting date.
-
Do not mix failed rows into the main link: Rows that fail to push to Kingdee should not be retried in place causing link blockage. They should fall into a separate "exception table" for manual or compensation task processing.
Applicable and Non-Applicable Scenarios
Applicable: Sales outbound order integration between e-commerce fulfillment systems (Wandiantong, Wangdianjia, etc.) and ERPs (Kingdee, Yonyou, etc.). Daily order volumes from a few hundred to tens of thousands all run smoothly. Suitable for scenarios requiring month-end reconciliation, cost accounting, and receivables confirmation.
Non-applicable: Scenarios requiring second-level real-time inventory occupation, scenarios requiring writing Kingdee vouchers and general ledger, and data requiring strict organization isolation across multi-org and multi-account sets—these should be split into independent strategies rather than mixed with sales outbound synchronization.