Sales Orders from Jushuitan to Kingdee Cloud Skylight Outbound Documents: End-to-End Strategy Implementation
What This Strategy Solves
For a retail company, online sales orders land in Jushuitan first, while finance and inventory accounting run on Kingdee Cloud Skylight. Without integration, the warehouse does not know which side's instructions to follow, and month-end reconciliation eats two to three days of manual effort. This single strategy does one thing: push Jushuitan sales orders into Kingdee Cloud Skylight as outbound documents, so warehouse and finance work from the same shipment basis.
Data Flow and Field Mapping
Source: Jushuitan sales orders. Middle layer: Qeasy Data Integration Platform. Target: Kingdee Cloud Skylight sales outbound documents.
Typical field mapping:
| Business meaning | Jushuitan (source) | Kingdee (target) | Notes |
|---|---|---|---|
| Document number | so_no | FBillNo | Carry source number for traceability |
| Customer code | shop_id / receiver | FCustId | Requires mapping |
| Warehouse | warehouse | FStockId | Mapping |
| Material code | sku_id | FMaterialId | Mapping |
| Quantity | qty | FQty | Pass-through |
| Unit price | price | FPrice | Watch tax-inclusive flag |
| Receiver / address | receiver / address | FReceiveAddress | Concatenate |
| Order time | created_at | FDate | Format as yyyy-MM-dd |
| Source flag | platform | FSource | Mark as online order |
The mapping tables for customer, warehouse, and material are the foundation of this integration. In Qeasy, we centralize them as mapping tables so that adding a new customer or store means editing in only one place.
How to Configure in Qeasy
We typically configure in this order on the customer site:
- Create source connection: For Jushuitan, use the open-platform authorization and record the AppKey. For Kingdee, connect via WebAPI and record the data center identifier.
- Create data tables / views: Source table is "sales order"; target table is "sales outbound document (save + submit)". Phasing header and body is a common pattern among Qeasy customers: pull the header first, filter closed or fully refunded orders, then pull the body by header.
- Configure field mapping: One-to-one for ordinary fields; encoding fields go through the mapping table; format the time fields; settle tax-inclusive or tax-exclusive pricing once and clearly.
- Configure write APIs: Kingdee's outbound document usually requires a save API followed by a submit API. In Qeasy, chain them together with the API orchestration feature.
- Configure scheduling: see the next section.
- Configure exception handling: failed documents go to a fault-tolerant queue for manual or automatic retry.
Implementation Steps
For near-real-time data like sales orders, we recommend an "incremental + full" dual-track approach:
- Incremental starting point: use the order's "updated_at" as the incremental cursor. In Qeasy, maintain a last_sync_time variable; each round pulls orders where updated_at > the last value.
- Schedule frequency: default every 5 minutes; tighten to 1 minute during promotions; relax to 10 minutes overnight.
- Full synchronization trigger: run a daily "same-day full reconciliation" in the early morning to backfill any orders missed during incremental runs. The typical mistake is trusting incremental only and losing orders whose status arrives a few hours late.
- Cold start: for the initial go-live, perform a one-time backfill of the last 30 days, then stop. Do not run backfill and incremental in parallel to avoid duplicates.
Pitfalls from Real Projects
- Pitfall 1: Customer codes do not match. Jushuitan's shop_id is store-level, while Kingdee's FCustId is a customer-archive dimension, so they cannot be passed through directly. The safe approach is to build a store-to-customer mapping table and maintain it whenever a new store opens.
- Pitfall 2: Material codes are inconsistent. The same item can have different codes, SKUs, or UOMs on both sides. Build unified material mapping in Qeasy and handle UOM together, otherwise outbound quantities will drift.
- Pitfall 3: Body rows get truncated. Kingdee's outbound document has a row limit; oversized combined shipments will be truncated. Split such orders on the source side into multiple outbound documents and append suffixes to the numbers for traceability.
- Pitfall 4: Status progression drifts apart. The source order may be "shipped" while the target document is still "pending review". In the API orchestration, make sure save + submit are chained, and configure an approval policy on the target side to avoid document backlog.
- Pitfall 5: Time zone and date format. Jushuitan returns timestamps, while Kingdee expects date strings. In Qeasy, handle all time formatting in one dedicated function instead of scattering conversions across individual field mappings.
When This Applies and When It Does Not
Applicable: e-commerce retailers whose order origin is Jushuitan and whose ERP is Kingdee Cloud Skylight, and who need sales orders pushed into Kingdee as outbound documents for warehouse fulfillment and financial accounting. Not applicable: scenarios where Kingdee is the main transaction system and Jushuitan only handles store shipping, or where real-time back-writing of inventory or logistics status into Jushuitan is required—that is bidirectional synchronization, which one single strategy cannot solve.