Syncing Supplier Master Data from Kingdee Cloud to Wangdiantong: A Single-Strategy Tutorial

What This Strategy Solves

In an integrated retail-and-distribution supply chain, supplier master data is the root of purchasing, receiving, and reconciliation. One retail enterprise uses Kingdee Cloud for finance and the supply-chain general ledger, while the downstream e-commerce fulfillment system runs on Wangdiantong. The supplier file has only one trusted source: Kingdee. What we need to do is push Kingdee's supplier master data to Wangdiantong on an incremental cadence, so that two sets of codes and statuses never appear and purchase orders and statements can be reconciled automatically across systems.

Data Flow and Field Mapping

The data flow is unidirectional: Kingdee Cloud (source, side B) → Qeasy Data Integration Platform → Wangdiantong·Enterprise Qimen (target, side A). At the field level, the source uses a Query-type WebAPI called executeBillQuery to fetch supplier records, while the target uses an Execute-type WebAPI called wdt.purchase.provider.create to write them.

The "cycle" fields have no matching standard field on the Kingdee side. To avoid blocking master-data landing, we use a constant fallback strategy and let the business team maintain those values manually in Wangdiantong afterwards.

Configuring It on Qeasy

Log in to the Qeasy console, open "Integration Strategies", and create a new strategy. Set the source system to Kingdee Cloud, the target to Wangdiantong·Enterprise Qimen, the business module to "Master Data Sync", and the business object to "Supplier".

Source-side configuration: choose API executeBillQuery, effect QUERY, method POST, primary key field FSupplierId, business number field FNumber, enable idCheck. Declare FSupplierId, FNumber, FName, FCreateOrgId.FNumber, and FUseOrgId.FNumber in the request body, and use FUseOrgId.FNumber as the filter to scope to a specific use organization.

Target-side configuration: choose API wdt.purchase.provider.create, effect EXECUTE, method POST. Map provider_no to template variable {{FNumber}} and provider_name to {{FName}}; fill the cycle fields with the constants listed above. Qeasy's centralized code-mapping management is critical here — all supplier code conversion rules are maintained in one place, so adding a new organization or supplier type does not require modifying the strategy itself.

Implementation Steps

We split this strategy into three phases, which is much more stable than running it all at once.

Phase 1: Align the incremental watermark. First, on the Kingdee side, confirm a "watermark table" that records the current maximum FSupplierId. In Qeasy, set the incremental start point to this value and configure a 5-minute (*/5 * * * *) incremental schedule, so newly created and modified suppliers are pushed to Wangdiantong in small batches. This phase should run for at least one business day, with manual spot checks on two or three records.

Phase 2: Trigger the full backfill. Once the incremental flow is stable, use Qeasy's "full backfill" capability to push historical suppliers once and catch up everything before the watermark. A common pattern we see at customer sites is dual-track incremental plus full: the full task is triggered manually only during initial go-live or recovery, while incremental runs daily — this avoids dirty writes.

Phase 3: Enter steady-state scheduling. After the full backfill completes, the strategy returns to incremental every 5 minutes. At the same time, turn on "failure retry and alerting" in Qeasy, route warnings for code conflicts and required-field validation failures on the target side, and push them straight into enterprise WeChat.

Pitfall Recap

1. Organization filter without FUseOrgId. In the first run we forgot to add the organization filter, and same-named suppliers across organizations on the Kingdee side were all pushed to Wangdiantong, breaking downstream reconciliation. The safe approach is to make FUseOrgId.FNumber a hard filter on the source request body and add a check in Qeasy's mapping layer.

2. Treating constant fields as mapping fields. The cycle fields have no value in Kingdee; someone tried to take a shortcut and fabricate fields on the source side, only to see "field does not exist" errors on the target. A typical mistake is mixing "business fields" and "target-side defaults" together. The safe approach is header-then-body phasing: get the primary identifiers (code, name) working first, then add business extension fields, with constant fallbacks on the target side for extensions.

3. An imprecise incremental start point causes missed pushes. If the watermark is set too early, records are missed; if too late, restarts produce duplicate pushes. Qeasy's idCheck deduplicates by primary key, but dirty data can still appear at the code level. The recommended approach before go-live is the combination of a one-off "full backfill" plus a precise "incremental start point", and to keep audit logs afterwards for verification.

4. Time-zone pitfalls across cycles. When the Kingdee server and the Qeasy scheduler run in different time zones, organization-related timestamp fields on FCreateOrgId and similar fields can cause "just-modified suppliers not pushed" symptoms. Aligning Qeasy's scheduler timezone with the source system saves a lot of after-sales tickets.

Applicable and Inapplicable Scenarios

Applicable: a single organization and single legal entity, where the supplier file is issued by Kingdee and Wangdiantong is the downstream execution system, and an incremental cadence at the minute level is sufficient. Not applicable: multi-organization and multi-ledger parallel setups, or scenarios that require bidirectional sync (Wangdiantong feeds suppliers back), or where suppliers are first created in Wangdiantong and then backfilled to Kingdee — those require a bidirectional sync strategy and a separate design.