Syncing Sales Outbound Orders from Kingdee Cloud Cosmos to Wangdiantong WMS: A Single-Strategy Deep Dive

What This Strategy Solves

The sales outbound order is the most contentious interface between an ERP and a WMS. On one side, Kingdee Cloud Cosmos generates the standard sales outbound order under financial and business rules; on the other, Wangdiantong WMS needs outbound instructions that fit warehouse execution logic. We worked with a retail client where both sides were technically correct, yet inventory still would not reconcile — the root cause turned out to be inconsistent document type codes and line-item granularity between the two systems.

This strategy has a deliberately narrow scope: treat the sales outbound order in Kingdee Cloud Cosmos as the single source of truth, push both header and line items to Wangdiantong WMS on a 5-minute cadence, and let that be the sole trigger for warehouse picking, shipping, and posting. It does not handle purchase receiving, transfers, or anything else. That is the value of a single-strategy design — clear boundaries, easy troubleshooting, and no entanglement with unrelated logic.

Data Flow and Field Mapping

The flow is unidirectional: Kingdee Cloud Cosmos → Qeasy Data Integration Platform (the middleware layer) → Wangdiantong WMS.

On the source side, the strategy calls Kingdee's executeBillQuery API over POST to pull the sales outbound view. On the target side, it calls WDT_WMS_STOCKOUT_CREATE, also POST, mapping the header into deliveryOrder and the line items into orderLines.

Key field mapping (anonymized for illustration):

idCheck=true and autoFillResponse=true on the source mean Qeasy automatically uses FID and FEntity_FENTRYID for deduplication, and feeds response fields back into the query result so subsequent status checks have something to read.

How to Configure It on Qeasy

We use Qeasy as the carrier, and the configuration has four blocks.

First, source platform attachment. Configure Kingdee Cloud Cosmos credentials, tenant, and account set into the connector. A common practice among Qeasy customers is centralized management of code mappings — keep mappings for organizations, customers, materials, warehouses, and document types in a dedicated mapping table rather than scattering them across strategy scripts. Adding a sales org or changing a document type later means touching one place.

Second, target platform attachment. The Wangdiantong WMS API expects deliveryOrder as an object and orderLines as an array. The Qeasy "object-array" assembler normally reshapes Kingdee's header + lines into that nested structure. The principle here is header and body in stages — land the header first, then the body; if the push fails, first determine whether the header failed or the lines failed, do not mix them in triage.

Third, field mapping and transformation. FBillTypeID.FNumber and its enum siblings are the most common trouble spot. The source document types are XSCKD01_SYS, XSCKD02_SYS, and so on, while the WMS only recognizes its own internal business type codes ("Standard Sales Outbound," "Consignment," "Retail," etc.). This must be mapped explicitly — do not rely on auto-inference.

Fourth, idempotency and logging. Register FID as the source-side unique key and id as the target-side acknowledgement key in the strategy's primary-key log. When the inevitable "we pushed it but the WMS did not receive it" argument arises, trace it by document number through the log chain without digging into either side's API.

Implementation Steps

Phase 1: Connection and liveness check. Use one or two real documents to validate that executeBillQuery returns records for the intended document type, and that WDT_WMS_STOCKOUT_CREATE can place the order successfully. Do not push volume yet.

Phase 2: Incremental start alignment. Pick an explicit starting point (usually 00:00 of a chosen day) and only sync sales outbound orders modified after that point with status "Approved." On the Qeasy side, FDate plus document status is the filter. Only "Approved" orders enter the push queue, otherwise in-flight documents get pushed repeatedly.

Phase 3: One-time full backfill. Once incremental is stable and before opening in production, run a historical full backfill of the last N days via Qeasy's "full task." This must be off-peak from warehouse operations — do not run a full backfill during a promotion outbound peak, or the WMS API queue will back up.

Phase 4: Steady-state scheduling. Source crontab is 0-59/5 * * * * (every 5 minutes, offset 0); target is 2-59/5 * * * * (offset 2). The 2-second stagger avoids the target hammering the moment the source produces. Steady state is pull-and-push every 5 minutes.

Phase 5: Monitoring and alerting. Attach metrics in Qeasy: rows fetched, rows pushed successfully, rows failed, average latency. Alert via enterprise IM when failures cross a threshold.

Lessons from the Field

Pitfall 1: Passing document type codes through as opaque strings. A classic mistake is shoving XSCKD01_SYS straight into the WMS, which does not recognize it and either errors out or — worse — silently routes it to the wrong business type, only surfacing during the next quarterly stocktake. The safe approach is an explicit enum mapping with auditability.

Pitfall 2: Treating only FID as the idempotency key. FEntity_FENTRYID is the line-level unique key on the source. If only FID is used, the same document pushed twice causes line items to be duplicated on the WMS side, doubling quantities. Line-level idempotency is mandatory.

Pitfall 3: Pushing in-flight documents. If the incremental filter only checks FDate and not document status, intermediate in-review documents are pushed repeatedly, with content that changes each time. The safe rule is only push "Approved" status, and trigger on status change.

Pitfall 4: Timezone and date semantic mismatch. Kingdee's FDate is the business date; the WMS often accepts a timestamp. Mixing the two leads to the illusion that "yesterday's documents were pushed today." Converge on passing "business date at 00:00:00" and rendering it in the warehouse's timezone on the WMS side.

Pitfall 5: Running full backfills without staggering. Dumping thousands of historical documents at once onto the WMS API during warehouse operation hours causes interface queuing and PDA picking slowdowns. The safe approach is to split the full task into batches of 200 to 500 documents with inter-batch sleeps.

Where This Applies and Where It Does Not

Applies: single legal entity, single account set, single warehouse or fixed warehouse list; sales outbound document types within the 8 in Kingdee's standard enum; WMS is the sole execution system for outbound operations.

Does not apply: multi-organization or multi-account-set scenarios that require per-entity split routing; outbound scenarios that also involve transfers, cross-org transfers, or VMI; situations where the WMS and ERP need bidirectional reconciliation, reversal, or retransmission — those require multiple cooperating strategies, not one.