Supply Chain Integration Solution: WMS and Kingdee Cloud

Scenario and Value

In typical retail or manufacturing enterprises, the ERP system handles procurement, sales, inventory accounting, and financial postings, while the WMS handles physical warehouse operations and document confirmation. When the two systems are not integrated at the platform level, the same business event tends to be executed twice: a purchase receipt is approved in the ERP but the WMS side never triggers the physical put-away; a sales outbound shipment is completed in the WMS but the ERP-side inventory and receivables are not updated in time; new or modified items sit in the ERP while the WMS item master lags behind, causing scanning, inbound, and outbound failures.

This solution targets the pain points above and designs an end-to-end integration covering five business domains: procurement, sales, inventory, master data, and returns, totaling 22 strategies. Rather than trying to cover every edge case, the solution clarifies the most common ERP↔WMS document flows and, through explicit execution dependencies and phased scheduling, brings both sides into alignment within a reasonable time window, reducing manual ticket handling and reconciliation cost.

Integration Architecture and Data Flow

The architecture treats Kingdee Cloud as the source of ERP master data and business documents, and WMS as the execution side for warehouse operations and physical confirmations. The integration platform acts as the middle channel, responsible for document retrieval, field mapping, write-in, and status callbacks.

Kingdee Cloud (ERP)
   │  Items / purchase receipt / sales outbound / inventory adjustments / transfers / assembly & disassembly / returns
   ▼
Integration Platform (strategy scheduling)
   │  Inbound confirmation / purchase return confirmation / item master
   ▼
WMS

In terms of flow direction, 18 strategies run from Kingdee to WMS, pushing ERP business instructions to the warehouse side for execution; 2 strategies run from WMS to Kingdee, writing the physical confirmation results back to the ERP to form a closed loop; 1 internal operation alerting strategy and 1 query-only strategy do not participate in bidirectional writes.

Interface List

By business module, the source/target platforms, data objects, and synchronization directions covered by this solution are:

Implementation Points

1. Master data first. All inbound and outbound strategies depend on the existence of item masters in the WMS. If master data is not synchronized first, downstream inbound, outbound, and transfer operations will fail in the WMS due to missing items. Therefore strategy H (Kingdee item → WMS goods master) must be executed first, and it is recommended to run at high frequency during business hours (hourly between 8 and 22) to quickly reflect new or modified items from the ERP.

2. Document status filtering. All strategies uniformly synchronize only approved documents, using the filter FDocumentStatus = 'C', to avoid pushing draft or rejected documents to the WMS and causing incorrect operations.

3. Incremental time window. Most strategies adopt a 3-hour incremental condition FApproveDate >= '{{HOURE_AGO_3|datetime}}', balancing data timeliness with reduced pressure on the source system. The window length can be adjusted according to the enterprise's document volume.

4. Warehouse scope containment. The solution constrains WMS-managed warehouses to CK009, CK010, CK011. All related strategies' filters must include FStockID.FNumber in (...) to prevent documents from other warehouses from interfering with inbound and outbound logic.

5. Closed-loop writeback control. Both the procurement and return business chains follow a three-stage "dispatch – execute – writeback" pattern: Kingdee purchase receipt notice pushes the WMS inbound document → WMS inbound confirmation → Kingdee purchase receipt; Kingdee material return application pushes the WMS purchase return → WMS purchase return confirmation → Kingdee purchase return document. Writeback strategies depend on the completion of preceding strategies and must be scheduled serially.

Best Practices

Phased scheduling. It is recommended to split the 22 strategies into 5 rounds based on dependencies: Round 1 runs item master (hourly); Round 2 runs purchase receipt push, inbound confirmation writeback, assembly and disassembly inbound (every 5–10 minutes); Round 3 runs sales outbound, sales return, delivery notice (every 5 minutes); Round 4 runs inventory and transfers (every 10 minutes); Round 5 runs material return and purchase return confirmation (every 5 minutes). High-frequency rounds handle order flow while low-frequency rounds handle master data, balancing real-time performance with system load.

Exception handling and alerting. The DingTalk ops bot strategy is responsible for pushing failure details to the operations group. Failure causes should at least cover four categories: source system connection timeout, missing field mapping, target system validation failure, and document status mismatch, so that frontline operations can locate issues quickly.

Layered field mapping management. Data objects such as the material return application involve more than 20 fields including FID, FEntity_FEntryID, FBillNo, supplier code, and purchasing organization. It is recommended to configure mappings in layers on the integration platform: basic fields (primary key, document number, status) in the first layer, business fields (supplier, organization, department) in the second layer, and extension fields (remarks, return reason, confirmation status) in the third layer, to facilitate future extension and auditing.

Phased rollout. Master data and inventory strategies can be launched first, while sales and return strategies are recommended for a phased rollout: first run the full chain on a single warehouse and verify document consistency on both sides before expanding to all target warehouses, reducing rollout risk.