Offline Kingdee Misc Delivery to Jike Cloud Sales Order: A Single-Strategy Integration Tutorial

What This Strategy Solves

In the supply-chain of a retail business, Kingdee Cloud Stellar acts as the ERP backbone while Jike Cloud hosts orders and WMS. Offline, non-standard shipments—samples, gifts, offline-channel deliveries—are recorded in Kingdee as miscellaneous delivery notes (bill type QTCKD06_SYS). Jike Cloud, however, needs a real, shippable sales order with logistics tracking.

We use the Qeasy integration platform to carry this strategy: Kingdee → Jike Cloud, incremental pull by approval date, filtered by bill type and warehouse, producing a Jike Cloud tradeOrder create request. It complements the "sales delivery note → sales order" path and covers all outbound sources, while closing the loop with a later "logistics-number callback" strategy.

Data Flow and Field Mapping

Flow: Kingdee Cloud Stellar (executeBillQuery, QUERY) → Qeasy middleware (group by FBillNo, buildModel constructs header + details) → Jike Cloud (oms.trade.ordercreate, EXECUTE).

Header field mapping:

Source (Kingdee)	Target (Jike Cloud)	Type	Rule	Notes
FBillNo	tradeNo	DIRECT	`{{FBillNo}}`	Sales order number, business key
FBillNo	sellerMemo	DIRECT	`{{FBillNo}}`	Seller memo, required, for P4-211 reverse lookup of Kingdee FID
FDate	consignTime / orderTime	DIRECT	`{{FDate}}`	Document date
FCustId.FNumber	customerCode / shopCode	DIRECT	`{{FCustId.FNumber}}`	Customer code
FSTOCKID.FNumber	warehouseCode	DIRECT	`{{FSTOCKID.FNumber}}`	Ship-from warehouse
F_recipient / F_Receiving_phone_number	receiverName / receiverPhone	DIRECT	direct	Consignee
F_economize / F_market / F_distinguish / F_Shipping_address	receiverProvince / City / District / Address	DIRECT	direct; can be concatenated	Consignee address
FNOTE	remark	DIRECT	`{{FNOTE}}`	Document remark
—	tradeType	CONSTANT	`Offline`	Order type flag
—	source	CONSTANT	`OPEN`	Integration source

Detail goodsDetail fields: FMATERIALID.FNumber → goodsNo, FMaterialID.FBARCODE → barcode, FModel → spec, FQty → sellCount (no FRealQty—use FQty), FSTOCKID.FNumber → warehouseCode (line-level warehouse).

Configuring It on Qeasy

Source pull: form STK_MisDelivery, filter FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' and FBillTypeID.FNUMBER='QTCKD06_SYS' and FSTOCKID.FNumber='RR-FZ1A', paginate with Limit/StartRow/TopRowCount.
Target write: oms.trade.ordercreate. Expand the tradeOrder object to include tradeNo / sellerMemo / warehouseCode / receiverName / goodsDetail. Set goodsDetail.value to details_list to receive the grouped detail array.
Centralised code mapping: keep the three lookup tables—customer, material, warehouse—in Qeasy's mapping centre; Kingdee codes are reused as Jike Cloud codes. This is the most common pattern we see across Qeasy customers.
Scheduling: source 3-59/5 7-22 * * *, target offset by one minute 4-59/5 7-22 * * * to avoid same-second concurrency.

Implementation Steps

Phase 1 — Incremental starting point. For the first backfill, drive a full run anchored on FDate, then switch to FApproveDate-based incremental and persist LAST_SYNC_TIME in Qeasy's run log.

Phase 2 — Full-volume trigger. During warehouse go-live or when adding warehouses, temporarily drop the FSTOCKID.FNumber filter, run a full pull, then restore the single-warehouse filter.

Phase 3 — Steady-state scheduling. Every 5 minutes from 07:00–22:00, nightly pause to reduce load on Kingdee; the morning batch picks up yesterday's backlog before the evening shift.

Phase 4 — Loop verification. Approve a misc delivery in Kingdee → Jike Cloud creates a sales order → WMS ships → P4-211 writes the tracking number back to Kingdee via sellerMemo. Any broken link leaves documents dangling, so every go-live must be checked end-to-end, forward and reverse.

Pitfalls We Have Hit

Empty sellerMemo breaks the logistics callback. This is the most common crash. P4-211 reverse-looks-up the source via sellerMemo, so FBillNo must always be written regardless of business need. Safer: make sellerMemo a required validation in Qeasy.
buildModel: false leaves detail rows ungrouped. Kingdee returns flat rows with header fields repeated. If the target API expects "one header per push", you must enable buildModel or group by FBillNo in a script—otherwise Jike Cloud creates N duplicate orders.
Missing price fields. Misc delivery notes have no FPrice / FAmount on the source. If Jike Cloud requires unit price/amount, supply defaults (0) in a script, or the API rejects the payload.
Hard-coded warehouse RR-FZ1A silently drops new warehouses. This is a frequent site issue. Move the allowed-warehouse list into a Qeasy mapping config so adding a warehouse is a one-line change.
Bill-type confusion. QTCKD06_SYS (misc delivery) and XSCKD09_SYS (offline sales delivery) are two separate strategies. Spell the FilterString out clearly, otherwise gift shipments leak into the sales-delivery channel and finance reconciliation breaks instantly.

When to Use and When Not To

Use when: Kingdee and Jike Cloud coexist; non-standard "misc delivery" traffic must surface in Jike Cloud as shippable sales orders; downstream logistics callbacks need to locate Kingdee FIDs via sellerMemo. Do not use for: pure-online e-commerce orders (route via the sales-delivery strategy), or scenarios where unit price/amount must match the financial ledger exactly (the misc-delivery source has no prices—a separate price-completion strategy is required).