Sync from Jushuitan Qimen Orders to Kingdee Cloud Sales Orders: A Single Strategy End-to-End Implementation
What This Strategy Solves
A retail enterprise takes e-commerce orders from Jushuitan Qimen and books them in Kingdee Cloud V2. Manual export leads to three problems: delayed vouchers, mismatched inventory views, and inconsistent promotional or tax handling between systems.
A single sync strategy from Jushuitan Qimen orders to Kingdee sales orders does one straightforward thing: it lands finalized e-commerce orders into the sales order module using Kingdee's field semantics, keeping both sides reconcilable.
Data Flow and Field Mapping
The pipeline is one-way: Jushuitan Qimen → Qeasy Integration Platform (the middle layer) → Kingdee Cloud V2.
The middle layer does not perform business calculations. It only fetches, cleans, and transforms. We centralize code mappings (stores, customers, materials) in Qeasy's mapping tables rather than hard-coding them in scripts. When a new store is added or renamed, the operations team can update the table themselves.
Key field mappings (only those that typically cause trouble):
| Business Meaning | Jushuitan Qimen | Kingdee Cloud V2 | Notes |
|---|---|---|---|
| Voucher Number | shop_oid + order_no | FBillNo | Prefix in the middle layer to avoid duplicates |
| Voucher Date | order_time | FDate | Watch time zones |
| Customer Code | shop_id + buyer | FCustomerID | Use mapping table |
| Material Code | sku_id | FMaterialID | Use mapping table |
| Tax-included Price | price | FPrice | Mind precision |
| Tax Rate | tax_rate | FTaxRate | Default 13%, validate |
| Header Remark | remark | FNote | Truncate length |
| Body Lines | items[] | FEntity[] | Handle header and body in stages |
How to Configure on Qeasy
On the Qeasy data integration platform, this strategy is built with two components: a source fetcher and a target writer.
Source side: Jushuitan Qimen exposes a pull-order interface via the Qimen open platform. We fetch incrementally by modification time. The interface returns JSON, which Qeasy can parse directly into row-shaped data.
Middle layer: Qeasy's field-mapping node renames fields, converts types, and runs conditional branches (for example, whether gift lines are recorded or whether tax is included).
Target side: Kingdee Cloud V2's sales order save interface uses a nested header-body structure. We use a staged header-then-body pattern on Qeasy: generate the header first, then submit the FEntity array in a second step. This avoids a single failed transaction rolling back the entire voucher.
All code mappings go through Qeasy's mapping table component. Do not write if-else logic inside scripts.
Implementation Steps
Roll out in three stages to stay safe.
Stage 1: Incremental starting point. Confirm Kingdee's opening date first, then set the Qeasy incremental starting point to the day before that opening date. The first run of the live strategy pulls a slice of historical data, after which we immediately switch to modification-time incremental sync.
Stage 2: Full reload. Run once at initial go-live or after a major change. We use Qeasy's manual trigger to execute a full reload. Before switching to production, we run the full flow end-to-end in a test environment.
Stage 3: Scheduling frequency. For order workflows, we recommend an incremental run every five minutes, configured in Qeasy's scheduler. A daily reconciliation job at midnight catches anything missed during the day. Qeasy's scheduling dashboard shows batch row counts and durations, with anomalies routed to an alert group.
Field-Tested Pitfalls
First, time zones. Jushuitan timestamps are Beijing time by default, but orders placed late afternoon can cross midnight and be posted to the next day in Kingdee. The safe approach is to split "order time" and "business date" in the middle layer, taking the business date from Jushuitan's order date.
Second, tax rate and precision. Jushuitan returns price as tax-inclusive; Kingdee expects tax-exclusive price plus a tax rate. A typical mistake is mapping price directly to FPrice, doubling amounts on the Kingdee side. In Qeasy's transformation node, we divide the tax-inclusive price by (1 + tax rate) and round to two decimals.
Third, gift lines and combo items. Gift lines in Jushuitan may carry no amount; pushing them through as-is triggers an invalid voucher error in Kingdee. In the middle layer we add a check: when the gift line amount is zero, set FPrice to zero and exclude it from tax computation. Kingdee then accepts the line normally.
Fourth, idempotency. The biggest fear with order sync is duplicate posting. On the Qeasy side, we use Jushuitan's order_no as the primary key, prefixed and written to Kingdee. Kingdee then deduplicates, so even if Qeasy reruns, no duplicate vouchers appear.
Fifth, alert thresholds. If a batch fails more than three times in a row, Qeasy automatically pauses the schedule and raises an alert, preventing dirty data from spreading. This has rescued us more than once on customer sites.
When This Fits and When It Doesn't
This fits: stable daily order volume (under tens of thousands), standardized order structures, and no requirement for complex promotion recalculation in the middle layer.
This does not fit: workflows that need real-time inventory to split orders, complex allocation in the middle layer, or cross-ledger consolidation. Those scenarios need a stronger middle-layer capability and should not be carried by a single SYNC strategy alone.