Practical Tutorial: Syncing Jushuitan After-Sales Rejection Refunds to Kingdee Cloud · Galaxy Flagship Edition
What This Strategy Solves
In multi-channel retail, Jushuitan handles after-sales rejection refunds from stores and e-commerce channels, while Kingdee Cloud · Galaxy Flagship Edition acts as the back-end ERP for finance and inventory accounting. Manual entry between the two easily leads to inconsistent refund statuses, inflated inventory, and mismatched receivables/payables. This strategy incrementally pulls Jushuitan's rejection refund orders into the middleware at scheduled intervals, converts them into Kingdee return bills, and writes them back, closing the "front-end intake → back-end accounting" loop.
Data Flow and Field Mapping
The overall flow is: Jushuitan (WebAPI query) → Qeasy Data Integration Platform → Kingdee Cloud · Galaxy Flagship Edition (RESTful write). In one real project, we split this strategy into three segments: source pull, intermediate transform, and target write. The key field mapping is as follows:
| Business Meaning | Jushuitan Source Field | Middleware Variable | Kingdee Target Field |
|---|---|---|---|
| After-sales order number | as_id (number and primary key) | {{as_id}} | billno |
| Shop/Customer code | shop_id | {{shop_id}} | customer_number |
| Document type | type (rejection refund) | Constant mapping | billtype_number (e.g., im_SalOutBill_STD_BT_S_R) |
| Inventory org | Requires shop mapping | Constant or lookup | org_number |
| Sales org | Requires shop mapping | Constant or lookup | bizorg_number |
| Settlement currency | Default CNY | Constant | settlecurrency_number |
| Modification time window | modified_begin / modified_end | {{LAST_SYNC_TIME}} ~ {{CURRENT_TIME}} | Not mapped directly; used as query condition |
| Document status | status=WaitConfirm, etc. | Enum mapping | Not mapped directly; used as filter |
A few details deserve special attention: SKUs returned by Jushuitan do not match Kingdee's material codes. We usually leverage Qeasy's "centralized encoding mapping management" to maintain a shared mapping table for external SKUs, shop codes, and ERP material numbers across all related strategies, avoiding hardcoded duplicates in every strategy. The header is written first, then line items are split and pushed one by one—a "header-body phased" pattern commonly used at customer sites.
How to Configure on Qeasy
For configuration, select the Jushuitan WebAPI connector on the source side and the Kingdee Cloud · Galaxy Flagship Edition RESTful connector on the target side, with Qeasy's three-layer model "source document—intermediate table—target document" carrying the middle. In the source model, set as_id as the document number and idempotency key, and enable idCheck to prevent duplicate pulls of the same after-sales order.
The incremental fields use modified_begin / modified_end, with time formats as {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}} placeholders—the platform maintains the cursor automatically. Pagination parameters page_index and page_size are set in a fixed loop until an empty page is returned.
On the target side, Jushuitan's as_id is used as billno, and idempotent writes are enabled on Kingdee's side. Customer codes, document types, inventory organizations, and similar fields are brought in through mapping lookups rather than hardcoded business values. This way, when new shops are added or organizations change later, only the mapping table needs updating, not the strategy itself.
Implementation Steps
Phase one is full-volume triggering: during initial project launch, all historical rejection refund orders from Jushuitan within a timeframe are fully pushed to Kingdee to confirm document format, field mapping, and refund amount calculations. Manual triggering with batch-by-batch verification is recommended at this stage.
Phase two is incremental start point switchover: after verification, clean up historical backfill tasks and set the cursor to midnight on the launch date. The source modified_begin then starts fetching from {{LAST_SYNC_TIME}}.
Phase three is scheduling frequency setting: Jushuitan's source crontab is set to 05,35 8-22 * * * (every 30 minutes during business hours); Kingdee's target write crontab is set to 20,50 * * * *, staggered from the source to let the source pull the latest data first while Kingdee handles batched writes, reducing instantaneous pressure on the target system. The "incremental and full-volume dual-track" pattern commonly seen at customer sites is implemented exactly this way—historical data via full-volume, daily operations via incremental.
Pitfall Review
- Time window boundary loss: A typical mistake is having
modified_endtake the system current time directly, but if Jushuitan generates a new order exactly at the boundary, the same second can cause duplicate pulls or missed orders. The safer approach is to leave a 1–2 second buffer for the end time, or simply let the source side deduplicate by document number. - Status enum mismatch: Jushuitan's
WaitConfirm,Confirmed,Finishedstatus names passed directly to Kingdee are unrecognized. We built a three-column enum mapping table: "Jushuitan status—Kingdee receivable status—whether to push," and start troubleshooting from this table. - Shop-to-customer mapping drift: One Jushuitan shop may correspond to multiple customer codes in Kingdee (self-operated, joint operation, platform store). Manual maintenance easily drifts. We recommend versioning the mapping table with an audit trail for every change.
- Rejection refunds mixed with normal returns: If the source interface does not pass
type, it returns both "rejection refunds" and "regular returns" together. We fix thetypeparameter to the rejection refund value to avoid mispush. - Empty inventory organization: Some new shops haven't had organizations set up in Kingdee yet, causing whole-document push failures. The customer-site approach is to route failed documents into Qeasy's "pending completion queue" and manually trigger re-push after the ERP side completes the organization setup, rather than throwing errors that interrupt the entire batch.
Applicable and Non-Applicable Scenarios
Applicable: Multi-channel retail front-ends using Jushuitan for after-sales intake and back-ends using Kingdee Cloud · Galaxy Flagship Edition for finance and inventory accounting, requiring near-real-time sync of rejection refunds to ERP—especially enterprises with many stores, many SKUs, and strict reconciliation timelines.
Not applicable: Small merchants with very few rejection refunds that do not need automated push; or scenarios where source and target encoding systems are fully aligned and entries can be made directly on the Kingdee front-end.