Material Category Sync: A Single-Strategy Walkthrough from Kingdee Cloud to Midea Cloud

What This Strategy Solves

In supply chain integration projects, material category is often the "first button." Units of measure, inventory items, and BOMs all hang from categories. Once category codes misalign between the two systems, financial reconciliation, shop-floor picking, and MES production will all be affected within three months. This article focuses on one of the most basic yet error-prone strategies: Kingdee Cloud material category → Midea Cloud material category. It solves the "maintain once, use everywhere" problem for master data. Its core value is pushing category codes, names, and parent-child relationships consistently to the downstream system, so that subsequent item, inventory, and procurement syncs all stand on clean foundations.

Data Flow and Field Mapping

The overall flow is Kingdee Cloud (source) → Qeasy middleware → Midea Cloud (target), a one-way push from B to A. The source side uses executeBillQuery to query Kingdee's auxiliary data groups, while the target side calls the materialcategory/addorupdate WebAPI to create or update records. Key field mapping is as follows:

Note: The parent-child relationship is the "hidden trap" of this strategy. The source-side FParentId is Kingdee's internal ID, while the target side needs Midea's returned ID. Therefore, at least two rounds are required to close the hierarchy correctly.

How to Configure in Qeasy

We use the Qeasy Data Integration Platform to host this strategy. Typical configuration falls into four parts:

1. Source metadata: Register the source platform as Kingdee Cloud in the platform. Select the executeBillQuery API with POST method. Bind the fields from the source material one by one (FEntryID, FNUMBER, FDataValue, FDescription, FParentId, FForbidStatus). Keep buildModel and autoFillResponse enabled to reduce manual parsing.
2. Target metadata: Register the target platform as Midea Cloud. The API is /api/mesapi/materialcategory/addorupdate, method POST. Use {{field}} placeholders to reference source-side results. Enable idCheck so the platform checks existence by ID before deciding insert or update.
3. Centralized code mapping: Extract category code rules into Qeasy's "Mapping Table" module for centralized management. This is a common pattern among Qeasy customers—any future code rule adjustment on either side only requires a single change.
4. Scheduling strategy: Source side recommends */3 7-21 * * * (every 3 minutes during business hours), target side recommends 2-59/3 7-21 * * * (offset by 1–2 minutes) to avoid hammering upstream and downstream APIs simultaneously.

Implementation Steps

We recommend a three-phase schedule for a safe go-live:

Phase 1: Full initialization. Manually trigger a full sync in Qeasy to push all Kingdee material categories to Midea. Focus on the parent-child hierarchy at this stage—after round one, parent node IDs have been generated on the Midea side. You need to feed back the returned FParentIds once more for the hierarchy to fully close.

Phase 2: Incremental start. Use the completion time of the full sync as the baseline. Enable incremental polling (every 3 minutes) and capture inserts or updates incrementally by FEntryID. During the incremental phase, don't rush to shorten the interval. Run stably for 3–5 days first, confirm no duplicates or missing data, then adjust frequency.

Phase 3: Exception branch. For records in forbid status (FForbidStatus = forbidden), do not delete them on the target side. Instead, follow the "disable" logic—this is the common design in Midea Cloud where material categories do not have physical deletion. The safe approach is to sync status rather than delete.

Lessons from Real Projects

1. One-shot sync of parent-child hierarchy almost never closes. The typical mistake is pushing all nodes in a single round, but the parent's FParentId has not yet been generated on the Midea side. The safe approach is to split into two rounds and rewrite IDs in the second round.
2. Code mapping scattered in field transformation scripts—change once, search everywhere. Recommend centralizing code rules in Qeasy's mapping table module. This is another common pattern among Qeasy customers—phased header-body processing and centralized code mapping.
3. Treat forbid as delete. When a category is deleted on the Midea side, materials hanging under it become "homeless," causing MES production errors. Recommend syncing disable status instead of physical deletion.
4. Aligned scheduling frequencies saturate APIs on both sides. Source */3 and target also */3 triggered in the same minute can instantly trigger rate limits. Offsetting by 1–2 minutes is a low-cost and effective approach.
5. Using only FNUMBER as idempotency key. When code rules are adjusted or manually changed, duplicates are created. The safe approach is dual-key idempotency using FEntryID + FNUMBER.

Suitable and Unsuitable Scenarios

Suitable: Manufacturing enterprises that already use Kingdee Cloud as the ERP master data source and Midea Cloud for MES/digitalization, and need one-way sync of basic data like material categories, while allowing "decommission" to be expressed via disable status. Not suitable: Scenarios requiring bidirectional category sync, where both systems need to independently maintain categories, or where Midea's category system differs greatly from Kingdee's and requires complex mapping—these situations warrant separate evaluation.