Overview of Supply Chain Integration between WMS and Kingdee Cloud · Galaxy Flagship Edition

Scenario and Value

After each e-commerce promotion season, the finance team at one food-technology enterprise typically discovered, only three days after the holiday, that there were over a thousand line-level discrepancies between procurement receipts and sales shipments across the ERP and OMS. The root cause was not ERP replication itself, but the absence of an automated closed loop between OMS and ERP: when a Kingdee receipt notice was issued down to the OMS-side platform and the procurement receipt was completed, what flowed back into Kingdee was a different inbound document. Sales shipments on the OMS side translated into a sales order plus a sales outbound document on the ERP side, and any break in this chain forced manual reconciliation at month-end.

What we observed at one real customer site is the typical pattern: the OMS owns orders and fulfillment, while the ERP owns procurement, inventory accounting, and subcontracting settlement. Both systems maintain complete inventory ledgers, but only when data flows back and forth along the business chain in an automated manner can the book-versus-physical inventory be aligned within T+1. This solution targets exactly that pain point, treating Kingdee Cloud · Galaxy Flagship Edition as the supply chain master-data and accounting hub, and the OMS-side platform as the order and fulfillment hub. Through 46 strategies spanning master data, procurement, sales, inventory, transfers, subcontracting, and system maintenance, the document loop is closed end-to-end.

Integration Architecture and Data Flow

The architecture is ERP-centric with the OMS in a supporting role. Master data flows first, then business documents move in a single direction per scenario.

                      Kingdee Cloud · Galaxy Flagship Edition (ERP)
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
   Item/Vendor           Receipt/Subcontract       Shipment/Transfer Requisition
   Shelf-life Lookup     PO Issuance               Original Order/Transfer
        │                     │                     │
        └─────────────────────┼─────────────────────┘
                              │
                              ▼
                          OMS Platform
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
   PO Receipt/Subcontract  PO Return/Subcontract    Other In/Out
   Transfer Out/In          Sales Shipment/SO       Stepwise Transfer Out/In
        │                     │                     │
        └─────────────────────┴─────────────────────┘
                              │
                              ▼
                      Kingdee Cloud · Galaxy Flagship Edition (ERP)

The data flow breaks down into three phases:

1. Master data downstream: Item, vendor, and shelf-life lookup data flow from ERP down to OMS. This phase must execute first, since all subsequent business documents depend on code mapping.
2. Business document downstream: ERP receipt notices and subcontract receipts issue POs on the OMS side; ERP shipment notices produce original orders on the OMS side (offline scenario); ERP transfer requisitions generate OMS-side transfer documents.
3. Business document return: OMS-side PO receipts feed back into ERP as PO receipts or subcontract completion receipts; sales shipments return to ERP as both sales orders and sales shipments; transfer in/out flows back as stepwise transfer in/out documents; other in/out, PO returns, and subcontract returns flow back by type.

We use the Qeasy Data Integration Platform as the implementation carrier. Through visual strategy orchestration, the three phases above are mounted onto a unified scheduler, so that additional strategies can later be appended from the console without touching the underlying code.

Interface List

Implementation Highlights

Phased scheduling: Master data (strategies 1 and 2) runs first on a 2-hour cycle. High-frequency business documents such as receipt notices, subcontract receipts, transfer requisitions, and sales orders run on a 10-minute cycle. Stocktake, movement, and other in/out run every 15 minutes. Shelf-life lookup and query-only strategies fire on demand. Error notifications are event-triggered. Log cleanup executes daily at 02:00.

Incremental fields and full-volume fallback: On the ERP side, FApproveDate and FModifyDate serve as the time window; a 3-hour window is recommended. On the OMS side, createTime, modifyTime, and operateTime are used. Full-volume pulls are allowed during initialization, but should avoid peak business hours.

Centralized code mapping: Item FNumber ↔ OMS sku_code, vendor FNumber ↔ supplier_code, warehouse FStockId.FNumber ↔ warehouse_code, customer FCustomerId.FNumber ↔ customer_code are maintained in a unified mapping table. Changes are made in one place, without editing individual strategies.

Document status filtering: Only approved or confirmed documents are synchronized. On the ERP side, FDocumentStatus='C' is used; on the OMS side, filtering follows the API status-code convention. Drafts and voided documents are not pushed downstream.

Exception retry and alerting: Write failures enter the retry queue; once the threshold is exceeded, an error notification (strategy 45) is pushed. Queue and log records are retained for one month and cleaned up automatically upon expiration.

Privacy and security: Customer names, phone numbers, addresses, company names, API keys, and other sensitive information are not embedded in the solution document. Credentials are injected uniformly through environment variables or a key management service.

Best Practices and Pitfall Retrospective

1. Do not run master data in parallel with business chains: Many projects start by scheduling items, vendors, procurement, and sales concurrently, only to have downstream documents repeatedly rejected due to missing code mappings. The safe approach is to run items and vendors through the first round, verify the mapping table, and then open up the business chain.
2. Write header and body in separate phases: Kingdee documents typically require the header to be written before the body; when a strategy submits both at once, dirty data with the header saved but the body missing often appears. The recommended approach is to push the body only after the header is committed, and roll back the header on failure.
3. Separate offline and online sales into dual channels: The offline scenario flows "ERP shipment notice → OMS original order", while the online scenario flows "OMS sales shipment → ERP sales order / sales shipment". Keeping the two channels separate at the strategy level prevents mutual interference.
4. Decouple subcontracting from ordinary procurement: Subcontract receipts and ordinary receipt notices both map down to OMS-side POs, but the document-type fields differ. Subcontract returns flow back as subcontract completion return documents and must not be mixed with ordinary PO returns. In the Qeasy Data Integration Platform, business-type fields are normally used as conditional branches to route the two chains to different downstream templates.
5. Do not rely solely on document counts for daily reconciliation: Post-holiday variances are rarely missing documents; they usually come from status fields not being written back promptly. A recommended practice is to add a daily "query only" pass (strategies 29, 43, 44) for consistency comparison, and queue discrepant documents for next-day supplement.

When to Use Qeasy

When a project involves supply chain collaboration across multiple ERPs, OMS, and WMS systems, with dozens of strategies requiring per-domain phased scheduling, the Qeasy Data Integration Platform unifies code mapping, incremental time windows, exception retry, and message alerting in a visual console. Additional strategies can be added without touching underlying code, making the operations cost noticeably lower than building a custom ETL.