Delivery Notice to Jushuitan Order Sync: A Single-Strategy Walkthrough
What This Strategy Solves
A retail enterprise runs its e-commerce on Jushuitan while financial and supply chain master data live in Kingdee Cloud. Once the warehouse ships, a delivery notice is created in Kingdee Cloud, and the online order number, date, recipient and other key fields must be pushed back to Jushuitan as the pre-shipment status change. If this link breaks, Jushuitan stays at "WAIT_SELLER_SEND_GOODS" and customer service, buyers, and logistics queries all suffer. This single strategy handles only the delivery notice push — no inventory, no reconciliation. Clear boundaries make it stable.
Data Flow and Field Mapping
The source is Kingdee Cloud, using executeBillQuery to query delivery notices (FBillNo as bill number, FEntity_FEntryID as entry ID, FDate as bill date, FORDERNO as sales order number). The middle layer is the Qeasy integration platform (轻易云集成平台) for field cleansing and mapping. The target is Jushuitan's jushuitan.orders.upload endpoint, which writes the pre-shipment status as an online order.
| Business Meaning | Kingdee Cloud (Source) | Jushuitan (Target) | Notes |
|---|---|---|---|
| Bill Number | FBillNo | so_id | length ≤ 50 |
| Bill Date | FDate | order_date | yyyy-MM-dd |
| Pre-shipment Status | (derived) | shop_status | hard-coded WAIT_SELLER_SEND_GOODS |
| Shop ID | (constant) | shop_id | configured as constant on target |
| Sales Order No. | FORDERNO | (pass-through / log) | used for reconciliation |
After the header passes through, the entry-level details are pulled in a second phase using FEntity_FEntryID, with receiver state, receiver and other fields mapped again. A typical mistake is stuffing header and entries into one request. The safe approach is staged: header lands first, then entries are appended; failures can retry a single segment.
How to Configure in Qeasy
Configure a QUERY-type source, API executeBillQuery, method POST, with FBillNo as number and FEntity_FEntryID as id. Enable idCheck to avoid duplicate fetches. Configure an EXECUTE-type target, API jushuitan.orders.upload. In the request body, so_id uses template syntax like {{FBillNo}} to pick up source fields directly. shop_status is a constant WAIT_SELLER_SEND_GOODS, because a delivery notice triggers exactly this pre-shipment status change.
Two patterns Qeasy customers commonly use: first, centralize tenant-level constants like shop_id in a single mapping table rather than scattering them across strategies; second, run header and entries as two serial strategies so that a header failure does not roll back entries — debugging becomes much faster.
Implementation Steps
Progress in three phases to stay safe:
- Incremental starting point: On first launch, only fetch data from yesterday onward, using
FDate >= yesterdayas the pull start. This phase verifies the link works, not historical completeness. - Full backfill trigger: During off-peak hours, run a one-time historical backfill, batched by
FDatein 500–1000 record chunks. After completion, reconcile Jushuitan order counts against Kingdee delivery notice counts. - Scheduling frequency: Source runs every 15 minutes (
1-59/15 7-23 * * *); target runs every 6 minutes (*/6 7-23 * * *). Source is slower, target is faster — this drains any backlog promptly. Qeasy makes the "incremental and full dual-track" pattern easy: full backfill is manually triggered only when needed, while daily operation runs incremental.
Pitfall Retrospective
- Wrong shop_status value. Jushuitan only accepts matching enums. It must be
WAIT_SELLER_SEND_GOODS; Chinese text or wrong casing gets rejected. - so_id exceeds length 50. Kingdee bill numbers may carry prefixes that push length over the limit. A safe approach is to add
SUBSTR({{FBillNo}}, -50)in the mapping. - Entries stuffed with header. One request containing both receiver state and receiver means any missing field kills the whole order. Staged processing means an entry failure won't affect the header.
- idCheck not enabled. Duplicate requests cause idempotency errors on Jushuitan — not dirty data, but logs go red and become hard to read.
Suitable and Unsuitable Scenarios
Suitable: e-commerce retail where Kingdee Cloud acts as ERP and Jushuitan as the shop middleware, needing real-time delivery notice status push-back. Unsuitable: small sellers who ship directly inside Jushuitan and don't need an ERP, and scenarios that require bidirectional inventory or payment reconciliation — those need at least two additional strategies working together; a single delivery notice push cannot bear that load.