WMS Warehouse Master Data Sync: A Single-Strategy Implementation Guide
What This Strategy Solves
Warehouse master data is the foundation of any supply chain integration. In one retail project we worked on, the client ran both a WMS and an ERP, each with its own warehouse records and its own coding rules. The result was familiar: outbound documents could not find a matching warehouse, stock numbers did not reconcile, and month-end reporting meant hours of manual cross-checking.
The WMS Warehouse Query strategy solves exactly one thing: pulling the WMS warehouse master into the integration platform on a schedule, so it can act as a prerequisite for downstream master data such as items, customers, and orders. If warehouses are not aligned, nothing downstream is stable.
Data Flow and Field Mapping
Data flows: WMS (source) → Qeasy Integration Platform (middleware) → ERP (target).
The source API is getWarehouse (POST). It supports filtering by warehouse code list, whether the warehouse supports distribution, and whether it is a special-purpose warehouse. The target API is batchSave. The key field mapping is:
| Business meaning | WMS source field | Type | ERP target field | Type | Notes |
|---|---|---|---|---|---|
| Warehouse code | warehouseCode | string | FNumber | string | Primary key, idempotency anchor |
| Warehouse name | warehouseName | string | FName | string | Required |
| Warehouse ID | warehouseId | int | id (id) | string | Back-reference |
| Warehouse type | warehouseType | string | FStockStatusType | string | Enum mapping |
| Use org | — | — | FUseOrgId | string | Default 100 |
| Create org | — | — | FCreateOrgId | string | Default 100 |
| Description | remark | string | FDescription | string | Optional |
FUseOrgId and FCreateOrgId are required on the target side with a default of "100", but they do not exist on the source. This is a typical "fill-on-target" scenario — the configuration must hardcode these values or pull them from a context org-mapping table.
How to Configure on Qeasy
On the Qeasy Data Integration Platform, the configuration breaks down into three blocks:
1. Source connector. Select the WMS connector, fill in the authentication (redacted), choose the getWarehouse API, pass warehouseCodeList as an array, and configure pagination according to the API spec.
2. Field mapping and cleansing.
- Enable centralised code mapping: explicitly bind the WMS
warehouseCodeto the ERPFNumberand store the mapping in a single table. Every downstream master data strategy can reuse this table, instead of each engineer reinventing their own. - Turn on
idCheck: usewarehouseIdfor idempotency, so repeated pulls do not create duplicates. - Enum fields such as
FStockStatusTypeshould go through a transformation function, not be hardcoded into scripts, so they stay maintainable.
3. Target writer. Select the ERP platform's batchSave. Use constant assignment for FUseOrgId and FCreateOrgId. For basic-data writes that do not depend on the response, turn off "auto-fill response" to improve throughput.
Implementation Steps
Here is how we actually rolled it out in one project:
Phase 1 — Incremental kickoff.
For the first run, do not touch historical data. Only pull warehouse changes since the go-live time. Add an updateTime range to the getWarehouse request and confirm data flows end to end.
Phase 2 — Full-volume trigger.
- On Monday at 2 a.m. (off-peak), manually trigger a full sync using an "ID-segmented" approach to push all historical warehouses into the ERP.
- Immediately after the full run, reconcile counts, statuses, and blank fields on both sides.
Phase 3 — Scheduling.
- Daily schedule is
02 4 * * *(04:02 every morning), pulling the previous day's changes. - Monthly fallback is
23 2 1 1 1(02:23 on the first Monday of each month) for a full-volume backstop, in case the incremental window drops anything. - This is the dual-track (incremental + monthly full) pattern most Qeasy customers use: incremental for freshness, monthly full for consistency.
Phase 4 — Dependency orchestration.
The warehouse strategy is sequence=A, meaning it sits at the top of every downstream master-data flow (customer, vendor, item). Place it at the root of the strategy dependency graph and have downstream strategies reference its strategy ID in depends_on.
Lessons from the Field
1. Missing org fields blew up the first run.
The source does not expose FUseOrgId, but the ERP requires it. The very first full-volume run failed 100% of records. The safe practice is to list all required target fields before configuring, and route anything not present on the source to a constant or context lookup.
2. Code mapping scattered across scripts. In an earlier project, each engineer kept their own mapping rules. Three months later, a handful of warehouses were out of sync and nobody could tell whose rule was authoritative. Since then, every project uses centralised code mapping — changes happen in one place.
3. Time-zone drift caused silent data loss.
Pulling with updateTime > yesterday 00:00 directly missed edge records because of server time-zone differences. The reliable practice is to use last-success-time minus a 5-minute overlap as the lower bound.
4. Unbatched full writes killed ERP transactions.
A single batchSave carrying thousands of warehouses blew past the ERP transaction timeout. The reliable practice is to segment by ID, around 200 records per batch, so failures are retryable.
When to Use and When Not To
Use it for: a single org or a small number of orgs, where WMS warehouse data needs to flow into the ERP; as a prerequisite for downstream master-data sync; warehouse change volume is low (sub-100 per day).
Do not use it for: multi-org or cross-legal-entity warehouses that require approval workflows; sub-minute real-time stock availability (that is an inventory strategy problem); true bidirectional sync between heterogeneous systems (split into two unidirectional strategies instead).