Supplier Master Data Sync from Kingdee Cloud to WMS: A Single-Strategy Tutorial

What This Strategy Solves

In a real supply-chain integration project at a pharmaceutical distribution enterprise, supplier master data was long maintained centrally in the ERP, and the warehouse-side WMS needed to reuse the same records. What looked like a simple "push code and name" task actually involves cross-organization mapping, multi-org authorization, null-value handling, and incremental deduplication. On the customer side we ultimately chose the Qeasy data-integration platform (轻易云数据集成平台) to host this single strategy: Kingdee Cloud as the single source of truth, the WMS as the receiver — achieving unified coding, timely changes, and full traceability.

Data Flow and Field Mapping

The data flow is straightforward: source (Kingdee Cloud) → Qeasy middleware → target (WMS). The source calls executeBillQuery to list suppliers, with FSupplierId as the key and FNumber as the business code. The target calls the unit API for write, using id as the unique identifier, with idCheck enabled.

Key field mapping (simplified):

A detail often overlooked: with idCheck enabled on the target side, repeated pushes of the same code will be detected. Therefore, the source side must use FNumber (business code) for idempotency rather than relying on the auto-increment database ID.

How to Configure on Qeasy

In the Qeasy data-integration platform, building this strategy can be broken into three pieces.

First, register both platforms. Add Kingdee Cloud as the source and the WMS as the target, with auth info and base-data API endpoints. For the source set api to executeBillQuery (POST); for the target set api to unit (POST) and keep idCheck enabled.

Second, configure field mapping. The Qeasy mapping editor supports two modes: value mapping and function mapping. For fields like legal person and registered address — possibly empty on the source but required on the target — we typically use _function CASE WHEN ... THEN ... ELSE '/' END for fallback. This is a common pattern in Qeasy's pharma customers — putting "null tolerance" in the mapping layer rather than scattering it across scripts.

Third, maintain org fields in a dedicated mapping table. Customers often have a dozen use-orgs in the ERP, but only some map to the WMS. We pull FCreateOrgId.FNumber and FUseOrgId.FNumber into Qeasy's "centralized code mapping" so that when orgs change, only one place needs updating — not dozens of strategies.

Implementation Steps

Rollout is split into three phases to avoid hammering both sides with high-frequency schedules from day one.

Phase 1: Establish the baseline. Run a one-time full sync of all ERP suppliers to the WMS as the baseline version. After it completes, record the max FSupplierId as the starting point for incremental.

Phase 2: Stable incremental sync. Attach the strategy to a scheduler: source crontab */10 8-22 * * * polling new and modified suppliers every 10 minutes during business hours. The target starts offset by 5 minutes (5-59/10 8-22 * * *) to reduce concurrent write pressure.

Phase 3: Tune frequency. After observing for a week, keep 10 minutes if the WMS shows no obvious pressure; otherwise back off to 15 or 30 minutes. A common Qeasy customer pattern is "dual-track incremental and full" — incremental handles daily changes, a monthly full sync acts as reconciliation. Long-term, the numbers on both sides never drift apart.

Pitfalls and Lessons

First, passing empty values through is a classic mistake. WMS fields like frdb and zcdz are required, but some legacy suppliers in the ERP don't have a legal person maintained. The safe approach is to add a CASE fallback in the mapping rather than passing empty values directly — otherwise the entire batch fails on the target side.

Second, don't assume org fields. The create-org and use-org in Kingdee Cloud may differ, especially in multi-org enterprises. Mapping only the create-org will make some use-org supplier records invisible on the WMS — discovered only 3 months later when business complains about missing data.

Third, picking the wrong primary key causes duplicates. FSupplierId is an auto-increment DB ID and not stable across environments; FNumber is the real business code. In Qeasy the number field must be set to FNumber, otherwise idempotency check breaks.

Fourth, keep idCheck on. We saw a case where it was temporarily disabled to debug an issue, then forgotten — duplicate pushes created piles of junk data, and cleanup took two full days.

Fifth, scheduler time-window edges are easy to miss. Source */10 8-22 * * * stops after 22:00, but the WMS may still have late-shift inbound. If the warehouse runs 24 hours, broaden the time window or switch from polling to event-driven triggers.

Suitable and Unsuitable Scenarios

Suitable: single ERP as the master-data source, target WMS needs to reuse supplier records, and coding consistency is critical in supply-chain integration. Unsuitable: scenarios with multiple coexisting ERPs requiring bi-directional sync, or where supplier master data must be independently maintained on the WMS and written back to the ERP — those need bi-directional sync strategies, not one-way push.