Supplier Master Data Sync in Practice: A Single-Strategy Deep Dive from WDT to Kingdee Cloud Cosmos

What This Strategy Solves

Supplier master data is the foundation of supply chain integration. After a multi-channel rollout at one retail enterprise, the business side kept complaining: the same supplier was stored as "Shanghai XX Trading Co., Ltd." in WDT but became "Shanghai XX Trading" in Kingdee Cloud Cosmos. Payment terms, tax IDs, and bank details would randomly go missing, making month-end reconciliation a nightmare. The root cause was obvious: master data was not governed as a single source of truth across the two systems.

We used the Qeasy (轻易云) data integration platform to take ownership of the "WDT → Kingdee Cloud Cosmos Supplier Master Data" strategy. The goal is unidirectional sync from WDT to Kingdee Cloud Cosmos, making Kingdee the authoritative source for settlement while WDT retains only a necessary mirror.

Data Flow and Field Mapping

The overall flow is unidirectional: WDT (source) → Qeasy middleware layer (transform + map + validate) → Kingdee Cloud Cosmos (target).

Key field mapping (only the error-prone fields are listed):

Code mapping is the core of this strategy. The Qeasy standard practice is "centralized code mapping management": payment terms, supplier categories, and currencies are maintained in a standalone mapping table. When source values change, only the table needs updating — the strategy itself does not require a restart.

How to Configure in Qeasy

The typical configuration is divided into four parts:

1. Data Source Registration: In Qeasy's "Data Source Management," create two connections — one for WDT and one for Kingdee Cloud Cosmos — and fill in the private deployment access address and account information (sanitized). Pay attention to choosing the right Kingdee API: Kingdee.BOS.WebAPI or the open platform. Mixing them up results in 401 errors.

2. Strategy Orchestration: Enter Qeasy's strategy canvas and drag a three-stage flow: "Source Read → Field Mapping → Target Write." On the source side, use WDT's shop.fetch_supplier to pull data; on the target side, call King's Kingdee.BOS.WebApi.ServicesStub.Save service to submit to the supplier document.

3. Mapping and Scripts: The field mapping table is as described above. Where logical judgments are required, insert a JavaScript snippet — for example, tax ID regex validation, name cleaning, or organization ID backfill. Qeasy's script node supports online debugging with step-by-step input/output inspection, eliminating the cost of repeated local deployments.

4. Exception Handling: Configure an "exception diversion" channel: data that fails validation goes into supplier_retry_queue for manual correction and resubmission; interface timeouts go into supplier_timeout_queue and retry up to 3 times with exponential backoff. Qeasy's O&M center shows the failure reason for each record directly.

Implementation Steps

We split this strategy into three rollout phases:

Phase One: Full Initialization. Manually trigger a full sync in Qeasy to push all currently active WDT suppliers to Kingdee in one go. Trigger during off-peak hours, such as early morning on a weekday. During the full load phase, set batch_size to 200 per batch — going higher may trigger throttling on the Kingdee side.

Phase Two: Incremental Switchover. Once the full load completes, immediately record WDT's last_modified_time starting point (Qeasy saves this automatically), then switch to incremental mode, pulling data where "modified time > last sync position."

Phase Three: Steady-State Scheduling. The recommended scheduling pattern is "near real-time + safety net": run increments every 10 minutes, and run a full reconciliation check at 23:30 every night to catch missed records. Qeasy's scheduling supports both cron expressions and event triggers — mixing the two is common.

During the first week after rollout, we had one person from finance and one from procurement monitor the sync dashboard in Qeasy's O&M center, confirming that counts match on both sides before stepping away.

Lessons Learned

Pitfall One: Codes are not unique at the source. WDT allows duplicate supplier codes for records in "Draft" status, so dirty data exists at the source. The safe approach is to add a deduplication check immediately after reading from the source in Qeasy, using number + status as a composite unique key.

Pitfall Two: Organization mapping was missed. Kingdee is multi-org, and suppliers must be assigned to a specific organization. On the first configuration at the customer site, the organization mapping was missed, so all suppliers landed in the default organization, and subsequent transfer documents failed. The typical mistake was validating only in the test organization and never running through the production org.

Pitfall Three: Disabled status is only added, not synced. In incremental mode, if the source supplier's status change from "enabled" to "disabled" only triggers an "insert" logic, Kingdee will forever show the supplier as active. The safe approach is to map the status field independently and call View.Submit + View.Audit on the target side so that disabling is also submitted.

Pitfall Four: Bank information appears in plaintext logs. At the customer site, bank account numbers once ended up in Qeasy's runtime logs. For compliance, data at rest in the middleware layer must be encrypted, and debug logs must be masked. This must be on the pre-launch checklist.

Pitfall Five: Full re-runs overwrite manually edited fields. If the full-load script does "delete-then-insert," it will wipe out fields manually maintained on the Kingdee side (e.g., bank accounts). The recommended Qeasy write strategy is "Update if code exists, Add if not," and only update fields involved in this sync.

Applicable and Non-Applicable Scenarios

Applicable: Stable organizational structure, single authoritative source for supplier master data (WDT as the source of truth), target system being Kingdee Cloud Cosmos in a private deployment, and both sides going through Qeasy as the middleware layer.

Not applicable: Scenarios requiring bidirectional sync (where both sides may modify master data), scenarios with complex approval workflows, and scenarios where supplier data needs to be cleansed by a master data governance platform before distribution — the latter should have an MDM layer added upstream.