Sales Outbound Sync in Practice: Kingdee Cloud Sales Delivery → Jushuitan Other Outbound
What this strategy solves
In a multi-system landscape, a retail business uses Kingdee Cloud as the system of record for finance and inventory, while Jushuitan handles online store fulfillment and shipping. Sales delivery orders need to be pushed from Kingdee to Jushuitan to drive outbound bookkeeping and shipping. It looks like a single integration, but if code mapping, inventory caliber, or the incremental watermark is wrong even once, the gap between books and reality grows fast. This strategy targets a stable, traceable sync under an on-premise deployment.
Data flow and field mapping
Overall flow: Kingdee Cloud (Sales Delivery Order) → Qeasy Data Integration Platform (mapping layer) → Jushuitan (Other Outbound Order).
The middle layer is responsible for field alignment and caliber conversion, not a plain pass-through. A typical mapping looks like this:
| Dimension | Kingdee source | Jushuitan target | Note |
|---|---|---|---|
| Document No. | Bill No. | external_no | Used for idempotency and lookup |
| Customer / Shop | Customer code | shop_id | Code mapping, managed centrally |
| Item | Material code | sku_id | Item master must be aligned first |
| Quantity | Actual qty | qty | Mind unit conversion |
| Warehouse | Inventory org / warehouse | warehouse_id | Warehouse mapping must exist |
| Date | Business date | delivery_time | Unify timezone and format |
| Doc type | Sales delivery | Other outbound (biz type) | Biz type is fixed on Jushuitan |
Extra notes: amount and tax fields are usually not transferred in an outbound scenario; Jushuitan calculates on its own. Batch and serial fields are mapped on demand.
How to configure on Qeasy
Using the Qeasy platform as the carrier, the strategy is broken into three segments.
Segment one: source extraction. Use Kingdee Cloud's query interface and filter by approved status, with a time window controlled by the incremental field. Avoid pulling too much history at once.
Segment two: the mapping layer. Centralize code mapping (customer, item, warehouse, org), format dates and numbers, and fill fields per business rules. A common pattern among Qeasy customers is centralized mapping management — keep all mapping tables in one place on the platform rather than scattered across scripts, so future changes propagate cleanly. A useful phasing tactic is headers first, line items second: stabilize the header path before adding line complexity.
Segment three: target write. The Other Outbound interface on Jushuitan has required fields and doc-state rules; configure strictly per the official spec. Use the external document number as the idempotency key.
Implementation steps
- Prerequisites: confirm sales delivery orders are approved in Kingdee, and that warehouse, org, customer, and item masters exist on both sides with codes aligned.
- Incremental watermark: do a one-time full initialization for history, then switch to incremental. Use Kingdee's modification time as the watermark, filtered by approved status.
- Phased scheduling: run headers at a 5–10 minute cadence first, watch reconciliation, then move to 1–3 minutes once lines are stable.
- Write-back and lookup: after Jushuitan accepts the order, write the platform doc number back to the mapping layer for troubleshooting.
- Exception handling: retry on the platform side, never pollute the source system; alert on consecutive failures for human intervention.
The dual-track approach — full and incremental running side by side — is the safe rhythm: full load backs up the early days, incremental carries the steady state, and full load is retired after a stable window.
Pitfalls and lessons
- Scattered code mapping: in one project, the item code mapping lived in the source-side script while warehouse mapping lived in the target-side script. When one retail client renamed an item, the two sides drifted and debugging took a week. Keep mapping centralized so a single edit takes effect end to end.
- Wrong watermark: choosing creation time as the incremental field will miss orders that are pending approval or resubmitted after rejection. Use modification time, filtered by approved status.
- Units and precision: Kingdee stores qty in base units, Jushuitan sometimes uses sales units. Without a unit conversion table, values drift over time.
- Idempotency key collisions: using the Kingdee bill number as the external number is standard, but watch Jushuitan's de-duplication behavior. Do not blindly retry on failure — check the platform doc number first.
- On-prem network jitter: an on-prem deployment does not have the same network quality as public cloud. Loosen timeouts and use exponential backoff instead of fixed intervals.
When it fits and when it doesn't
Fits: self-operated warehouse fulfillment where Jushuitan needs to record the outbound, with Kingdee as the inventory book of record. Does not fit: pure stock transfers or inter-org movements (use a transfer-order sync), and scenarios that need real-time strong consistency (prefer event-driven integration over scheduled sync).