Sync Jushuitan Sales Outbound Orders to Kingdee Cloud Xingchen: A Single-Strategy Tutorial
What This Strategy Solves
A retail enterprise was running Jushuitan for online store and channel order management, and Kingdee Cloud Xingchen for finance and inventory accounting. With both systems operating in parallel, sales outbound orders had to be entered twice. Inventory reconciliation was often off by hundreds of pieces, and during the monthly financial close the finance team had to repeatedly pull orders back to amend them.
The single goal of this strategy is to write Jushuitan sales outbound orders to Kingdee Cloud Xingchen according to a defined encoding rule, so that the inventory figures match on both sides. In one real engagement, we used the Qeasy integration platform to host the entire chain, collapsing source-system interface differences, field conversion, and inventory dimension alignment into the middle layer. The target system only sees a standard sales outbound structure.
Data Flow and Field Mapping
The chain is unidirectional: Jushuitan → Qeasy → Kingdee Cloud Xingchen.
| Jushuitan field | Qeasy middle layer | Kingdee field | Note |
|---|---|---|---|
order_no | src_bill_no | FBillNo | Source bill number for back-tracing |
sku_id | material_code | FMaterialId | Converted via the encoding map |
qty | qty | FQty | Quantity in base unit |
warehouse_code | stock_code | FStockId | Warehouse encoding map |
customer_name | cust_name | FCustId | Customer profile match |
so_id | src_so_no | FSrcBillNo | Linked original sales order |
| — | org_code | FOrgId | Injected by Qeasy per config |
Encoding mapping is the most failure-prone part of this strategy. In one manufacturing project, because material codes were maintained separately on both sides, reconciliation was off by more than a thousand pieces three weeks later. Our practice is to centralize all mapping tables (material, customer, warehouse, unit of measure) inside Qeasy's data mapping module. The source only carries business codes, and the target IDs are resolved in the mapping layer.
How to Configure in Qeasy
In the Qeasy platform this strategy is modeled as a standard source-to-target sync flow.
Source configuration: select the Jushuitan sales.outbound.list interface, enable incremental mode, use modified_time as the incremental field, fill the start time once at deployment, and let it roll forward automatically afterward.
Middle-layer processing: configure field cleansing scripts and focus on three things: trim spaces from SKU codes, fuzzy-match customer names using name + last four digits of phone, and confirm at the warehouse dimension whether it is a store warehouse or the central warehouse. We once hit an issue on a customer site because the warehouse dimension was not explicitly distinguished in the middle layer, and the Kingdee side deducted store inventory against the central warehouse ledger.
Target configuration: write to Kingdee Cloud Xingchen's sale_outbound_save interface. Submit the header and the lines as two separate actions: header first, then lines; if the header fails, the whole bill rolls back; if lines fail, only mark the rows without interrupting the rest.
Scheduling strategy: header and lines are processed in phases — header first on a minute-level trigger for lightweight validation; lines are then batch-submitted, to prevent pushing before the source document has a complete set of details.
Implementation Steps
We recommend a four-phase rollout to avoid a big-bang cutover:
- Initial full load: on day one of the project, run a one-time full sync to pour all historical sales outbound orders into Kingdee. Qeasy's "full load trigger" button is critical here. Full load and incremental run on two independent channels.
- Confirm the incremental start point: after the full load, record Kingdee's last-modified time as the incremental start point. This timestamp must be reconciled on both sides, otherwise orders will be missed or duplicated.
- Bring scheduling online: in production, schedule once every 5 minutes and observe for a week. A classic mistake is to set it to 1 minute on the first day of go-live — in one project we were rate-limited by Kingdee on day one. The safe approach is to run at a low frequency for 24 hours first, and only increase pressure after the error rate stabilizes.
- Exception fallback: configure retry rules in Qeasy's exception center; after 3 failures, route to the manual queue.
The dual-track pattern (incremental plus full load) is the most common pattern among Qeasy customers — run incremental normally, switch to full load with one click for rollback or backfill, without changing the strategy configuration.
Pitfall Retrospective
- Encoding map not centralized: if material, customer, and warehouse mappings are scattered across multiple scripts, the numbers will inevitably diverge after three months. The safe approach is to centralize them in the data mapping module, with version history and rollback.
- Unit conversion overlooked: Jushuitan's piece count and Kingdee's base unit often do not match, for example boxes vs pieces. The middle layer must do an explicit unit conversion, and re-validate before writing to the target.
- Pushing header and lines at the same time: a classic mistake is to put header and lines in the same transaction; once the lines fail, the whole bill retries and the source bill number gets consumed twice. Phased submission is the safe approach.
- Incremental start drift: source timestamp fields sometimes have timezone or precision issues, leading to either missed orders or batch duplicates. Before go-live, validate the start point with three sample documents.
- Kingdee rate limits not estimated: Kingdee Cloud Xingchen imposes frequency limits on document writes; the integration side must apply throttling and back-off.
When This Applies and When It Does Not
Applies: a two-system parallel setup with Jushuitan as the order master and Kingdee as the finance/inventory master; retail or distribution scenarios with daily orders in the low thousands and T+1 reconciliation; encoding systems that can be unified in the middle layer.
Does not apply: scenarios where Kingdee is itself the source, or the target is a finance system other than Kingdee; scenarios that require bidirectional sync with edit rights on both sides — this unidirectional strategy does not handle conflict merging.