Material Master Data from ERP to CRM: A Hands-On Breakdown of an Incremental Sync Strategy

What This Strategy Solves

Pushing material master data from an ERP to a CRM looks like the most basic kind of master data sync. But in one real project, three months after go-live, the two sides stopped matching — dozens of obsolete items that had been disabled in the ERP were still alive in the CRM, and salespeople were quoting wrong model numbers to customers.

The core value of this strategy is one sentence: use a time-windowed incremental push to keep ERP material changes flowing into the CRM on a steady cadence, so that critical fields like code, name, and model stay aligned long-term, and disable/modify actions flow back promptly.

Data Flow and Field Mapping

The overall flow is unidirectional: source system (KIS Private Cloud material) → Qeasy integration platform → target system (OKKI CRM product).

The source side pulls changes through a RESTful query interface by time window. The platform maps, cleanses, and deduplicates the data, then calls the target's execute interface to write it. Below are the core fields we focused on in this project:

One thing worth highlighting: centralized code mapping management is one of the most common patterns used by Qeasy customers. The correspondence between every KIS code and OKKI product ID lives in the platform's mapping table, so no matter who changes what on either side, things stay consistent.

How to Configure in Qeasy

When we built this on Qeasy, the configuration splits into three parts:

Source configuration. Register the KIS Private Cloud API and call the material list query interface. The request body carries four key parameters: account identifier (AccountDB), page size (ItemsOfPage, default 10), current page (CurrentPage), and the time window (StartDate / EndDate). Here SourceTimeStart and SourceTimeEnd use the platform's built-in variables ${LAST_SYNC_TIME} and ${CURRENT_TIME} to automatically pick up the window — do not hardcode timestamps.

Mapping configuration. Wire source fields to target fields per the table above. In Qeasy, use placeholders like {{FNumber}} and {{FName}} to reference source fields. Set idCheck to true so the platform can decide create vs. update based on the code, avoiding duplicate inserts.

Target configuration. Register the OKKI CRM product write interface, method POST, effect EXECUTE. Note that product_id in the OKKI interface is the mapping key maintained automatically by the platform — no manual filling needed.

Two more switches worth calling out: buildModel = false means we do not auto-build a model and rely on the hand-written mapping; autoFillResponse = false means responses are not auto-back-filled, keeping the mapping table under the platform's unified management.

Implementation Steps

We typically break material sync into a three-phase rollout:

Step 1: Full baseline. Before go-live, run a single query without a time window to push all materials from the ERP into the CRM at once, building the initial mapping table. This runs only once at initialization and never again.

Step 2: Incremental switch-over. Once the baseline is in place, switch SourceTimeStart to ${LAST_SYNC_TIME} and start the schedule. In this project we set 0-59/45 7-20 * * * — every 45 minutes between 7 AM and 8 PM on weekdays. Dense sync during working hours, off overnight and on weekends — a typical 'incremental + full baseline dual track' pattern. The full run handles initialization; the incremental run handles daily changes.

Step 3: Schedule convergence. After one or two weeks of stable operation, observe the actual change volume. If changes are sparse, drop the frequency to every 2 hours or lower. If changes are dense and real-time is required, consider event-driven triggers. Do not start with high frequency — that is another common pitfall.

Pitfalls and Lessons Learned

Across several projects, these are the typical traps on this strategy:

1. Wrong time-window format. The KIS interface requires an ISO datetime with T as the separator, but the platform variable defaults to a space separator. Always wrap it with _function REPLACE('{{LAST_SYNC_TIME|datetime}}',' ','T'), otherwise the source side will reject the request outright.

2. Page size too small, data missed. The default ItemsOfPage of 10 is nowhere near enough for enterprises with large material catalogs. In one customer case we only stabilized after raising it to 100. After changing it, recheck total record count and page count carefully.

3. Inconsistent units. KIS uses grams for weight, while OKKI expects kilograms or pounds. This kind of mapping is not just string-to-string — you must convert units inside the mapping script, or first align the unit dictionary on both sides.

4. Disabled materials not flowing back. The incremental run only looks at change timestamps. If the source disables a material without touching its timestamp, the CRM keeps treating it as active. The safe approach is to run a separate status reconciliation task that compares the status field end-to-end once a week.

5. Dependencies not declared. If material sync has an upstream/downstream relationship with sales order sync (for example, orders need a product_id), the depends_on must be configured in Qeasy — otherwise the order will fail when the sequence is wrong. In this material the strategy's depends_on is an empty array, meaning it is an independent master data sync, but downstream strategies must explicitly depend on it.

When It Fits and When It Doesn't

Fits: Enterprises that need long-term consistency of material master data between ERP and CRM, where the change rate is not extreme (not per-minute); private deployments that are sensitive to data leaving the domain.

Doesn't fit: Scenarios that need real-time, second-level sync — those should be event-driven; purely display-only material info with no code mapping requirement — direct API fetch is lighter; and systems where the source side has no reliable timestamp field.