Qeasy Cloud
Get Started

Sales Outbound Sync with Freight Order — A Practical Guide (Jushuitan → Kingdee Cloud)

· 谢锴斌· Integration Solutions· 19 views· 3 min read
JushuitanKingdee Cloud销售出库单同步运费单Incremental Sync供应链集成

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):

MeaningJushuitan sourceKingdee targetNotes
Document numberio_idFBillNoSource ID becomes target doc no.
Outbound dateio_dateFDateTaken from source
Customer / shopshop_idFCustomerIDMust be registered in code map
Sales orgDerived from mappingFSaleOrgIdFixed code such as "100"
Tracking no.freight segmentFCarriageNOPull from freight block
Freight amountfreight segmentamount fieldPer Kingdee model
StatusstatusTrigger conditionOnly 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:

  1. Pick jushuitan.saleout.list.query as the source API. Set page_index default 1, page_size up to the source's hard limit (50 here). Going over the limit will be silently truncated.

  2. Use built-in variables {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}} for the incremental window. The platform manages the watermark automatically.

  3. 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.

  4. Centralize code mapping. Keep shop_id → FCustomerID and FSaleOrgId mappings in a single map table so other strategies (items, shops) reuse the same definitions instead of drifting.

Implementation Steps (Phased Scheduling)

  1. Incremental start point: On first go-live, use a small window (e.g., the last 2 hours) as start_time to validate the chain. The typical mistake is kicking off with a 7-day backfill — the source pagination and target throttling will saturate.
  2. Full backfill: Run historical data as a one-shot job, time-shifted away from the incremental job to avoid contention.
  3. Cadence: Source crontab 22 */2 * * * (every 2 hours at minute 22); target write 10 0 * * * (00:10 daily). Offset by at least 30 minutes so the target has headroom.
  4. 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_time and end_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 WaitConfirm makes the target reject or create empty freight documents.
  • Duplicate doc numbers: io_id must be idempotently written; the target checks FBillNo for duplicates to avoid reruns producing duplicate outbound orders.
  • Unregistered org/customer codes: Kingdee strictly validates FSaleOrgId and FCustomerID. 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.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/strat-jushuitan-kingdee-cloud-4431-nb6bb4eab-8130f638

Comments