Material Master Synchronization from Kingdee Cloud to ERP: A Single-Strategy Implementation Guide
What This Strategy Solves
In retail and manufacturing operations, material master data is usually maintained in one source ERP and then consumed by procurement, warehousing, and sales processes. In one implementation project, we needed to synchronize material codes, names, specifications, and other master attributes from the source system to the target system. The task may look like simple data transfer, but poor code mapping, incorrect status conversion, or an unsuitable schedule can quickly lead to mismatched records, duplicate creation, or unusable products.
This strategy uses a one-way flow: source system → Qeasy data integration platform → target system. We use Qeasy to handle API calls, field transformation, and scheduling, keeping the synchronization logic centralized instead of scattering it across multiple custom scripts.
Data Flow and Field Mapping
The overall chain is: the source system reads material records through a query API; Qeasy performs transformation and validation; the target system submits the data through an execution API to create or update materials. The key mappings are:
| Source field | Target field | Processing note |
|---|---|---|
| Material code | Inventory SKU | Direct mapping and business matching key |
| Material name | Product name | Direct mapping while preserving business meaning |
| Specification | Specification field | Map according to target requirements; convert format if needed |
| Previous code | Extended or historical code | Retain for traceability |
| Source identifier | Material internal ID | Use for logging and troubleshooting; do not use as SKU |
| Lifecycle status | Product status | Convert through a controlled status dictionary |
| Warehouse information | Warehouse information | Assemble in the JSON or array structure required by the target API |
| Length, width, height | Package dimensions | Normalize units and field types; preserve empty values |
Code mapping should be centrally managed. A common Qeasy implementation pattern is to maintain code conversion, status mapping, and default-value rules in one place rather than in multiple integration scripts. For header and body data, use a phased approach: first synchronize basic fields, then process warehouse and dimension extensions after the target confirms the basic record is valid.
How to Configure It in Qeasy
First, create the source-system connection and configure the query method, request method, and required fields. At minimum, read the material code, name, specification, and any other attributes required by the target. After the API response arrives, check for empty codes and unexpected field types before transformation.
Second, configure field mapping. Map the material code to the target SKU and the name to the target product name. Status values must be converted through a dictionary because source and target enums may differ. Convert length, width, height, and similar fields to the data types accepted by the target API, and package warehouse information according to the interface contract.
Third, configure the target execution behavior. The target system generally requires a create or update API. Before submission, enable code matching and idempotency checks. Repeated delivery of the same code must not create duplicate records. The safe approach is to use the material code as the business key and look up or update the existing record.
Fourth, configure validation and monitoring. Qeasy should record each read, transformation, submission, and failure reason, including empty codes, target rejection, empty names, and formatting errors. In production, retain the original response and a transformation summary, but never log credentials, tokens, or internal addresses.
Implementation Steps
- Incremental starting point: Define the initial scope and incremental cursor. During the first launch, start from a confirmed business time point or a specified code range rather than automatically pulling all historical data. If the source supports incremental queries by update time or primary key, prefer that method.
- Full-data trigger: Run a controlled full synchronization before the formal cutover. A full run is not simply an unrestricted replay. Complete a small batch trial, then expand the scope gradually. Configure batch size, retry limits, and manual confirmation points in production.
- Schedule frequency: Source extraction and target submission can run on different fixed intervals, but they must not both retry large volumes at the same time. Schedule outside business peaks and use delayed retries for failures.
- Go-live: After the full run passes, switch to the incremental task and retain a parallel observation period. Each day, compare additions, modifications, and failed records in both systems and confirm that the business team maintains data only in the source system.
- Exception recovery: Apply limited retries to temporary errors. Missing codes and invalid field values should enter an exception list instead of being retried indefinitely. After the source data is corrected, compensate the failed item by code.
We recommend a dual-track model: run incremental synchronization in daily operations, and trigger a confirmed full run during go-live or major changes. During a full run, isolate batches so incremental processing does not write the same materials concurrently.
Lessons Learned
Pitfall 1: Using the name as the unique key. Material names can be duplicated or changed. A common mistake is creating a record solely by name, which produces duplicates. Always use the material code as the business key.
Pitfall 2: Hard-coding status values. Source and target systems often use different status enumerations. Passing source values directly may incorrectly disable a target product. Maintain status mapping centrally in Qeasy and review it with the business team.
Pitfall 3: Infinite retries for failed tasks. Network fluctuations can be retried, but missing fields will not be fixed by repetition. Separate temporary errors from business validation errors and set a retry ceiling.
Pitfall 4: Full and incremental tasks colliding. Concurrent submission of the same material in different batches can create update-order problems. Pause or isolate the corresponding incremental window before a full synchronization and restore it afterward.
Pitfall 5: Sensitive data in logs. Interface configurations and logs must not contain real accounts, credentials, tokens, or internal addresses. Qeasy deployments should use masked records and retain only tracking identifiers, material codes, and error reasons.
Suitable and Unsuitable Scenarios
This strategy is suitable when one source system owns material master data and a target system needs to consume it continuously, especially for shared materials, frequently changing master data, and businesses that need code history. It is not suitable when source data quality is persistently unstable, when the target requires complex approval before activation, or when the two systems have fundamentally different organizational, inventory, or batch semantics. Those situations require data governance and an interface-boundary review first.