Material Master Data Sync in Practice: Deep Dive into a Single Strategy from Kingdee Cloud to Sinopharm WMS

What This Strategy Solves

Pushing material master data from an ERP to a WMS sounds like a simple "query + write" job. After a real project, however, we found that the three things that truly determine success are encoding mapping, the incremental starting point, and scheduling frequency. Misaligned encodings cause the two sides' material counts to drift apart after three months; a wrong incremental starting point causes the first run to either miss data or duplicate it; an unreasonable schedule overloads the WMS logging and pushes the ERP query interface to its limits. This article dissects one single strategy in detail.

Data Flow and Field Mapping

The data flow is unidirectional: Kingdee Cloud (source) → Qeasy Data Integration Platform (intermediate layer for cleansing and mapping) → Sinopharm WMS (target).

On the source side is Kingdee Cloud's material master interface, a typical query WebAPI (executeBillQuery, POST), pulling fields including FMATERIALID (entity primary key), FNumber (code), FName (name), FSpecification (specification/model), FOldNumber (old material code), and FBARCODE (barcode).

On the target side is Sinopharm WMS's ReqPubGoodsErp interface (WebService, POST, EXECUTE semantics), which receives product master data writes. Key field mapping:

The intermediate layer does only two things: rename fields, and inject platform-level constants like the owner code as static values. This is a typical "light mapping" scenario that Qeasy's configuration UI can express in a single mapping table.

How to Configure in Qeasy

Open the Qeasy Data Integration Platform, create a new strategy, choose "Kingdee Cloud" as the source and "Sinopharm WMS" as the target. Key configuration points:

First, the source uses a "Query Action," select executeBillQuery as the API, and include fields like FMATERIALID, FNumber, FName, FSpecification, FOldNumber, and FBARCODE in the request body. Turn off idCheck since we rely on incremental condition filtering rather than single-record fetching.

Second, the target uses an "Execute Action," select ReqPubGoodsErp as the API with POST. Note that idCheck here must be turned on—this is the safe approach, letting the WMS use primary keys for idempotency so that repeated pushes do not produce dirty data.

Third, in the "Field Mapping" panel, do one-to-one mapping: {{FNumber}} → ERP_GOODS_CODE, {{FMATERIALID}} → ERPGOODSID, and fill static constants for the owner code. One common pattern among Qeasy customers is "centralized encoding mapping management"—all FNumber-related mappings are consolidated into one table so a change takes effect across the entire chain.

Fourth, configure the exception handler to "skip by primary key" so that materials already existing on the WMS are skipped automatically without errors.

Implementation Steps

We split this strategy into a three-phase schedule:

Phase One: Incremental starting point. Before the first launch, run a full export on the Kingdee Cloud side and record the starting FMATERIALID of all current materials as the incremental starting point. Qeasy's scheduler supports passing in "last maximum primary key" as the next query condition.

Phase Two: Full trigger. Before the first official scheduled run, manually trigger a "full backfill" to write all historical materials into WMS in one go. This step runs only once on the cutover day.

Phase Three: Normal scheduling. The source cron is set to */10 8-22 * * * (every 10 minutes during business hours), and the target is staggered by 5 minutes to 4-59/10 8-22 * * * to avoid simultaneous concurrent access to the same interface. A common "incremental and full dual-track" pattern applies here: incremental on weekdays, plus a verification-style full run at 02:00 every Sunday to catch incremental misses.

Pitfall Review

Pitfall 1: Mixing up FNumber and FMATERIALID. This is the most common error. FNumber is the business code (changeable); FMATERIALID is the physical primary key (permanent). If you use FNumber as the idempotency key, the day the customer changes a code, WMS will generate duplicates. The safe approach is to use FMATERIALID for idempotency.

Pitfall 2: Choosing the wrong field for the incremental starting point. Using FModifiedDate as the incremental condition easily causes misses because someone may batch-edit materials at dawn. The safe approach is to use the auto-increment FMATERIALID primary key and record "last maximum ID" as the next starting point.

Pitfall 3: Forgetting to turn on idCheck on the target side. If the WMS write interface lacks idempotency, an incremental rerun will produce duplicate products. Always turn on idCheck and configure primary-key-based skip.

Pitfall 4: Schedule frequency so high that it overwhelms the source. We have seen a project on the customer site schedule material sync once per minute, only to push Kingdee Cloud's query interface into response timeout. Once every 10 minutes is generally enough for material master data, and the WMS side should be staggered by another 5 minutes.

Pitfall 5: Hardcoding the owner code in multiple places. If platform-assigned values like the owner code are scattered across multiple scripts, a single change must be replicated N times. It is recommended to use Qeasy's "Static Dictionary" for centralized hosting so that one change covers all.

Applicable and Non-Applicable Scenarios

Applicable: Supply chain scenarios where ERP and WMS are two separate systems, material master data needs unidirectional sync between them, and the encoding system is relatively stable.

Not applicable: Scenarios requiring bidirectional material sync (where both sides can modify), and complex master data governance scenarios with frequently restructured material codes or across multiple organizations and account sets—the latter requires a dedicated MDM platform rather than a simple integration strategy.