Sales Outbound Sync Tutorial: Incremental Closed Loop from Jushuitan to Kingdee Cloud

What This Strategy Solves

In a real retail supply-chain integration project, the front-end e-commerce ERP generates a large volume of confirmed sales outbound orders every day. Finance and supply-chain teams need those orders in the back-end ERP to post accounting entries and deduct inventory. Manual export works for a while, but once order volume grows, it breaks down and the two sides stop agreeing on inventory numbers. The goal of this single strategy is to move confirmed sales outbound orders incrementally from the front end to the back end, so outbounds are visible the same day and inventory deductions are traceable.

Data Flow and Field Mapping

The flow is: Source (Jushuitan) → Qeasy Data Integration Platform → Target (Kingdee Cloud). Qeasy acts as both the mover and the translator.

On the source side, we call the jushuitan.saleout.list.query API and pull incrementally by start_time / end_time, with a window no longer than 7 days. We only take records where status = Confirmed. Pagination starts at page_index = 1, with page_size defaulting to 25.

On the target side, we write into Kingdee Cloud via the batchSave API, using bill type XSCKD01_SYS, and pass date, sales organization, customer, and department through variables.

Key field mapping:

The shop_id → FCustomerID mapping is the most error-prone piece. We centralize it in Qeasy's encoding mapping module so that adding a new shop only requires one edit.

How to Configure It in Qeasy

This strategy is a typical "Source QUERY + Target EXECUTE" combination on the Qeasy Data Integration Platform. Key configuration points:

• Register the data source: fill in the Jushuitan Qimen platform appKey / appSecret and bind authorized shops.
• Register the target: select Kingdee Cloud and enter organization code, app ID, and other basics.
• Source API: choose jushuitan.saleout.list.query, bind start_time, end_time, status to variables; fix status to Confirmed.
• Target API: choose batchSave, hard-code bill type XSCKD01_SYS, pass date and document number through variables.
• Mapping rules: one-to-one mapping for header fields, split line items into a separate stage; route customer encoding through centralized mapping rather than hard-coding in scripts.
• Dedup and idempotency: use io_id as the idempotency key, enable idCheck on the target so the same document cannot be created twice.

Implementation Steps

We usually recommend a three-step rollout: "incremental start point → full trigger → schedule frequency".

Step 1: Define the incremental start point. Agree on a clear timestamp with business owners, for example 2024-01-01 00:00:00. Anything before that goes through the historical full-load channel; anything after goes through the incremental channel. Control the window with {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}.

Step 2: Run the full trigger. Manually execute a historical window in Qeasy to backfill all existing confirmed outbounds and reconcile totals against the source. Do not skip this step — otherwise the month-end closing numbers will not match, and root-causing it later is extremely painful.

Step 3: Steady-state scheduling. Source uses */23 * * * *, pulling increments every 23 minutes; target uses */40 * * * *, pushing to Kingdee every 40 minutes. The two are offset to avoid backlog. After running for a while, we tighten the frequency to every 15 minutes based on actual volume.

Lessons from the Field

1. Window longer than 7 days fails immediately. The Jushuitan API requires the start/end interval to be ≤ 7 days, so the schedule interval must also be < 7 days or the stream breaks.
2. Shop encoding not centralized. One customer originally hard-coded shop_id → FCustomerID in scripts. When a new shop opened six months later, three scripts had to be patched. Since then we always centralize encoding mapping.
3. Header and body run in one round. Outbound orders have many line items. It is safer to stabilize the header first, then handle the body separately in a "header-then-body phased" approach — failure localization becomes much faster.
4. Duplicate push creates duplicate docs. Always enable idCheck. Without it, a network retry will create two identical sales outbound orders on the target side and trigger reconciliation headaches.
5. Incremental and full-load share one pipeline. If both run on the same channel, a watermark misalignment can overwrite history. We recommend two independent strategies in Qeasy — one for full-load, one for incremental — each managing its own watermark.

When to Use and When Not To

Use it when: the front end is Jushuitan, the back end is Kingdee Cloud, and daily outbound volume is within a few thousand orders — typical retail or distribution scenarios. Do not use it when: the business requires sub-second synchronization between warehousing and distribution (use a message queue or a direct WMS link instead), or when handling non-confirmed pre-outbound documents — this strategy only syncs Confirmed status.