Practical Tutorial: Syncing Jushuitan Non-Qimen After-Sales Orders to Kingdee Cloud Starry Sky Sales Returns
What This Strategy Solves
A retail enterprise runs Jushuitan for storefront and e-commerce fulfillment, while back-office finance and inventory live in Kingdee Cloud Starry Sky. Once an after-sales order is created, customer service has to enter it twice — at best that is duplicate work, at worst a refund has already been issued to the customer while the return document in Kingdee was never posted, leaving stock and sub-ledger accounts out of balance.
This strategy collapses those two steps into a single, one-way flow: as soon as a non-Qimen after-sales order is approved in Jushuitan, it is pushed to Kingdee Cloud Starry Sky and turned into a sales return document. We deliver this on the Qeasy data integration platform, which owns field mapping, execution cadence, and failure retry.
Data Flow and Field Mapping
The flow is one-way: Jushuitan (source) => Qeasy middleware => Kingdee Cloud Starry Sky (target). The middleware only translates fields and tags status; it does not persist business data, avoiding dual-write.
Key field mapping (code mappings are centrally managed in Qeasy dictionaries):
| Business meaning | Jushuitan source field (example) | Qeasy middleware | Kingdee target field (example) |
|---|---|---|---|
| Document number | so_id / refund_no | doc_no | FBillNo |
| Customer code | shop_id | customer_code | FCustomerNumber |
| Warehouse code | warehouse | stock_code | FStockNumber |
| Refund amount | refund_amount | total_amount | FAmount |
| Refund reason | reason | reason_text | FNote |
| Line items | items[] | line_items[] | FEntity (entries) |
| Material code | sku_id | material_code | FMaterialNumber |
| Quantity | qty | qty | FQty |
| Unit price | price | price | FPrice |
Two points matter here: Jushuitan's warehouse codes and Kingdee's warehouse profile codes do not share a numbering scheme, so a mapping table must be maintained in Qeasy. Material codes follow the same rule. Free-text fields like refund reason can typically be passed through directly.
How to Configure on Qeasy
In Qeasy, one strategy corresponds to one integration flow, and the core configuration sits in three places.
1. Source connector. Pick the Jushuitan non-Qimen channel, configure access credentials and store scope; the key is to select the "after-sales order" business object and set the incremental cursor field (e.g., modified_time) along with the initial full-load timestamp.
2. Target connector. Pick the Kingdee Cloud Starry Sky V2 interface, log in to the on-premise Kingdee tenant, and authorize write access to the sales return document. We recommend either "save and approve" or the safer "save only with manual review" mode — the latter is more conservative.
3. Field mapping and scripts. In Qeasy's mapping canvas, complete the correspondences above. Use a staged header/body pattern for line items — first the header (customer, warehouse, refund amount), then the body (product lines), joined by doc_no. The typical pitfall here is line ordering: if the items array in a single Jushuitan document contains duplicate SKUs, the script must aggregate by sku before posting, otherwise Kingdee rejects with "duplicate entries".
Implementation Steps
In real projects, we usually run it in three phases.
Phase 1: Full initialization. Pick a historical starting point (for example, 90 days back) and pull all Jushuitan after-sales orders once, triggering a manual full sync in Qeasy. This only runs once, and its job is to backfill historical data — it will not run again.
Phase 2: Switch the incremental origin. Once the full load is verified clean, move the cursor to the modified_time at the end of the full run and only sync new or changed after-sales orders from that point on. The incremental start must align precisely with the end of the full load, otherwise orders will be missed or duplicated.
Phase 3: Steady-state scheduling. Configure cron in Qeasy's scheduler, polling every 5–10 minutes. Turn on failure retry (up to 3 retries with exponential backoff) and set an alert in Qeasy's monitoring panel for documents stalled for more than 30 minutes. After-sales orders carry SLA pressure, so the polling interval should not be longer than 5 minutes.
Lessons Learned from the Field
1. After-sales order vs refund-only confusion. In Jushuitan, "after-sales order" includes both refund-only and return-with-refund; only the latter maps to a Kingdee sales return document. The source filter must exclude refund-only by the type field, otherwise Kingdee will see an "unrecognized source document" or stock will be wrongly reduced.
2. Missing warehouse mappings. Configure every warehouse mapping up front rather than patching as you go. A missing warehouse fails the entire document instead of a single line.
3. Wrong customer-code basis. Jushuitan's shop_id is not the same as Kingdee's FCustomerNumber. Use the agreed customer profile code (typically the "customer" or "member" numbering scheme) rather than substituting a store ID.
4. Cursor disturbed by manual edits. If customer service manually edits an approved after-sales order in Jushuitan, modified_time moves backwards. The safe approach is to add a status filter in Qeasy (sync only approved) so that processed documents are not repeatedly overwritten.
5. Network jitter in on-premise deployments. Internal domain changes or certificate renewals in an on-premise Kingdee Cloud Starry Sky deployment can briefly drop the Qeasy connector. Enable connection health checks in Qeasy and configure backup addresses.
When This Applies and When It Doesn't
Applies to: Retail-leaning enterprises with e-commerce operations, an on-premise Kingdee Cloud Starry Sky deployment, and customer refunds handled primarily in Jushuitan, where after-sales orders and sales returns must correspond one-to-one.
Does not apply to: Scenarios where the after-sales process originates in ERP, where the source system uses the Qimen channel, or where refund-only cases make up the vast majority of after-sales activity (since those do not need sales return documents).