Sales Outbound Sync with Freight Order — A Practical Guide (Jushuitan → Kingdee Cloud)
What This Strategy Solves
A retail enterprise runs its e-commerce operations on Jushuitan and keeps financial books in Kingdee Cloud. After the warehouse ships, operations want confirmed sales outbound orders (with freight info) pushed to Kingdee on a steady cadence so invoicing and reconciliation can follow. This single strategy does one thing: incrementally pull Jushuitan confirmed outbound orders, enrich them with freight and tracking data, and write them as sales outbound documents in Kingdee. It sounds simple, but if the source of freight fields is not nailed down, freight totals drift apart within three months and finance ends up reconciling by hand.
Data Flow and Field Mapping (Source → Middle Layer → Target)
Source is Jushuitan; target is Kingdee Cloud. On the Qeasy integration platform, requests and responses pass through a unified middle layer that normalizes source fields into ones the target can accept.
The source call is jushuitan.saleout.list.query, with an incremental window defined by start_time and end_time, filtered to status=Confirmed, keyed by io_id. The target call is batchSave, with document type fixed at XSCKD01_SYS.
Key field mapping (excerpt):
| Meaning | Jushuitan source | Kingdee target | Notes |
|---|---|---|---|
| Document number | io_id | FBillNo | Source ID becomes target doc no. |
| Outbound date | io_date | FDate | Taken from source |
| Customer / shop | shop_id | FCustomerID | Must be registered in code map |
| Sales org | Derived from mapping | FSaleOrgId | Fixed code such as "100" |
| Tracking no. | freight segment | FCarriageNO | Pull from freight block |
| Freight amount | freight segment | amount field | Per Kingdee model |
| Status | status | Trigger condition | Only Confirmed is pushed |
Freight data is nested inside the freight block, not at the top level of the outbound order. This is the classic trap: mapping only top-level fields silently drops freight.
How to Configure on Qeasy
Four practical points when configuring this strategy on Qeasy:
-
Pick
jushuitan.saleout.list.queryas the source API. Setpage_indexdefault 1,page_sizeup to the source's hard limit (50 here). Going over the limit will be silently truncated. -
Use built-in variables
{{LAST_SYNC_TIME|datetime}}and{{CURRENT_TIME|datetime}}for the incremental window. The platform manages the watermark automatically. -
Isolate freight fields in a dedicated branch rather than mixing them into the main script. A common pattern on Qeasy is header/body phased handling: land the main document first, then attach the freight segment.
-
Centralize code mapping. Keep
shop_id→FCustomerIDandFSaleOrgIdmappings in a single map table so other strategies (items, shops) reuse the same definitions instead of drifting.
Implementation Steps (Phased Scheduling)
- Incremental start point: On first go-live, use a small window (e.g., the last 2 hours) as
start_timeto validate the chain. The typical mistake is kicking off with a 7-day backfill — the source pagination and target throttling will saturate. - Full backfill: Run historical data as a one-shot job, time-shifted away from the incremental job to avoid contention.
- Cadence: Source crontab
22 */2 * * *(every 2 hours at minute 22); target write10 0 * * *(00:10 daily). Offset by at least 30 minutes so the target has headroom. - Replay: Keep the last 7 days of watermarks so a missed document can be re-pulled by ID rather than re-running the whole window.
Pitfalls and Lessons Learned
- Time window > 7 days: The source API enforces a 7-day maximum between
start_timeandend_time. A full backfill must be split into chunks. - Freight segment ignored: Freight lives inside the freight block, not at the top level. Map it explicitly.
- Wrong status: Pushing
WaitConfirmmakes the target reject or create empty freight documents. - Duplicate doc numbers:
io_idmust be idempotently written; the target checksFBillNofor duplicates to avoid reruns producing duplicate outbound orders. - Unregistered org/customer codes: Kingdee strictly validates
FSaleOrgIdandFCustomerID. Any code not in the mapping table will fail. Pre-register customers and orgs before go-live.
When It Fits — and When It Doesn't
Fits: Retail and e-commerce businesses already running Jushuitan for warehouse fulfillment that need confirmed outbound orders and freight data pushed to ERP for invoicing and reconciliation. Doesn't fit: Real-time (sub-minute) outbound scenarios, pre-shipment / unconfirmed status flows, and multi-org or multi-book complex distribution chains — the latter should split books before talking sync.