Sync After-sales Orders from Jushuitan to Kingdee Return Documents: A Field Guide

What This Strategy Solves

A retail enterprise needs after-sales return-to-warehouse orders from a JD channel to form return documents inside the ERP for financial reconciliation and inventory rollback. Jushuitan records aftersales orders in an "actual received" status; Kingdee Cloud · Galaxy flagship edition needs standard sales return documents. This strategy stitches the two together so changes on the front-end platform close the loop inside the ERP.

Data Flow and Field Mapping

The flow is one-way: Jushuitan → middle layer (Qeasy) → Kingdee Cloud · Galaxy flagship edition.

On the source side (Jushuitan), the integration calls /open/aftersale/received/query, paging by modified_begin to modified_end with a page size of 50. The primary key is io_id, and idCheck=true prevents duplicates.

On the target side (Kingdee Cloud · Galaxy flagship edition), the integration calls /kapi/v2/im/im_saloutbill/batchAddV2 to batch-create sales-outbound return documents. The document type code is im_SalOutBill_STD_BT_S_R.

Business meaning	Jushuitan field	Kingdee field	Notes
Document number	`io_id`	`billno`	Pass-through, used for cross-system reconciliation
Shop / customer	`shop_id`	`customer_number`	Route through Qeasy's centralized encoding mapping
Inventory org	Fixed `100`	`org_number`	Adjust to actual ledger in private deployment
Settlement currency	Fixed `CNY`	`settlecurrency_number`	Open another strategy for cross-currency
Document type	Implicit	`billtype_number`	Locked to the standard return document
Business org	Platform value	`bizorg_number`	Goes through the mapping table

Note: Jushuitan's shop_id cannot be written directly as a customer number. The middle layer must perform a shop-to-customer mapping. We use Qeasy's "centralized encoding mapping" to maintain a shop registry as a hot-reloadable mapping table, so adding a new channel means editing one place.

How to Configure in Qeasy

Source integration: Pick the Jushuitan adapter. Set modified_begin to {{LAST_SYNC_TIME|datetime}} and modified_end to {{CURRENT_TIME|datetime}}. Use a fallback timestamp for the first run.
Request parameters: Set page_index to 1, page_size to 50, and date_type to 4 (filter by modification time).
Middle-layer transform: In Qeasy Data Integration Platform, configure field mapping and a "header-then-body phased" process — write the header (document number, customer, organization) first, then loop through the body line items to ensure consistent line apportionment.
Target write: Call the Kingdee batch-add interface with idCheck enabled; failed rows go to the error queue.
Variable management: LAST_SYNC_TIME and CURRENT_TIME are maintained automatically by the platform. The cursor only advances after the strategy run completes, preventing missed records.

Implementation Steps

We recommend a three-phase rollout to avoid the risks of a hard cutover:

Phase 1: Anchor the incremental starting point. Manually reconcile a batch of historical received orders as the baseline. Initialize LAST_SYNC_TIME to "7 days before cutover," perform a full backfill, then switch to incremental mode.
Phase 2: Full + incremental in parallel. For the first two weeks, run both full and incremental tracks. Use Qeasy's reconciliation report to check whether document numbers match on both sides. Stop the incremental track immediately if any discrepancy is found.
Phase 3: Lock the schedule. Set the Jushuitan source crontab to 05,35 * * * * (5th and 35th minute of every hour) and the target write crontab to 20,50 * * * *. Stagger them by 15 minutes to leave a window for middle-layer transformation and retry on failure.

Lessons from the Field

Do not truncate modified_begin to a whole hour or day. A typical mistake is using 00:00:00 as the start, which causes records modified in the early morning of the current day to be missed. The safe approach is to use the previous successful CURRENT_TIME directly, advanced at millisecond precision by the platform.
shop_id is not the customer code. Writing the shop ID directly into the Kingdee customer field produces hundreds of "ghost customers" within two weeks. A mapping table is mandatory, and the mapping must be completed on the day a new shop is onboarded.
Document-number collisions on the batch interface. If the same number has been manually entered on the Kingdee side, the batch add fails entirely. Always enable idCheck, set billno to the Jushuitan original, and let Kingdee enforce uniqueness with its own rules.
Body line items being truncated. A source document may have 200 detail lines, but the target batches 50 at a time. Without "header-then-body phased" processing, headers can be written while bodies are missing, producing orphan documents.
Clock drift in private deployment. If the source server and the middle layer are out of sync, LAST_SYNC_TIME advances abnormally. We recommend turning on NTP drift monitoring in Qeasy and alerting when drift exceeds 30 seconds.

When to Use and When Not to Use

Use it when channel-platform documents enter an "actual received" state and need to form return documents inside the ERP — especially for multi-shop, multi-channel businesses with a clear "received" milestone.

Do not use it for cross-border multi-currency returns with complex approval flows, or for legacy source interfaces that lack a modification-time incremental field and can only pull the full database.