Syncing Sales Orders from Jushuitan to Kingdee Cloud: A Field Guide to One Integration Strategy

What This Strategy Solves

The e-commerce front end runs order review, printing, and shipping in Jushuitan; back-end finance and supply-chain accounting live in Kingdee Cloud. When the two are not connected, you get embarrassing gaps: the warehouse has shipped, but the ERP still shows "to be shipped." Inventory mismatches pile up, costs cannot be settled, and customer service has to fall back on screenshots.

This strategy pulls Confirmed outbound sales orders out of Jushuitan by modification time and creates matching sales-outbound documents in Kingdee Cloud, putting front-end fulfillment and back-end accounting on the same data line.

Data Flow and Field Mapping

The pipeline follows the "source → middleware → target" three-stage pattern, with the Qeasy integration platform sitting in the middle to fetch, transform, and write.

Jushuitan (Source)	Meaning	Kingdee Cloud (Target)	Notes
o_id	Online order id	FBillNo	Idempotency key, used as target bill no.
io_date	Outbound date	FDate	Date type, mind the time zone.
shop_id	Shop code	FSaleOrgId (via lookup)	Resolved through findCollection against an auxiliary table.
lc_id	Logistics company	F_XC_ASSISTANT	Code mapping required.
io_id	Outbound order id	id (returned primary key)	Written back for idempotency checks.
items[].sku_id	SKU	FMaterialID (via mapping)	Codes managed centrally.
items[].qty	Quantity	FQty	Body rows written in batches.
status=Confirmed	Status	—	Only confirmed outbounds are pulled.

The source side only fetches status=Confirmed. The target side uses a fixed bill type DSXSCKD (e-commerce sales outbound). Customers, items, shops, and logistics companies are not mapped inside this strategy. They are resolved at runtime via findCollection lookups against auxiliary tables populated by upstream master-data strategies. This is a common pattern among Qeasy customers: centralize code mappings instead of scattering them across every strategy.

How to Configure It on Qeasy

Source configuration highlights:

API: orders.out.simple.query, POST call.
Pagination: page_index / page_size (max page size is 25 per the spec; setting 100 here is a guardrail).
Incremental window: {{LAST_SYNC_TIME|datetime}} to {{CURRENT_TIME|datetime}}, aligned with the cron schedule.
Set number to io_id, id to o_id, turn on idCheck so duplicates are skipped automatically.
Enable autoFillResponse so body items can be referenced directly when writing the document body.

Target configuration highlights:

API: batchSave, POST.
Bill type FBillTypeID=DSXSCKD, bill no. FBillNo={{o_id}}.
Sales org FSaleOrgId resolved via _findCollection from the auxiliary table against shop_id.
Write the header and body in stages: first batchSave the header to obtain the returned id, then loop the body rows. A failed row can be retried in isolation.

Implementation Steps

Master data first. Customers, items, shops, and logistics companies must be loaded by upstream strategies before this one runs. Do not reinvent the wheel here.
Incremental start point. On first go-live, trigger a full backfill of historical confirmed outbounds, deduplicated by io_id. Then switch to incremental, taking the last successful sync time as the start.
Scheduling cadence. Source cron 10 7-22/3 * * * (every 3 hours, covering 07:00–22:00 — the main outbound window). Target cron 40 7-22/3 * * * (offset by 30 minutes to leave room for fetch + transform + write). The two sides are staggered.
Idempotency and write-back. Use o_id as the idempotency key. After a successful write, push the Kingdee-returned id back into the middleware layer for manual triage and replay.
Monitoring and alerting. Use the Qeasy console to watch cumulative processed count, failure count, and exceptions. Failed orders land in the exception queue for manual handling and re-run.

Pitfalls From the Field

Incremental window must stay within 7 days. The Jushuitan API refuses a modified_begin/modified_end span longer than 7 days. If the scheduler skips a run, the next window is silently truncated and you lose data. The safe move is to alert on missed runs and backfill immediately.
Shop code is not the sales org. The shop id maintained by Jushuitan has no direct equivalent in Kingdee's organization dimension. Passing it raw will be rejected. Always go through findCollection, and keep the mapping table in sync as orgs change.
Writing header and body in one batchSave call is risky. If a single body row fails validation, the whole document rolls back and you only see an opaque error code with no row pointer. Write the header first, then loop the body — failures become row-level and retriable.
Cancelled orders must be filtered out. The source status field carries multiple values by default. If you do not explicitly pass Confirmed, cancelled orders leak through and inflate Kingdee inventory.
Time zone and date format. io_date from Jushuitan is a string. For cross-time-zone customers, normalize to the ERP's time zone before writing FDate, otherwise daily settlement slips by one day.

When to Use It and When Not To

Use it when: the e-commerce front end is Jushuitan and the back-end ERP is Kingdee Cloud, confirmed outbounds need to flow into the ERP as sales-outbound documents on an incremental basis, and volume is in the few-thousand to few-tens-of-thousands per day range. Do not use it for: real-time (sub-second) outbound status sync, multi-book/multi-tenant ERP setups, or orders flowing through Jushuitan's Qimen channel — that is a different strategy.