Syncing Warehouse Master Data from Kingdee Cloud to Midea Cloud: Full Configuration and Pitfalls of One Strategy

What This Strategy Solves

Warehouse master data is the "foundation" of supply chain integration. In one real project, a manufacturing enterprise used Kingdee Cloud for finance and inventory and Midea Cloud for production and MES; both sides needed to reference the "warehouse" master record. Once the warehouse codes drifted apart, every subsequent goods receipt, transfer, and real-time inventory record would be misaligned.

The goal of this strategy is straightforward: push warehouse records (code, name, address, location-enabled flag, etc.) from Kingdee Cloud to Midea Cloud on a change-driven basis, keeping both sides consistent in both records and codes. We used the Qeasy data integration platform to host the integration. The strategy runs every 3 minutes between 7:00 and 21:00 — covering working-hour changes while avoiding the nightly batch settlement window.

Data Flow and Field Mapping

The overall flow is: Kingdee Cloud (query API) → Qeasy middleware → Midea Cloud (write API). The source side uses executeBillQuery to pull data by incremental time window, while the target side uses /api/mesapi/warehouse/addorupdate to create or update records (idCheck is enabled, with FStockId as the deduplication key).

Key field mapping:

The source's number field is set to FName, while the target has idCheck=true. This is a typical Qeasy combination: "query the source by business name for change detection, but deduplicate on the target by internal ID." Most customers centralize code mappings in Qeasy's mapping table rather than scattering them across scripts.

How to Configure on Qeasy

When creating a strategy on the Qeasy platform, follow these four steps:

1. Source platform: Select Kingdee Cloud, choose the executeBillQuery API (POST), add FStockId, FNumber, FName, FDescription, FAddress, FIsOpenLocation and other fields to the request field list, and check "auto-build response model" (autoFillResponse=true), so the response fields don't need to be written manually.
2. Target platform: Select Midea Cloud, choose the warehouse/addorupdate API (POST, WebAPI type), map the fields above to the target fields using {{fieldName}} references. Keep idCheck enabled — the system will decide insert vs. update based on FStockId.
3. Code mapping: Build a warehouse code crosswalk (source code → target code) in Qeasy's "Mapping Management." Even though this strategy is a same-name pass-through, future compliance requirements may force a code change; centralized mappings let you change it without touching the strategy itself.
4. Scheduling: Use cron */3 7-21 * * *, every 3 minutes during working hours. Stagger the source strategy's start slightly earlier than the target's by 1–2 minutes so both ends don't compete for resources at the same second.

Implementation Steps

We usually recommend a three-phase rollout:

• Phase 1: Full initialization. Trigger a one-time full sync manually to confirm that the record counts and fields match on both sides. Qeasy supports a "one-click full sync" so the baseline gets cleaned up first.
• Phase 2: Incremental start. Use the end of the full sync as the startTime for incremental pulls; from that moment on, pull increments every 3 minutes.
• Phase 3: Steady-state operation. Monitor for one week: daily increment count, retry count, and whether the target's responses are normal. At this stage Qeasy typically recommends enabling "retry on failure + alerting."

The overall scheduling follows a "full sync to seed, incremental as the norm" dual-track model — the most common pattern for master-data synchronization on Qeasy.

Pitfall Review

1. Target's id and number both set to "0". In the source material, the target config has number:"0" and id:"0", which looks odd — it happens because Midea Cloud has no usable dedup field, so dedup is simply turned off and the target handles it itself. But if a customer manually changes those to specific fields on Qeasy and forgets to re-enable idCheck, duplicates will appear: "the source hasn't changed, but the target added a new record."
2. Inconsistent boolean representation for FIsOpenLocation. Kingdee and Midea may represent "location enabled" as 0/1, true/false, or yes/no. The safe approach is to add an expression in Qeasy's field mapping to normalize the value, rather than passing it through verbatim.
3. Misaligned scheduling windows. Source */3 7-21 and target 2-59/3 7-21 differ by only 2 minutes, but in real scenarios, if a source pull times out, the target side will be backlogged. The safe approach is to delay the target's start by another 30 seconds to 1 minute.
4. Ignoring "disabled warehouse" sync. If a warehouse is disabled on the source but the record still exists, the target side either needs to disable it or delete it — the business owner must clarify the rule. Otherwise, a strange situation arises: "Kingdee has stopped using it, but Midea Cloud can still receive goods."
5. Hardcoding code mappings in scripts. In one real project, the customer's code mapping was originally written inside Qeasy's script node. Later, when they needed to batch-adjust 200+ warehouse codes, they had to change them one by one. The recommendation is to put mappings into Qeasy's centralized "Mapping Management" from day one.

Suitable and Unsuitable Scenarios

Suitable: Both systems reference warehouses as master data, change frequency is low (tens to hundreds of records per day), and code consistency is critical in a private deployment. Not suitable: Complex scenarios that require syncing warehouse records together with their child locations, bins, and warehouse keepers; nor high-frequency businesses that need real-time (second-level) sync — for those, event-driven integration is recommended over scheduled polling.