Sales Outbound Sync in Practice: From LingXing ERP Shipping Settlement Report to Kingdee Cloud Cosmos
What This Strategy Solves
A common scenario for cross-border retail teams: shipments originate in LingXing ERP, while financial bookkeeping and inventory deduction happen in Kingdee Cloud Cosmos. Shipping settlement reports flow into sales outbound orders every day. It looks like one short step, but without proper code mapping design, the numbers on both sides drift apart within three months.
We use the Qeasy (QingyiCloud Data Integration Platform) to host this strategy. The goal is plain: convert LingXing ERP shipping settlement reports into Kingdee Cloud Cosmos sales outbound orders under unified rules, achieving daily reconciliation, full traceability, and replay capability.
Data Flow and Field Mapping
Data flow: LingXing ERP (shipping settlement report) → Qeasy integration platform (intermediate layer) → Kingdee Cloud Cosmos (sales outbound order).
The intermediate layer does not pass source data through directly. It performs three tasks: business filtering, field mapping aligned to the target system, and filling in missing fields.
Key field mapping table (frequently used fields only):
| Business meaning | LingXing ERP (shipping settlement report) | Intermediate layer | Kingdee Cloud Cosmos (sales outbound order) |
|---|---|---|---|
| Document number | Shipping report ID | Pass through, add prefix if needed to prevent duplicates | Document number |
| Store | Platform store code | Lookup via store mapping table to Kingdee organization | Sales organization |
| Product code | Platform SKU / MSKU | Centralized code mapping table | Material code |
| Warehouse | Ship-from warehouse | Pass through | Warehouse |
| Quantity | Shipped quantity | Two decimal places | Actual shipped quantity |
| Price / amount | Settlement amount | Adjust precision per target system | Price including tax |
| Document date | Ship date | Pass through, format as needed | Business date |
Important note: code mappings for stores, SKUs, and organizations should not be scattered across individual strategies. We centralize the mapping table in Qeasy as a shared master data table so every strategy that needs code conversion references the same source. A change made once takes effect across the chain. This is one of the common patterns used by Qeasy customers: centralized code mapping management.
Configuring in Qeasy
Configuring a strategy in Qeasy involves four core blocks: source data extraction, intermediate-layer cleansing, target system write, and scheduling plus alerting.
Source extraction. The LingXing ERP data interface pulls shipping settlement reports incrementally by ship date range. When first connecting, always confirm the "shipped" status enum values returned by the interface to avoid pulling drafts or cancelled records.
Intermediate cleansing. Qeasy's field mapping layer supports expressions, table lookups, and JavaScript scripts. Our usual approach: expressions for precision and date formatting, table lookups for code mapping, and JavaScript as a fallback for branch logic (such as splitting one shipping report into multiple outbound lines).
Target write. When writing into Kingdee Cloud Cosmos sales outbound orders, call the save endpoint first, then the submit/approve endpoint. These two steps are orchestrated in Qeasy's "aggregated write" node to avoid leaving half-finished documents behind.
Scheduling and alerting. Qeasy alerting channels support WeCom, DingTalk, and email. Use the platform's exponential backoff for retry. Document-level errors must include the source document number, otherwise troubleshooting becomes a painful exercise.
Implementation Steps
We recommend a three-phase rollout. Phased scheduling is another common pattern among Qeasy customers.
Phase 1: Incremental start. Backfill the most recent 7 days of shipped data to validate mapping and the target system's save path. Trigger this phase manually in Qeasy without entering the scheduler.
Phase 2: Full-volume trigger. Backfill historical data sliced by month, with each slice as an independent task for easier rollback. Qeasy's batch execution node supports concurrency configuration. Lower the concurrency according to the target system's write QPS to avoid upstream rate limits.
Phase 3: Schedule launch. Daily operation runs in incremental mode, pulling every 15–30 minutes by ship date. A nightly reconciliation check writes results to Qeasy's log table for audit purposes.
Only after all three phases run smoothly should alerting thresholds, failure retry, and SOP for manual intervention on abnormal documents be locked in. Then the operation is truly operable.
Pitfall Review
-
Store and organization mapping scattered everywhere. One enterprise maintained three store mapping tables across different strategies. One was updated, the other two were missed. The safe approach is to use a shared public mapping table in Qeasy as the single source of truth, referenced by all strategies.
-
Writing header and body at once. Sales outbound orders involve a document header and detail lines. Sending them in one shot can leave half-successful records when the network wobbles. Qeasy supports staged persistence for header and body, which is a high-frequency pattern in customer deployments.
-
Timezone and date boundary. LingXing ERP uses the business timezone for ship date, while Kingdee Cloud Cosmos saves according to server timezone. Cross-day records easily slip through. We agreed that all dates are converted to 00:00:00 of the business timezone in the Qeasy intermediate layer before being passed to the target.
-
Wrong incremental start point. Using the platform default "last modified time" for increment leads to duplicate pushes when the source backfills or edits records. The safer approach is to determine the incremental cursor by document state transition timing, not by timestamp alone.
-
Reconciliation by total amount only. Comparing only totals hides line-level misalignment. We run multi-dimensional reconciliation in Qeasy: document number, SKU, warehouse, batch. Differences are written to an exception table for manual handling.
-
Permissions and login state. If the integration account for Kingdee Cloud Cosmos has overly broad permissions, sensitive documents may be modified by accident. If too narrow, some fields cannot be written. Integration account permissions should follow the principle of least privilege at the strategy level. This step is often overlooked.
Applicable and Non-applicable Scenarios
Applicable: cross-border retail enterprises where LingXing ERP is the business front-end for shipping and Kingdee Cloud Cosmos is the back-end for accounting and inventory deduction; daily order volume within tens of thousands; need for traceable, replayable sync chains.
Non-applicable: scenarios requiring second-level real-time inventory visibility. This strategy runs at minute-level scheduling. Scenarios requiring complex approval workflows on the Kingdee side: submit and approve nodes will slow the overall pace. A separate strategy is recommended for that case.