Product Master Data Cross-System Sync Solution: Field Mapping and Scheduling Design from ERP to eCommerce WMS

Feature Overview

The Product Master Data Sync Solution in Qeasy DataHub (轻易云数据集成平台) is designed to synchronize SKU-level product information between an upstream ERP and a downstream eCommerce warehouse management system. We built this feature because product master data is typically scattered across ERP, eCommerce mid-platform, and WMS systems, and manual maintenance is not only inefficient but also prone to errors caused by inconsistent field semantics—errors that quickly cascade into stock, pricing, and order-fulfillment issues. With the visual solution editor, users can build a sync pipeline from the perspective of "source object → target object", while the platform handles API calls, field mapping, data transformation, scheduling, and exception alerting.

A typical use case is: a company uses an ERP to manage material codes, purchase prices, specifications, units, and brands, and needs to deliver this data to an eCommerce WMS in the SKU format required by the warehouse. Along the way, fields rarely line up one-to-one, and the source data frequently needs cleaning to match the target's rules. The platform covers most of these situations with four mapping types: DIRECT, CONSTANT, TRANSFORM, and COLLECTION.

Usage Scenarios

This solution demonstrates a one-way sync from ERP product master (Ptype) to eCommerce WMS product (ItemSKU):

• Source: ERP material/product master, fetched via the /GetPtypeInfo endpoint using QUERY mode with queryParams as the filter; autoFillResponse is enabled so response fields are filled in automatically.
• Target: The eCommerce WMS product endpoint /open/itemsku/upload, with items as the root node for batch uploads.
• Sync mode: Both full and incremental sync are supported, controlled by the source queryParams. A recommended cadence is source every 3 minutes between 07:00 and 21:00, with the target scheduled slightly later so it never reads a half-loaded batch.
• Typical mappings: sku_id takes the material code EntryCode directly; i_id (style code) requires REPLACE(FullName, ' ', '') to strip spaces; purchase_price maps from PreBuyPrice1; batch_enabled is a fixed constant "0".

Configuration Guide

To build this solution in Qeasy DataHub, the configuration falls into three main parts.

1. API and Request Configuration The source uses QUERY mode—enter the endpoint, request template, and enable autoFillResponse. The target uses WRITE mode, with dataKey=items configured as the root field for the batch payload. Remaining fields are configured in the field mapping table.

2. Field Mapping Table The mapping table is the heart of the solution. Each row describes a target-to-source correspondence. Four mapping types are supported:

• DIRECT: Take the source value as-is, e.g. sku_id ← EntryCode, name ← FullName, unit ← UnitName.
• CONSTANT: Write a fixed value, e.g. batch_enabled ← "0", used when the target field has no dependency on source data.
• TRANSFORM: Expression or function transformation, e.g. i_id ← REPLACE({{FullName}}, ' ', ''). The platform supports SQL-style expressions, string functions, arithmetic, CASE WHEN branching, and common helpers such as FROM_UNIXTIME, LEFT, and LOCATE.
• COLLECTION: Code mapping. When the source only provides a category ID or unit code, link an independent mapping solution through _findCollection or _mongoQuery to translate the internal ID into the human-readable name expected by the target.

3. Scheduling A recommended source schedule is 0-59/3 7-21 * * * (every 3 minutes between 07:00 and 21:00). The target is scheduled as needed and starts strictly after the source so the data is ready when it is read.

Caveats

1. Robustness of i_id space stripping: The current solution uses REPLACE to remove spaces. If the source FullName may contain full-width spaces, tabs, or other invisible characters, append TRIM or a regex cleanup to avoid duplicate style codes in the target.
2. Override rule for duplicate fields: When the same target field is defined more than once in the mapping table (for example, purchase_price first as the constant "0" and again as {{PreBuyPrice1}}), the platform applies last-wins, so the final value is PreBuyPrice1. Keep mappings one-to-one to avoid ambiguity.
3. Unmapped source fields: Source fields such as Volume and BoxPackQty are not mapped because the target endpoint does not expose corresponding fields. If the target later supports volume, simply add a DIRECT row without changing anything else.
4. Scheduling timing: When the source runs every minute and the target runs later, ensure that the source schedule window actually covers the target's first run, or the target will read an empty payload.
5. Extending code mappings: If the source later provides only CategoryId/UnitId, do not modify this solution directly. Create a separate "product category mapping" solution and link it via the COLLECTION type. This keeps the data pipeline decoupled, reusable, and easy to maintain.