Sync Sales Returns from Jushuitan to Kingdee Cloud Skylink: Non-Qimen Local Warehouse Tutorial
What This Strategy Solves
A retail company runs Jushuitan as its e-commerce front end and Kingdee Cloud Skylink as its back-end finance and inventory system. Once both sides enter documents independently without an aligned returns flow, reconciliation gaps appear within three months: items already returned on one side still show as shipped on the other. We use the Qeasy data integration platform to bridge this narrow but critical link — sales returns to sales outbound — so that return documents flow into Kingdee by rule instead of manual re-entry.
Data Flow and Field Mapping
The direction is Jushuitan (return order) → Qeasy middle layer → Kingdee Cloud Skylink (sales outbound order). The middle layer does not just transport data; it also handles code mapping, field conversion, and status validation.
Key field mapping (sanitized):
| Business meaning | Jushuitan source | Middle layer | Kingdee target |
|---|---|---|---|
| Document number | Return order ID | Pass-through | FBillNo |
| Document type | Return type flag | Split by local / Qimen warehouse | Sales outbound business type |
| Warehouse | Return-to warehouse code | Map to Kingdee warehouse master | Inventory org + warehouse code |
| Item code | SKU code | Look up in item mapping table | Material code |
| Quantity | Return qty | Unchanged | Actual issue qty |
| Customer | Shop / customer ID | Map via customer master | Customer code |
| Cancel-after-receipt flag | Business status | Strong validation, used as trigger | Remark / business flag |
How to Configure in Qeasy
In the Qeasy integration platform, configure in three stages: data source → mapping → destination.
1) Source: Jushuitan return order Select the return/return-in business module. Pull incrementally by modification time, and use the "cancel-after-receipt" business status as a filter — only return orders hitting this status enter the push queue.
2) Middle-layer mapping This is where real work happens. We typically centralize code mapping: the three lookup tables — material code, customer code, and warehouse code — are kept in Qeasy's mapping dataset instead of being hard-coded in scripts. When a new SKU or shop is added, only one place changes.
Another engineering habit is header and body in two stages: push the header first and confirm it lands in Kingdee, then fill in the line items. This avoids the situation where Kingdee rejects the whole document due to a body-level check, making troubleshooting harder.
3) Destination: Kingdee Cloud Skylink sales outbound Submit through Kingdee's save interface. Run pre-validation in the middle layer before submission — sign of quantity, required fields, and organization multi-dimension.
Implementation Steps
We usually deploy scheduling in three phases:
- Phase 1: Incremental starting point On the first run, manually specify a starting timestamp (e.g., a specific early-morning time) to backfill all return orders with "cancel-after-receipt" status after that point as the baseline. This usually runs once, then switches to incremental.
- Phase 2: Full-volume trigger (as fallback) Keep a manually triggered full-volume entry that is not on a timer — start it only when there is a period anomaly or a missing upstream order. Qeasy supports manual triggering, which is critical for us: production issues can be re-run immediately.
- Phase 3: Scheduling frequency For online business, suggest a 5–15 minute incremental polling interval. The return status in Jushuitan can transition from "pending review" to "cancel-after-receipt" in a short time; slow polling causes book-to-physical mismatches in Kingdee.
Pitfalls and Lessons
Pitfall 1: Wrong trigger status "Cancel-after-receipt" and "already returned to warehouse" are two adjacent states in Jushuitan. Filtering by a field containing the word "return" will pull in normal returns as well. The safe approach is for the middle layer to explicitly match the exact enum value of "cancel-after-receipt".
Pitfall 2: Mixing Qimen warehouse into the path This strategy is explicitly the "non-Qimen local warehouse" path, but Qimen and local warehouses in Jushuitan often share a parent node. The middle layer must filter again by the warehouse master type field, otherwise Qimen warehouse returns will leak in and the inventory organizations will not match.
Pitfall 3: Wrong incremental starting point When first running the baseline, if the starting point is set to 30 days before the current time, return orders that occurred at the start of the month will be missed. The safe approach is to reconcile the period start with the customer first, then set the incremental start.
Pitfall 4: Missing inventory organization dimension in Kingdee Kingdee Cloud Skylink sales outbound orders must carry both inventory organization and warehouse dimensions. Missing either will be rejected directly by Kingdee. The middle layer must perform a required-field validation before pushing.
Pitfall 5: Negative direction not aligned with finance Sales returns in Kingdee are usually handled as "sales outbound (negative)" to offset. The middle layer must align the sign of quantity with the finance convention; do not simply copy the sign from Jushuitan, or period-end reconciliation will break again.
When to Use and When Not
Use when: Jushuitan acts as the e-commerce front end and Kingdee Cloud Skylink as the back-end ledger; the warehouse is a local warehouse (not Qimen); the return status is clearly "cancel-after-receipt"; and a unified rule is required to generate Kingdee sales outbound orders (including the offset direction).
Do not use when: Qimen warehouse path, cross-border warehouse, or scenarios requiring a separate Kingdee return document (instead of negative outbound offset); also during a transition period when the Jushuitan return status is not yet stable and human judgment is still required.