Material Master Data Sync from ERP to WMS: A Single-Strategy Tutorial
What This Strategy Solves
Material master data is the foundation of supply chain digitization. In one of our warehouse upgrade projects, a retail client needed to sync material/product master data from the ERP into the WMS so that warehouse operations (picking, put-away, stock reservation) could rely on a clean, trusted product master. It sounds simple, but if codes, units, or spec names drift between the two systems, within three months you will see cascading issues: inventory reconciliation gaps, pickers unable to locate goods, and batch attributes that cannot be written back. This strategy's core goal is to ensure each ERP material has exactly one trusted mapping in the WMS, with every change traceable.
Data Flow and Field Mapping
The overall direction is a one-way push: Source (ERP, Material) → Qeasy Integration Platform → Target (WMS, Goods).
| Business Meaning | Source Field (ERP Material) | Target Field (WMS Goods) | Notes |
|---|---|---|---|
| Material Code | material_code | goods_no | Primary key; ERP code recommended as the source of truth |
| Material Name | material_name | goods_name | Display name |
| Specification | spec | spec | Free-text spec |
| Base Unit | unit | unit | Picking unit |
| Goods Type | material_type | goods_type | Enum mapping |
| Active Status | enable_status | is_active | 0/1 or boolean |
A safe pattern we use is centralized code mapping: maintain a single "material code → WMS goods code" reference table in Qeasy, keeping the source code stable and preventing dirty data from flowing back downstream.
Configuring It on the Qeasy Platform
In real client projects, we use the Qeasy Data Integration Platform to host this strategy. The key configuration points are:
- Source connection: Use Qeasy's ERP adapter to pull the material list, with a filter for "not deleted and active" records to keep dirty data out of the downstream pipeline.
- Field mapping: Bind the field-to-field relationships above in Qeasy's mapping canvas. For enum fields like unit and goods type, add a mapping function to convert value domains.
- Target write: Call the WMS goods write API. Qeasy's built-in "batched submission + failure retry" mechanism prevents a single bad record from breaking a large batch.
- Validation rules: Enable "code uniqueness validation" and "required-field validation". Any material with an empty code or empty name is blocked in Qeasy and never reaches the WMS.
Practical tip: Treat the "code mapping" as a global resource in Qeasy so multiple strategies can share one table — when new SKU-related strategies come in later, you do not reinvent the wheel.
Implementation Steps
We recommend splitting the rollout into three phases to avoid overwhelming the target system with a one-shot full load:
- Phase 1: Incremental start. Use "active = true" as a filter and pull deltas every 30 minutes, syncing only newly created or modified materials. This gradually converges the differences between the two systems.
- Phase 2: Full trigger. Once the incremental sync is stable, manually or scheduled trigger a one-time full sync to backfill all historical materials into the WMS, then switch back to incremental mode.
- Phase 3: Lock in the schedule. Material master data does not change very often, so the final cadence can settle on a "delta every 15–30 minutes + nightly full verification" two-track rhythm — another common pattern we have seen across Qeasy customers.
Before going live in each phase, we recommend running a "dry run + diff report" inside Qeasy to confirm the material counts and key fields line up on both sides before switching to the production schedule.
Pitfalls and Lessons Learned
- Unit field overlooked. The classic mistake is syncing only the material code and name and forgetting the base unit. The result is that the WMS has empty units for received goods and picking grinds to a halt. The safe approach is to make the unit field a required validation in Qeasy's mapping.
- Soft-deleted records not filtered. Materials marked as "disabled" in the ERP are pushed to the WMS as-is, allowing discontinued products to still be picked. Add the exclusion to the source query — do not leave it for the downstream to figure out.
- Code case inconsistency. The ERP uses uppercase codes while the WMS stores them in lowercase. Without a normalization function in Qeasy, you end up with duplicate records. This is a typical pitfall — normalize with a mapping function.
- One-shot full sync overloads the WMS. Pushing tens of thousands of materials at once causes cascading API timeouts. Batched submission + failure retry is Qeasy's default behavior, but confirm a reasonable batch size (typically 200–500 records per batch).
- No "disabled" reverse notification. When a material is disabled in the ERP, the WMS goods record is not deactivated in sync, so it still appears during stock counts. A reverse "status change" notification can be added later, but in this single strategy at minimum ensure "disabled materials are not pushed further".
When to Use and When Not to Use
Use when: The ERP is the single source of truth for material master data and the WMS acts purely as an execution system; the material count is within tens of thousands; there are no complex auxiliary attributes (such as multi-SKU or free-combination batch attributes) — typical for retail and distribution. Do not use when: Materials carry multi-dimensional auxiliary attributes, the WMS needs to maintain its own product records, or bidirectional sync is frequent. In those cases, expand the strategy set or split it into multiple strategies.