WMS Delivered Status Writeback to Kingdee Cloud: Single-Strategy Tutorial

What This Strategy Solves

After WMS completes a sales outbound shipment, the ERP-side sales outbound order has no native awareness of it — finance, customer service, and planning still see "not shipped." This strategy writes the delivered fact from WMS back to the header of the Kingdee Cloud sales outbound order, aligning ERP and WMS statuses. It is a critical link in closing the sales-order loop.

Data Flow and Field Mapping

Data flow: MySQL (WMS view v_delivered_order) → Qeasy (Qingyiyun Data Integration Platform) → Kingdee Cloud (business object SAL_OUTSTOCK). This strategy operates at the header level only and does not touch outbound entries.

Key field mapping table:

The source SQL already filters by business type: outType in ('1','2','9','12'), and pulls incrementally by realTime >= :realTime, which keeps unrelated outbound types and historical data out of the pipeline.

How to Configure on Qeasy

1. Source side (MySQL): select MySQL as the platform, choose the select API (POST with custom SQL). Put the main SQL in otherRequest, and use :realTime, :limit, :offset as the three placeholders driven by the scheduler. Set both number and id to outOrderNo, and enable idCheck for idempotency.
2. Target side (Kingdee Cloud): select Kingdee.Cloud, choose the batchSave API. Configure the four request fields per the table above using {{field_name}} for direct pass-through, and write the constant "1" for the delivery status.
3. otherRequest (control parameters, required): FormId=SAL_OUTSTOCK, Operation=BatchSave, NeedUpDateFields=F_DPs_FHstate,F_WMS_OrderNo, IsDeleteEntry=false, IsUserModelInit=true, IsAutoSubmitAndAudit=false. These parameters are what make "update only, do not delete entries, do not lock, do not auto-audit" work — they are the key to a successful partial update.
4. Centralized code mapping: Keep the userDef1 → FID mapping in Qeasy's mapping configuration rather than scattering it across scripts, so future full-sync strategies for sales orders can reuse the same mapping table.

Implementation Steps

1. Incremental starting point: set the source schedule to 1-59/10 * * * * (every 10 minutes). For the first run, set :realTime to the historical minimum timestamp to perform a full historical writeback, then switch to rolling incremental on realTime.
2. Stagger the target: set the target schedule to 3-59/15 * * * * (every 15 minutes), starting 2 minutes after the source and with a wider interval. This avoids the dirty-read window where the source is still writing while the target is updating.
3. Trigger and frequency: the source runs on realTime increment, the target is triggered by batch number; once stable, keep the 10/15-minute dual cadence.
4. Go-live in three steps: verify in a test ledger → stress-test with sandbox production data → cut over to the formal ledger. Keep a rollback switch.

Pitfalls and Lessons Learned

1. Missing NeedUpDateFields: a typical mistake is to fill in the request business fields but forget to declare NeedUpDateFields in otherRequest. As a result, Kingdee treats it as a full-field check and wipes the entries. The safe pattern: split header and entry updates into stages; for any "update only a few fields" writeback, always declare the updatable fields explicitly.
2. Ignoring IsUserModelInit=true: forgetting this flag causes batchSave to fail under network control, and the document appears unchanged.
3. userDef1 not back-filled: when the sales outbound order is first synced from Kingdee to WMS, FID must be written into WMS's userDef1. Otherwise, during writeback there is no primary key to locate by, and the system falls back to fuzzy matching on FBillNo, dramatically increasing mis-routing.
4. Missing outType filter: without outType in ('1','2','9','12'), transfer orders and other outbound types will also be written back, triggering complaints from business owners.
5. Same-minute concurrent updates: if the source's 10-minute tick and target's 15-minute tick align within the same minute, the same document may be updated twice in the concurrency window. A 2-minute offset is the simplest way to avoid this.

When to Use and When Not to Use

Use for: WMS→ERP status/marker writebacks, marking sales outbound headers as delivered, writing back WMS shipment numbers, partial updates that must preserve original entries. Not for: writebacks that change detail quantities or amounts (must go through a new-document or full-update flow), cross-organization complex approval workflows, or scenarios that need to trigger Kingdee workflow engines (in those cases use submit + audit rather than batchSave).