Sales Order Sync in Practice: Integrating Sales Delivery Orders from Jikeyun to Kingdee Cloud Cosmos
What This Strategy Solves
In one of our retail-and-manufacturing client engagements, the business team faced a recurring pain point: front-end channels kept placing orders, and the back-end ERP had to quickly and accurately turn those orders into shippable sales delivery orders. This cross-system step looks simple, but it breaks easily—wrong document type, mismatched tax rates, or batch-number fields failing strict validation. Our approach was to isolate this single strategy from the broader integration blueprint and let the Qeasy Data Integration Platform own the end-to-end pipeline: pulling sales orders from the source system and writing sales delivery orders into the target ERP, with monitoring, compensation, and replayability built in.
Data Flow and Field Mapping
The flow is unidirectional: Source system (orders via open interface) → Qeasy middleware (standardization, cleansing, mapping) → Target ERP (sales delivery orders generated).
| Dimension | Source (Online Sales Order) | Target (Sales Delivery Order) | Handling Notes |
|---|---|---|---|
| Document Type | Online sales order | Standard sales delivery order | Lock the type on the target side; no overwrite |
| Document No. | Source order ID | Source order ID (as a reference field) | Used for reconciliation and tracing |
| Header Customer/Store | Platform store code | Customer code | Must already exist in the target customer master |
| Header Date | Order placement time | Business date / posting date | Follow the target accounting rules |
| Line Item Code | Merchant code / SKU | Material code | Must already exist in the target item master |
| Line Quantity | Sales quantity | Base-unit quantity | No unit conversion; keep the original value |
| Line Tax-Inclusive Price/Amount | Platform-amount fields | Tax-inclusive unit price / amount | Strictly two decimal places |
| Warehouse | Default shipping warehouse | Warehouse code | Must match the target warehouse master |
A typical pattern: keep all code mappings (store→customer, SKU→material) in Qeasy's centralized mapping tables so they can be reused across multiple strategies instead of being redefined each time.
Configuring It in Qeasy
In Qeasy, this strategy is usually assembled from three building blocks:
- Source reader: Use the source platform's order-query interface, pull incrementally by modification time, and add business-state filters (e.g., paid / pending shipment) so invalid orders don't enter the pipeline.
- Cleansing and mapping: Use Qeasy's field-mapping and formula components to handle store→customer, SKU→material, and amount formatting uniformly. For this no-batch-number scenario, explicitly set the batch-number field to null to bypass the target's strict batch validation.
- Target writer: Call the target ERP's "save then submit" two-step interface for sales delivery orders, avoiding pile-ups in draft status.
Hard requirements at the configuration layer: the source pull must support pagination (no missing pages), and the target write must capture the returned document number and internal ID back into a staging table for idempotent deduplication.
Implementation Steps
We recommend rolling this out in three phases:
- Phase 1 – Full initialization: Manually trigger a full sync in Qeasy with a time window covering one full business cycle (e.g., the last 90 days) to validate mapping tables and master data coverage. Don't rush into scheduling after the first run.
- Phase 2 – Confirm the incremental watermark: Take the modification time of the last fully-synced order as the starting watermark and write it into Qeasy's cursor management. Subsequent increments only pull orders after this watermark.
- Phase 3 – Steady-state scheduling: Based on the client's volume, set the frequency to every 5–15 minutes; for high-volume, order-dense cases, switch to a near-real-time mode (1–2 minutes). Enable failure retries and alert notifications on the Qeasy side.
In addition, a separate reconciliation strategy (hourly or daily) is usually paired with it in Qeasy to compare document counts and amounts between the two systems, catching issues at reconciliation time rather than at month-end.
Pitfalls and Lessons Learned
- Mishandled batch-number fields. This is explicitly a no-batch-number scenario, but pushing the source's empty string as-is can still trigger the target's batch validation. The safe approach: set the field to NULL in the mapping layer and confirm that the target allows nulls for this no-batch business case.
- Running before master data is ready. Missing entries in store, SKU, customer, or item masters will cause the target to reject the order. Make master-data sync strategies (item, vendor, customer) a hard prerequisite, and only enable business-document sync after masters are stable.
- Drifting incremental watermark. If the source supposedly supports pull-by-modification-time but actually returns creation-time, the watermark will crawl forward or stall. In the Qeasy source component, explicitly bind the cursor to the true timestamp field.
- Amount precision truncated by the middleware. E-commerce amounts often arrive with three decimals or special characters. Explicitly round to two decimals and strip currency symbols and commas before pushing to the target.
- No idempotent deduplication. Replays or concurrent runs can produce duplicate delivery orders. In Qeasy, enable a unique-key check on "source order ID + business date," and turn on duplicate-save blocking on the target side.
When to Use and When Not to Use
This strategy fits scenarios where multiple front-end channels are consolidated into a unified ERP, order volume is high, and shippable documents must be generated in frequent batches. It is not suitable for scenarios that require strict batch/serial-number management, demand ultra-low-latency delivery posting (under one minute), or involve cross-organization, multi-currency, complex settlements. Those cases should be designed as separate strategies with their own compensation mechanisms.