Sync Jushuitan Purchase Returns to Kingdee Cloud Xingchen: A Single-Strategy Implementation Guide
What This Strategy Solves
A retail-style business runs its e-commerce front end on Jushuitan and its finance and supply-chain back end on Kingdee Cloud Xingchen. Purchase returns initiated by buyers land in Jushuitan first. Without sync, inventory and payables diverge between the two systems — finance month-end ends up with inflated stock and misplaced refund postings. This strategy, built on the Qeasy data integration platform, pushes Jushuitan purchase returns into Kingdee purchase returns so the documents stay aligned and as close to real-time as possible.
Data Flow and Field Mapping
The flow is one-way: Jushuitan as source, Kingdee Cloud Xingchen as target, with Qeasy as the integration pipeline for cleansing and mapping.
| Dimension | Jushuitan (Source) | Kingdee Cloud Xingchen (Target) | Mapping Notes |
|---|---|---|---|
| Document No. | Purchase return No. | Return order No. | Passed through; used as the idempotency key |
| Return type | To supplier / To warehouse | Business type | Mapped via constants |
| Supplier | Supplier code | Supplier ID | Maintained centrally in Qeasy's code-mapping table |
| Item line | SkuId + quantity | Material code + actual return qty | SkuId–material code table managed centrally |
| Warehouse | Warehouse code | Warehouse ID | Same central mapping approach |
| Time | Created time / Approved time | Document date | Use approved time to avoid drafts polluting the stream |
| Amount | Refund amount | Price-incl.-tax total | Truncate precision per the target system's requirement |
How to Configure It in Qeasy
In the Qeasy data integration platform, create a new strategy: pick the Jushuitan "purchase return order" interface as the source, and the Kingdee Cloud Xingchen V2 "save purchase return order" interface as the target.
A few configuration points that commonly trip teams up:
- Trigger mode: pick "incremental + scheduled catch-up". Use Jushuitan's modification-time field for incremental pulls, and schedule a daily task that re-fetches the previous 24 hours as a safety net.
- Code mapping: do not hardcode it in scripts. Put it in Qeasy's code-mapping table so that supplier additions or material renames only need to be updated in one place.
- Header-then-line split: land the header first, then fill the lines via a sub-flow or post-action. This way a single failed line does not roll back the whole document.
- Idempotency key: use the source document number. The target system deduplicates by document number, so repeated pushes never create duplicate return orders.
Implementation Steps
On customer sites we break the rollout into four steps.
Step 1: Full historical backfill. Run a one-time historical full sync in Qeasy to backfill historical return orders into Kingdee. Mark a clear cutoff timestamp; subsequent incremental pulls start strictly after that point to avoid replay.
Step 2: Align the incremental start point. Set the incremental start time to one hour before the full-sync cutoff, to leave a clock tolerance on both sides. In the Qeasy strategy, put this start time into the scheduling parameters; the scheduler then rolls the window automatically.
Step 3: Scheduling frequency and monitoring. Default to an incremental pull every 5 minutes, plus a daily catch-up reconciliation. The Qeasy console shows pulled count, success count, and failure details per run; anomalies flow into the alerting channel.
Step 4: Gray release and rollback plan. Pilot with one warehouse or one supplier for about a week. Watch for document and inventory deltas between the two systems. Once stable, open it up. The rollback path is to use Kingdee's un-approve function on the target side so dirty data does not accumulate.
Pitfall Retrospective
Pitfall 1: Drafts get synced. Jushuitan return orders are edited repeatedly before approval. If you use modification time as the incremental field directly, drafts will be pushed into Kingdee. The safe approach is to filter on the source side for "approved" only and use the approval time as the incremental field.
Pitfall 2: Code mapping scattered everywhere. A typical mistake is to embed the SkuId-to-material-code mapping in scripts; once the customer changes materials, every integration task errors out. We centralize it in the code-mapping table so ongoing maintenance only touches one place.
Pitfall 3: Duplicate pushes cause duplicate documents. Jushuitan occasionally returns document numbers that have already been pushed. Without an idempotency key, the target system creates two return orders. Always enable "document number deduplication" in the Qeasy strategy and enforce uniqueness on the target interface as well.
Pitfall 4: Numeric precision loss. Jushuitan amounts are in yuan with two decimals; Kingdee Cloud Xingchen stores fen (cents), which requires ×100. Passing raw strings gets rejected by the target system. Add a numeric conversion function in the Qeasy field mapping to standardize this.
Pitfall 5: Cross-day document attribution. Documents approved the day before but created today get sliced off if you filter by created time. The safe pattern is to set the catch-up window to "last 48 hours" so cross-day documents are not lost.
When This Applies and When It Doesn't
Applies: retail or distribution businesses where the e-commerce front end is on Jushuitan, the supply-chain back end is on Kingdee Cloud Xingchen, with moderate return volumes (hundreds per day per site), and a need to roll out warehouse-by-warehouse or supplier-by-supplier.
Does not apply: very high return volumes (tens of thousands per day) with sub-second consistency requirements; Jushuitan Qimen warehousing scenarios (which use a different interface set); or Kingdee Cloud Xingchen versions other than V2.