Master Data Sync in Practice: Unified Coding and Scheduling for Products from Jushuitan to Kingdee

What This Strategy Solves

In retail and supply chain integration projects, the product master in the front-end e-commerce platform and the material master in the back-end ERP have long been managed independently. A retail client once ran into this exact issue: the front-end SKU name was changed, but the ERP material record was not updated. Three months later, during a cost reconciliation, the numbers on both sides did not match, and it took the finance team a whole week to sort things out. The very first pipeline we built on the Qeasy Data Integration Platform was designed to map products from Jushuitan into materials in Kingdee Cloud Galaxy under unified rules, ensuring a single source of truth and consistent IDs on both sides.

Data Flow and Field Mapping

The data flow is unidirectional A→B: the product master from source system A is cleaned and transformed by the Qeasy middleware layer, then written into the material master of target system B. The key field mapping is as follows:

We manage all coding mappings centrally in the Qeasy Mapping Center instead of hard-coding them inside strategies. When new categories are added, only one place needs to be updated.

How to Configure in Qeasy

The whole strategy is assembled in the Qeasy Data Integration Platform as three visual components:

1. Source Extractor: connects to the Jushuitan product master API and pulls data incrementally by update time. The incremental key is recommended to be last_update_time rather than create_time; otherwise, historical modifications will be missed.
2. Data Transformer: uses Qeasy field mapping plus a script node to handle code concatenation, unit conversion, and category ID translation. The script node supports JavaScript syntax, and a few lines of loop code are enough to merge multiple barcodes.
3. Target Writer: calls the Kingdee Cloud Galaxy material save API. Note that the create and update actions are separate. Qeasy automatically routes records based on whether the material code already exists.

Two other common configurations:

• Failure Retry: set retry count to 3 in Qeasy with exponential backoff intervals (30s / 2min / 5min) to avoid transient network jitter causing the whole batch to fail.
• Alert Callback: configure a Lark or DingTalk bot to push notifications immediately on single record failure, rather than waiting until the batch finishes.

Implementation Steps

We roll out this strategy in three phases, combined with the Qeasy scheduler:

1. Incremental Baseline Initialization: run a one-time full sync to seed all existing product records into Kingdee as the baseline for subsequent increments. The "Full Trigger" button in Qeasy runs a complete sync and automatically switches to incremental mode afterward.
2. Incremental Scheduling Live: set the schedule frequency to every 15 minutes. The Qeasy scheduler triggers on a fixed window, and the first run captures all products that changed within the past 15 minutes.
3. Historical Data Backfill: for the small amount of data modified after the full sync but missed by the incremental run, use the Qeasy "Backfill by Condition" feature to manually trigger another run filtered by the last modification time.

The scheduling window should avoid business peak hours. For example, run full syncs at dawn and high-frequency increments during business hours to avoid consuming source system resources.

Pitfall Recap

1. Wrong incremental key is the top cause of failure: early on, we used create_time as the incremental key, which caused renamed or re-specified products to be missed. The safe approach is to use update_time and persist the maximum timestamp after each run as the starting point for the next pull.
2. Code prefix not unified: the two systems have different code lengths, and the Kingdee side has strict length validation on material codes. Define the prefix rule first in the Qeasy Mapping Center before doing concatenation.
3. Unit mapping scattered in scripts: writing the unit mapping table directly inside JS scripts means that adding a new unit requires code changes. The proper way is to upload the mapping table to Qeasy's auxiliary data store and let scripts only look up the table.
4. Barcode fields overwritten: when a Jushuitan product has multiple barcodes, if the writer passes only one field, the later values overwrite the earlier ones. A loop must be implemented in Qeasy to split and write them one by one into the Kingdee barcode sub-table.
5. No idempotency causes duplicate materials: network retries can easily trigger duplicate writes. The Qeasy writer uses the primary key for idempotency by default, but this only works if the source primary key is stable and not randomly transformed in the middleware layer.

Applicable and Non-Applicable Scenarios

Applicable: small and mid-sized retail enterprises that need to unify front-end e-commerce product masters into ERP material masters, with stable product categories and predictable change frequency. Not applicable: source systems whose product fields change frequently and significantly, target ERPs that have stopped material master maintenance, or business requirements demanding bidirectional sync, which requires a separate reverse pipeline strategy and cannot reuse this solution.