Syncing Sales Outbound Orders from Jushuitan to Kingdee Cloud Cosmos: Incremental Scheduling on Qeasy

What This Strategy Solves

For retail businesses, moving e-commerce outbound orders from Jushuitan to Kingdee Cloud Cosmos for financial posting and inventory accounting looks like simple "document transport." But if the incremental window, status filter, and shop-to-customer mapping are not designed carefully, the two systems drift apart within three months and month-end reconciliation becomes an incident.

This strategy addresses one specific scenario: pull Confirmed sales-outbound orders from Jushuitan daily by modification time, and write them as standard sales-outbound documents (XSCKD01_SYS) into Kingdee Cloud Cosmos, pinned to sales organization 101, with customers mapped from shops.

Data Flow and Field Mapping

Data Flow: Jushuitan (source) → Qeasy data integration platform (middleware, with transformation and mapping) → Kingdee Cloud Cosmos (target).

Key Field Mapping Table (desensitized from the source material):

How to Configure It on Qeasy

On the Qeasy data integration platform, this strategy is typically configured with two nodes — source and target:

1. Source node (Jushuitan · Qimen): API is jushuitan.saleout.list.query, POST. Pagination with page_index and page_size (max 50). Incremental window uses start_time / end_time, start with {{LAST_SYNC_TIME}}, end with {{CURRENT_TIME}}, with the interval not exceeding 7 days. Status filter is hardcoded to Confirmed.
2. Target node (Kingdee Cloud Cosmos): API is batchSave, document type XSCKD01_SYS, sales organization 101. Enable idCheck with io_id as the idempotency number to prevent duplicate writes.
3. Middleware mapping layer: The shop-to-customer encoding map should be maintained centrally in a single mapping table rather than hardcoded inside each strategy. A common Qeasy customer pattern is to process the header first, then submit the line-item body in a second phase.

Implementation Steps

We tend to push an incremental strategy through three phases:

Phase 1: Confirm the incremental starting point. Before the first go-live, manually set a start_time (e.g., 00:00 on the go-live day) and initialize LAST_SYNC_TIME to this value to avoid missing data.

Phase 2: Full backfill trigger (once, on go-live day). Use a temporary task to pull all Confirmed orders from the past N days. Since the window must be ≤ 7 days, slice into 7-day loops. Once the full backfill completes, snap the cursor to "current time" immediately.

Phase 3: Steady-state incremental scheduling. Schedule the source at 0 22 * * * (every day at 22:00, pulling the previous full day), and the target at 0 1 * * * (writing at 01:00 the next day). The two time points are staggered to leave margin for the source pull and to avoid peak hours on the Kingdee side. A common Qeasy customer pattern is the dual-track of incremental and full: keep the full script available but disabled by default, only enabling it manually during breakpoint recovery.

Lessons from the Field

1. Silent failure when the window exceeds 7 days. The Jushuitan interface returns an error when start_time to end_time exceeds 7 days, but the error message is not prominent. The safe approach is to add "automatic window slicing" logic in the Qeasy scheduler script.
2. Shop ID does not match the customer master. A typical issue seen on customer sites is that after a new shop is opened in Jushuitan, the customer master has not been created on the Kingdee side, and batchSave then fails. It is recommended to add a "master pre-validation" step before the mapping layer — write missing entries into a todo queue rather than throwing an error directly.
3. WaitConfirm orders leak in. The source-side status filter must be hardcoded to Confirmed, otherwise orders that have not actually shipped will enter the financial system, causing inventory mismatches at month-end.
4. Using FBillNo alone is not enough for idempotency. The same document number with different modification times causes duplicate writes. The recommended idempotency key combination is io_id + io_modified_time.
5. Timezone drift. Jushuitan timestamps are UTC+8, but when Kingdee parses them in local time, cross-day data may be lost. The middleware layer should uniformly force +08:00 handling.

Applicable and Non-Applicable Scenarios

Applicable: E-commerce retail, where shipping immediately posts to the books, with Jushuitan as the front-end OMS and Kingdee Cloud Cosmos as the back-end ERP — typically small to mid-sized merchants. Not applicable: B2B bulk outbound, multi-level sales orders requiring approval flows, and scenarios where Kingdee has a custom document type (other than XSCKD01_SYS) — the latter requires redoing the document type and field mapping.