Sales Outbound Order Sync in Practice: Kingdee Cloud to Xiaomifeng WMS

What This Strategy Solves

In a typical manufacturing company, sales orders and shipping instructions run in the ERP, while physical outbound operations happen in the WMS. Both sides have outbound documents, but they originate differently—the ERP holds the business-side shipping voucher, and the WMS holds the physical-side execution voucher.

A common real-world scenario: once the sales coordinator finishes shipment registration in the ERP, the warehouse has no idea what to pick, in what order, or for whom. After the warehouse finishes picking, someone has to manually fill the outbound confirmation back into the ERP so that inventory and receivables can move forward.

This strategy does exactly one thing: it takes the sales outbound order from the ERP as the driver, pushes outbound instructions to the WMS on a defined schedule, and the WMS feeds back execution results. The middleware is handled by the Qeasy Data Integration Platform, where scheduling, field mapping, and idempotency checks are all configured.

Data Flow and Field Mapping

Data flow: Kingdee Cloud (Sales Outbound Order) → Qeasy Middle Layer → Xiaomifeng WMS (Offline Outbound Order).

The source side queries sales outbound orders through the ERP's executeBillQuery interface, and the target side writes offline outbound orders through the WMS's /outOrders/v4_1 interface. Key field mapping is as follows:

A common practice among Qeasy customers is to extract code mappings (customer, organization, warehouse, material) into a separate mapping table and maintain them independently. This way, when the business system adjusts fields, only the mapping table changes, not the main pipeline.

How to Configure on Qeasy

Step 1: Build data source connections. Register both the ERP and the WMS as data sources on the Qeasy Data Integration Platform. For private deployment environments, fill in internal network addresses and use key托管 for credentials. Do not hardcode credentials in the strategy.

Step 2: Configure the source query. On the ERP side, use executeBillQuery to filter sales outbound orders by document type, and check fields like FBillNo, FDate, FSaleOrgId_FNumber, FCustomerID_FNumber, FBranchId_FNumber. In the header filter conditions, it is recommended to add FDocumentStatus='A' (approved) to avoid pushing draft documents downstream.

Step 3: Configure target write. The WMS interface is /outOrders/v4_1, POST write. Header fields (outOrderNo, houseCode, shipperCode, etc.) are mapped directly, and the body line items go through Qeasy's body parser.

Step 4: Configure mappings and scripts. For code mapping, use Qeasy's lookup table component to map the ERP's FSaleOrgId_FNumber to the WMS's shipperCode. The relationship key between header and body is FBillNo ↔ outOrderNo.

Step 5: Enable idempotency. The WMS's outOrderNo is set with a unique constraint, so reruns do not create duplicate orders. In the Qeasy strategy, turn on idCheck, and orders with write failures go into the retry queue.

Implementation Steps

Phase 1: Full historical backfill. During initial go-live, do a one-time full backfill of historical data. Query all approved sales outbound orders from the ERP for the past N months, and push them to the WMS in FBillNo ascending order. This step lays the foundation; configure a manually triggered full task in Qeasy, no scheduling needed.

Phase 2: Incremental starting point. After the full backfill, record the last FBillNo or last modification time as the incremental starting point. The Qeasy incremental strategy picks up new orders from this point forward.

Phase 3: Dual-track operation. After go-live, it is recommended to keep dual-track running for 1-2 weeks. Qeasy runs the new pipeline while the old pipeline (if any) keeps running. Reconcile daily—FBillNo matches, quantities match, status match on both sides. Investigate differences immediately.

Phase 4: Cutover and scheduled execution. Once dual-track is stable, switch to the new pipeline as the only channel. The recommended schedule is 0-59/5 * * * * (source) and 3-59/5 * * * * (target, offset), running every 5 minutes. The source side runs on the minute, and the target side offsets by 3 minutes, avoiding both sides抢占 resources at the same moment.

Lessons Learned

1. Draft documents got pushed downstream. Without the FDocumentStatus='A' filter, unapproved sales outbound orders were pushed to the WMS. The warehouse finished picking, but the ERP rejected the approval, leaving both sides in inconsistent states. The safe approach: hard-lock the approved status in the source query filter.

2. Code mappings scattered across strategies. Customer code and organization code mappings were written directly in field conversion scripts. When the business system adjusted the organizational structure, all twenty strategies had to be modified. The typical mistake is treating mappings as fields. The correct approach is to use Qeasy's mapping table component for centralized maintenance, with strategies only referencing rather than hardcoding.

3. Pushing header and body together causes rollback difficulty. The header was successfully pushed to the WMS, but a certain line in the body failed validation, causing the entire order to roll back, while the warehouse had already seen a half-order. A common response pattern is phased handling: first push the header to occupy a slot, then asynchronously push the body lines, and finally do a complete validation.

4. Schedule collision caused order loss. Both the source and target sides were set to 0-59/5, running in the same minute window. Orders entered the source queue while the target side had not finished processing the previous batch, causing backlog. It is recommended to offset the target side by a few minutes for staggered execution.

5. Wrong idempotency key used. Using FEntity_FENTRYID as the idempotency key resulted in the header changing but the line items not changing, causing the WMS to duplicate lines. The idempotency key must be the business primary key FBillNo, not the entry ID.

Applicable and Non-Applicable Scenarios

Applicable: Two separate systems where sales orders and warehouse execution are decoupled; ERP handles business documents while WMS handles physical execution; both have standard interfaces; near-real-time sync required; high reconciliation requirements in retail or manufacturing companies.

Not applicable: Business and physical warehouse are in the same system (just use internal system functions); WMS has no outOrders-style outbound interface and only supports Excel import; or the business side tolerates high latency (hourly level), making 5-minute scheduling unnecessary.