Syncing Supplier Master Data from Kingdee Cloud to Wangdiantong: A Qeasy-Based Implementation Guide

What This Strategy Solves

Supplier master data is the foundation of any supply chain system—purchase orders, receipts, and payment documents all depend on it. When records diverge between systems, downstream documents either fail to find a supplier or get attached to the wrong one. In one retail project we encountered this exact issue: a supplier had been deactivated in Kingdee Cloud, but Wangdiantong kept pushing orders against it, leaving receiving documents in limbo and forcing endless reconciliation at month-end. The core value of this strategy is treating Kingdee Cloud as the Single Source of Truth for supplier data, then syncing changes into Wangdiantong on a schedule via the Qeasy data integration platform so both sides stay aligned over time.

Data Flow and Field Mapping

The flow is unidirectional: Kingdee Cloud (source) → Qeasy middleware → Wangdiantong·Flagship Qimen (target).

On the source side, Qeasy calls Kingdee's executeBillQuery interface to fetch supplier records (FSupplierId as business key, FNumber as the code). The middleware applies code mapping and field transformation, then calls Wangdiantong's wdt.setting.purchaseprovider.push interface to write the data.

Key field mapping table:

In Qeasy, code mappings are best maintained in a single dedicated mapping table rather than scattered across scripts—this is one of the most common patterns we see among Qeasy customers.

Configuring in Qeasy

Source side: Pick the Kingdee Cloud adapter, API executeBillQuery, method POST, and enable idCheck (idempotent dedup by FSupplierId). In the request body, include FSupplierId, FNumber, FName, create org, and use org.

Target side: Pick the Wangdiantong·Flagship Qimen adapter, API wdt.setting.purchaseprovider.push. Map provider_no to {{FNumber}} and provider_name to {{FName}}. Contact, landline, mobile, and fax fields are left as empty strings for now since the Kingdee query did not return them in this iteration; they can be added later in Qeasy.

Scheduling: The source uses */10 7-22 * * * to poll every 10 minutes; the target uses 8-59/10 7-22 * * *, offset by 8 minutes so it does not call out before the source finishes pulling.

Implementation Steps

Step one is defining the incremental cursor. In the source configuration, set a "last sync time" cursor so only suppliers changed after that timestamp are fetched. For the first go-live, place the cursor well before a clear business cutover so existing records are picked up.

Step two is triggering a one-time full load. Clear the cursor and run a full sync to bring every current supplier across. A common Qeasy customer pattern is "incremental plus full-load dual track": run incremental normally, then trigger a full reload whenever data drift is suspected.

Step three is establishing the schedule. The source polls every 10 minutes and the target runs 8 minutes later. Restrict execution to the business window of 07:00–22:00 and leave the early hours for reconciliation and catch-up jobs.

Step four is post-launch verification. For the first three days, manually sample five records per day and check that code, organization, and disable flags match on both sides.

Pitfalls and Lessons Learned

Pitfall 1: Organization fields ignored. Kingdee supports multiple organizations, and the same supplier can carry different codes under different orgs. If only FNumber is synced without the org, Wangdiantong will end up mixing suppliers from different orgs. The safe approach is to write the org as an auxiliary key alongside the mapping table.

Pitfall 2: Source disabled status not filtered. When a supplier is forbidden or frozen in Kingdee, Wangdiantong should also reflect that status—otherwise downstream orders keep flowing. The typical mistake is that the source query does not filter by status, so disabled records are pushed as well. Add FForbidStatus = 'A' to the source filter.

Pitfall 3: Empty contact fields cause interface errors. Wangdiantong's purchaseprovider.push validates the format of some non-required fields and rejects null values. A common trip-up is that Qeasy defaults null to a JSON null rather than an empty string. The safe approach is to add a fallback script before target mapping that converts null to "".

Pitfall 4: Wrong incremental cursor causes data loss. If the cursor is set to midnight on launch day, suppliers created earlier that morning will not sync. The safe approach is to move the cursor back one to two hours to absorb clock drift.

Pitfall 5: Supplier code changed in Kingdee causes mismatch. Supplier codes should not change in theory, but they occasionally do in practice. Qeasy is idempotent by id by default, so if Kingdee changes FNumber while FSupplierId stays the same, Wangdiantong "finds the record by id, updates the name, but leaves the old code." The recommended fix is a script on the target side that raises an alert when a code mismatch is detected instead of silently updating.

Suitable and Unsuitable Scenarios

Suitable: Kingdee Cloud is the single source of truth for supplier data, Wangdiantong is a downstream business system, and a unidirectional sync is sufficient. Supplier count ranges from thousands to tens of thousands, and scheduled (rather than real-time) sync is acceptable.

Not suitable: Bidirectional sync where both sides maintain suppliers, real-time second-level response requirements (use event-driven triggers instead of polling), or scenarios where field structures differ so drastically that heavy transformation is required—in those cases, data governance should come first, then integration.