Material Master Data Sync in Practice: A Complete Guide from a Retail Platform to an ERP

What This Strategy Solves

Material master data is the root of every downstream document: without it, purchase receipts, sales deliveries, and live inventory simply cannot align. In a real project with a retail enterprise, we saw exactly this — one front-end business system holding the source of truth, an ERP on the back end, and material codes, names, specs, units maintained separately on both sides. Three months later, the numbers did not match, month-end closing stalled, and warehouse picking ran on tribal knowledge.

This strategy pushes material master data unidirectionally from the source system to the target system and keeps it consistent over the long term. Once landed on the Qeasy data integration platform, code mappings are managed centrally, new/updated records flow incrementally while the first onboarding triggers a full initial sync — a dual-track pattern many Qeasy customers adopt — and the business no longer has to type the same data twice.

Data Flow and Field Mapping

The overall flow is source system → Qeasy middleware layer → target system. The middleware layer owns field conversion, code mapping, cleansing, and deduplication.

Key field mapping (typical items; actual fields depend on the source and target metadata):

A few common moves are worth calling out: the source usually has a multi-level category while the target often expects a flat inventory category, so the mapping happens in the middleware; multiple barcodes need an explicit retention rule; disabled materials are best synchronized by status rather than physically deleted.

How to Configure It on Qeasy

On the Qeasy data integration platform, this strategy typically lives as an independent "material master" integration scenario: a source collector paired with a target writer, chained through a mapping and transformation node.

Typical configuration points:

1. Source collection: Use "last modified time" as the incremental cursor. Before the first run, perform a full baseline extraction into a snapshot table in the middleware.
2. Centralized code mapping: Put the "product code ↔ material code" mapping into a central mapping table rather than scattering it across scripts. This is one of the common patterns Qeasy customers adopt — it pays off every time the integration needs to scale or switch partners.
3. Field mapping and unit conversion: Write mapping rules in the transformation node; normalize everything to the base unit before pushing downstream.
4. Target write: The target usually exposes a material-save API. Existence check by code — new codes go through create, existing ones through update.
5. Failure retry and alerting: A single failed record should not fail the whole batch. Retry up to three times, then move to a dead-letter queue and trigger an enterprise IM or email alert.

Implementation Steps

On customer sites we usually split this into three phases, keeping incremental start point, full sync trigger, and scheduling frequency as separate configuration concerns.

Phase 1: Full initialization Export all materials from the source into a temporary table in the middleware. Diff against the target's existing materials and produce three lists: new, updated, disabled. Spot-check the samples manually, then bulk write to the target. This step is the baseline — if it is wrong, everything downstream is wrong.

Phase 2: Anchor the incremental cursor Use the combination of "last modified time + material code" as the incremental cursor, so concurrent edits on the same material are not lost. Store the cursor value in Qeasy's scheduling state table; each batch automatically picks up the previous max timestamp.

Phase 3: Scheduling frequency Material changes are typically infrequent, but cross-department entry does happen occasionally. The recommendation is an incremental run every 30 minutes, plus a fallback full diff around 2:00 a.m. to compensate for anything missed during the day. Another common Qeasy customer pattern is exactly this "incremental + full dual-track" approach — that nightly fallback really matters.

Lessons Learned

Here are a few things that burned us in real projects — all earned the hard way.

1. Codes not centralized. Burying the mapping inside scripts means rewriting the whole chain three months later when the partner changes. The safer move is a central mapping table; Qeasy provides a dedicated mapping management view for exactly this case.
2. Unit conversion missed. A single product has different units across stores, the target side never normalizes, and inventory goes haywire. Always converge to the base unit first.
3. Barcodes overwritten. A product has three barcodes at source, the target API only accepts the primary one, the others vanish, and the business only notices when they come knocking. Define a "primary + secondary" write policy in the transformation node up front.
4. Disabled materials treated as new. Source disables a material and changes its code; the target treats it as a new code, and the old code becomes an orphan with leftover stock. Sync the status field, and agree that a disable signal on the source triggers a disable on the target.
5. Concurrent edits lose updates. Both sides edit the same material; the source wins on time but the target keeps the old value. Bring in a "last modified time" comparison — skip if the target is newer — or force the source to win with an audit log written before the overwrite.

When This Applies — and When It Does Not

Applies: Source owns master data, target is read-only consumer; material count in the tens of thousands, change frequency medium to low; retail or trading enterprises that need long-term cross-system consistency.

Does not apply: Both sides need bidirectional maintenance (collision-prone); millions of materials with high-frequency change (use a dedicated MDM platform instead of a sync channel); the target requires sub-second real-time consistency (sync links inherently run on a minute-level cadence).