Syncing Product Master Data from ERP to CRM: A Single-Strategy Deep Dive into the Dingjie-to-Xiaoman Product Sync
What This Strategy Solves
When product master data lives in both an ERP and a CRM with mismatched codes, units, and category trees, sales sees one set of items while the supply chain sees another. This guide focuses on a single sync strategy that pushes ERP product master data to the CRM through a defined code-mapping pipeline, and shows how to make it a sustainable routine job on the Qeasy data integration platform.
Data Flow and Field Mapping
The flow is one-way: Source ERP (product master) → Qeasy integration platform (middleware for code conversion, field mapping, deduplication, and validation) → Target CRM (product record).
Key field mapping (real field names depend on the systems in use):
| Business meaning | Source ERP field | Middleware handling | Target CRM field |
|---|---|---|---|
| Product code | product_code | Centrally managed code mapping: source code → target rule | item_code |
| Product name | product_name | Trim whitespace; full-width to half-width | item_name |
| Unit of measure | uom | Aligned against a unit dictionary (pcs / set / kit) | unit |
| Category | category_path | Compressed to the CRM's 3-level category tree | category |
| List price | list_price | Two decimal places; currency normalized to CNY | price |
| Status | status | A active / X inactive | enabled |
How to Configure It on Qeasy
On real projects where we use Qeasy for this, configuration typically lands in three places:
- Data source registration: register the ERP product master endpoint as the source and the CRM item write endpoint as the target. The Qeasy connector handles authentication and pagination so we do not write SDK code by hand.
- Mapping rule orchestration: maintain the mapping table above in Qeasy's field-mapping canvas. It is strongly recommended to extract the three high-change rule sets — code mapping, unit dictionary, category mapping — into dedicated mapping dictionaries. Any business-side adjustment then changes one dictionary entry, not the strategy body.
- Target write policy: depending on the CRM's write semantics, choose between an upsert keyed on item code or an insert-only mode. A common pattern among Qeasy customers is the header-then-detail staging approach: first stabilize the product header fields (code, name, unit, category), then layer in price and inventory attributes, so that an attachment-field failure does not break the master data.
Implementation Steps
Phased scheduling is the key to a stable master-data sync.
- Step 1: Full initial load. Before the strategy goes live, run a one-off job that pushes every active ERP product to the CRM to build the initial baseline. This step must use the full endpoint without an incremental filter, so that the CRM side has a complete picture first.
- Step 2: Define the incremental start point. After the full load completes, record the "last successful timestamp" or "max update time" as the incremental start point. On Qeasy this is typically pinned as a strategy parameter or a scheduling context.
- Step 3: Configure the schedule. Product master data does not change often, but new SKUs may appear frequently in sales. The recommended pattern is "incremental polling every 5 minutes plus a daily full-volume safety net": incremental gives freshness, full-volume repairs any incremental gaps.
- Step 4: Reconciliation and exceptions. Attach a simple reconciliation node on Qeasy that compares the two sides' code sets and pipes the difference into an alert channel, so operations sees daily variance instead of discovering mismatched numbers three months after go-live.
Lessons from the Field
- Code mapping scattered across scripts becomes unmaintainable. The classic mistake is embedding "ERP code → CRM code" inline in every transformation script. The safe approach is to maintain a centralized mapping dictionary on Qeasy, so a business-side change takes effect in one place.
- Full and incremental merged into one strategy produces duplicate data everywhere. Keep full-volume initialization and daily incremental as two independent strategies, chained by schedule order, and do not try to solve both with a single if-branch.
- Units aligned by text only, not by semantics. A "set" on the ERP side and a "set" on the CRM side may refer to different bundling rules. Drop an explicit unit semantics dictionary in the middleware layer rather than doing plain string replacement.
- Inactive products are not synced with their status, so sales keeps ordering discontinued SKUs. The status field must travel with the master data, with explicit active/inactive value conventions.
- Category tree depth differences are ignored. The ERP has five levels while the CRM has three; pushing the full path will be truncated or rejected. The safe approach is to compress the tree in the middleware and maintain a traceable mapping table.
When to Use and When Not to
Use when: the ERP is the single source of truth for product master data and the CRM needs to quote by ERP code; product changes are infrequent but timeliness matters; multiple scattered systems must converge on one CRM.
Do not use when: the CRM must write back to the ERP, when the two systems hold fully independent product definitions, or when product records are co-edited under high concurrency.