Subcontracting Inbound Order Sync: Practical Configuration from WMS to Kingdee Cosmos
What This Strategy Solves (Scenario and Value)
In a retail enterprise's subcontracting workflow, after outsourced processing is completed, the processor returns finished goods. The warehouse records them as subcontracting inbound orders in the WMS, while finance and cost accounting are settled in the inventory module of the ERP. Both sides need the document — the warehouse uses it for later inventory checks, and finance uses it to consolidate material costs and processing fees. If the two sides don't match, monthly cost roll-ups will show discrepancies between the books and the actual inventory.
This strategy writes the WMS subcontracting inbound order into the ERP's other inbound order structure, with document types and codes translated uniformly by us through the Qeasy data integration platform. It ensures both systems can locate the same business transaction, while centralizing the document transformation rules in the middle layer, avoiding tight coupling between the two systems.
Data Flow and Field Mapping
The source system is the WMS enterprise edition's subcontracting inbound order, and the target system is the ERP's other inbound order. The middle layer is hosted on the Qeasy data integration platform and handles three main tasks: document type unification, code mapping, and field trimming.
Key field mapping (source → middle layer → target):
| Dimension | WMS (Source) | Qeasy Middle Layer | ERP (Target) |
|---|---|---|---|
| Document Type | Subcontracting Inbound Order | Subcontracting Inbound Order | Other Inbound Order (Business Type = Subcontracting Inbound) |
| Document Number | ERP Order Number | Pass-through | Document Number |
| Warehouse | Warehouse Code | Code Mapping Table | Warehouse Code (post-mapping) |
| Material Code | Merchant Code / SKU | Code Mapping Table | Material Code |
| Quantity | Inbound Quantity | Unit unification (base unit) | Actual Received Quantity |
| Unit Price | Subcontracting Unit Price | Tax-inclusive / tax-exclusive conversion | Unit Price |
| Supplier | Processor Code | Supplier Mapping Table | Supplier Code |
| Remarks | Original Remarks | Append source identifier | Remarks |
Note: For business fields like units, tax treatment, and tax rate not explicitly specified in the source material, no specific rules are invented.
How to Configure in Qeasy
The entire configuration follows a three-stage approach: source ingestion, mapping, and target writing.
- Source ingestion: In Qeasy, add the WMS enterprise edition adapter, select "Subcontracting Inbound Order" as the pull object, and drive the pull window by "last modified time".
- Middle-layer mapping: Enter the strategy canvas and orchestrate field mapping nodes. Two often-overlooked details:
- Centralized code mapping. Warehouse codes, material codes, and supplier codes should not be scattered across multiple strategies. Instead, all should point to a unified "Code Mapping Table". We have promoted this practice at multiple customer sites, and cross-strategy reuse improves significantly.
- Header and body in stages. The header goes through basic validation first (document number, warehouse, and supplier cannot be empty), then the body is parsed in batches. This prevents a single line error from causing the entire document to fail.
- Target writing: Connect to the ERP's "Other Inbound Order" save interface, with the business type set to the predefined subcontracting inbound value. Document writing uses a "save first, then approve" two-step approach, avoiding approval blocks that cause incremental backlog.
Implementation Steps
Roll out in three stages, each starting with small-traffic trial runs before scaling.
Stage 1: Align the incremental start point. On the WMS side, lock down a clear time point as the incremental start (e.g., a specific moment at the beginning of the month), to prevent historical data from mixing into the incremental stream. Once this time point is set, don't easily rewind it.
Stage 2: Full data trigger. After start point alignment, run a historical data backfill. Use a batch trigger to pull in batches by document date, with each batch capped at 200–500 documents. Qeasy directly supports loop batch configuration. The goal here is to bring both sides' existing data into alignment first.
Stage 3: Scheduling frequency and monitoring. Once the incremental flow is stable, scheduling frequency is recommended at one round every 5–15 minutes, matching the WMS's outbound rhythm. At the same time, configure two things: failure retry and alerting (Qeasy comes with a built-in monitoring dashboard), and a daily reconciliation job run after business close — a "document-number-level" reconciliation that compares both sides' document number lists and outputs the differences into a troubleshooting table.
The incremental + full data dual-track is a common pattern we've seen Qeasy customers adopt: incremental during normal operations, full data backfill at month start or during anomalies, avoiding overwhelming the downstream with full loads from the outset.
Lessons Learned
- Code mapping not centralized. The same warehouse may be "WH01" in the source system and "001" in the target system. If scattered across multiple strategies, mismatches within 3 months are almost inevitable. The reliable approach is to have all strategies share the same code mapping table.
- Unit conversion overlooked. Subcontracting inbound often involves base units and sales units. The source system's "piece" must be converted to "each" or "kilogram" in the target system. The pitfall here is not the conversion formula itself, but decimal rounding. It's recommended to handle this explicitly in the middle layer rather than relying on the target system's default logic.
- Mismatched approval timing. Once the target system's document is approved, the modification path narrows. If approval is built directly into the sync chain, some erroneous documents get stuck in a semi-approved state, and cleanup costs are high afterward. The reliable approach is "save first, approve later" — approval is triggered only after reconciliation confirms no discrepancies.
- Incremental start point drift. Dev and production environments use different WMS tenants. If the incremental start points aren't aligned, missing or duplicate documents appear. Each environment switch requires re-confirming the start time.
- No reconciliation. A sync scheme without reconciliation is a scheme without acceptance criteria. After every incremental run, two questions must be answerable: "How many documents were pushed today?" and "Do both sides match?"
Applicable and Non-Applicable Scenarios
Applicable: Scenarios where WMS serves as the warehouse and fulfillment system and ERP serves as the main ledger, with stable subcontracting business and clear document structures. Not applicable: Scenarios involving multi-level process decomposition in subcontracting, where the ERP side needs cost reconstruction and labor hour allocation, or where the ERP side needs to use a dedicated subcontracting processing module rather than the "Other Inbound Order" workaround — in such cases, a dedicated strategy is recommended instead of reusing a generic inbound mapping.