Sales Order Sync in Practice: From Jushuitan to Kingdee Cloud Skylink
What This Strategy Solves
A retail enterprise generates large volumes of sales outbound orders every day. The source system is Jushuitan, while the finance and supply chain back end sits in Kingdee Cloud Skylink. Without proper integration, you end up in an awkward situation: the front-end has shipped, but the back-end has not deducted inventory.
The core value of this strategy is simple: it pulls confirmed (Confirmed) sales outbound orders from Jushuitan on a daily schedule, routes them through the Qeasy data integration platform for field mapping and business rule processing, and lands them as standard sales outbound documents in Kingdee Cloud Skylink.
Data Flow and Field Mapping
The flow has three segments: Jushuitan (source) → Qeasy Integration Platform (middle layer) → Kingdee Cloud Skylink (target).
The source side calls the Jushuitan Open Platform's jushuitan.saleout.list.query interface, pulling incremental data by "modification time range + document status." The middle layer handles code mapping, field renaming, and field splitting/merging. The target side calls Kingdee Cloud Skylink's batchSave interface to write the sales outbound document.
Key field mapping reference:
| Business Meaning | Jushuitan (Source) | Qeasy Middle Layer | Kingdee (Target) |
|---|---|---|---|
| Document No. | io_id | Pass-through | FBillNo |
| Outbound Date | io_date | Format to standard date | FDate |
| Shop / Customer | shop_id | Customer mapping table | FCustomerID |
| Document Status | status | Filter to Confirmed | (controlled by API) |
| SKU Code | sku_id | Item code mapping | FMaterialID |
| Quantity | qty | Numeric validation | FQty |
| Document Type | (n/a in source) | Constant value | FBillTypeID |
| Sales Org | (n/a in source) | Constant value | FSaleOrgId |
One thing worth highlighting: centralized code mapping management is a very common pattern among Qeasy customers—pulling the mapping tables for shops, warehouses, and items into a single place rather than scattering them across every strategy.
How to Configure on Qeasy
There are four typical configuration areas:
- Source adapter: Use the Jushuitan Open Platform adapter. Pick the
jushuitan.saleout.list.queryinterface with POST method. Configurestart_time,end_time, andstatusas variable references. - Target adapter: Use the Kingdee Cloud Skylink adapter. Pick the
batchSaveinterface. Org-level fields likeFBillTypeIDandFSaleOrgIdare set as constants. - Field mapping table: Build the source-to-target field mapping. Any field that points to master data (customer, item, etc.) should reference the code mapping tables.
- Write strategy: Enable
idCheckand use the sourceio_idas the idempotency key. Re-running will not produce duplicate documents.
Implementation Steps
We recommend a phased rollout:
Phase 1: Align the incremental starting point. Run a full sync first in Qeasy to backfill historical sales outbound documents. Then switch to incremental mode, where start_time is the last sync time and end_time is the current time. Note that Jushuitan requires the time range not to exceed 7 days; anything beyond that gets rejected, so keep the incremental window under control.
Phase 2: Full-trigger validation. When switching environments or doing major version changes, run a full reload as a safety net. Incremental stays as the default. Running incremental and full in parallel is a common practice among Qeasy customers.
Phase 3: Scheduling frequency. The source crontab is set to 0 22 * * * (pull at 22:00 every day); the target crontab is 0 1 * * * (write at 01:00 the next day). The two schedules are staggered, leaving enough window for data landing and exception retries.
Lessons Learned
These are pitfalls we've actually hit in real projects:
- Time window over 7 days gets rejected. Jushuitan does not allow the interval between
start_timeandend_timeto exceed 7 days. If a scheduled run is missed one day, the next run's window can easily exceed the limit. The safe approach is to add window-slicing logic in Qeasy that automatically splits ranges longer than 7 days into multiple segments. - Wrong document status filter. The source
statusmust be explicitly set toConfirmed. Otherwise, you pull in dirty data—pending outbound, cancelled, etc.—and pollute the downstream. - Missing customer code mapping. The shop IDs in Jushuitan and the customer IDs in Kingdee are not one-to-one. Missing the mapping on initial setup causes write failures or posts to the wrong customer. Strongly recommend maintaining the mapping table as a reusable resource rather than hardcoding it in the strategy.
- Header and body done in stages. Trying to configure header and body all at once in the first version tends to cause repeated rework on field validation. A common pattern among Qeasy customers is to get the header working first, then layer in the line items.
- Forgetting to enable idempotency. Without
idCheckenabled, re-runs produce duplicate documents. Always confirm the idempotency key is configured correctly.
When to Use and When Not to Use
Use when: You are a retail or distribution business with moderate daily order volume and tolerance for "daily" level latency; you already run Kingdee Cloud Skylink as your finance and supply chain back end and need sales outbound data to flow back from the e-commerce front end.
Do not use when: You need minute-level real-time sync, span multiple orgs or books, require complex approval workflows before write-back, or when the source has no reliable modification timestamp and must be event-driven.