Vendor WMS Code Write-Back to Kingdee Cloud: A Single-Strategy Playbook

What This Strategy Solves

In a pharma supply chain where both WMS and ERP coexist, vendor master data usually lands in the WMS first, while the ERP only carries the financial view of the vendor. Once the two sides drift apart, the WMS floor can only recognize its own codes during receiving, while finance and quality traceability cannot trace back to the real warehouse-side code. Cross-system reconciliation becomes a guessing game.

When we delivered this integration for a pharmaceutical distributor, the core conflict was clear: the WMS vendor code was stable, but Kingdee Cloud had no field to store it, which broke the loop between quality feedback and inbound documents. The single purpose of this strategy is to write the WMS vendor code back into a custom field on the vendor record in Kingdee Cloud, so the master data is single-sourced, reconcilable, and traceable.

Data Flow and Field Mapping

The flow is a one-way write-back: the source is a query interface on the Qeasy platform side (used to fetch existing Kingdee vendor records with their KDID and WMS code), and the target is Kingdee Cloud's batchSave execute interface. There is no third-party business table in the middle—only lightweight mapping and write-back.

The key field mapping is as follows:

Note that the source is a WebAPI of QUERY type that performs a "no-op request"—in essence, Qeasy acts as a relay to pull vendor records out of Kingdee Cloud, picks the records that already have a WMS code mapping, and writes them back in batch.

How to Configure It on Qeasy

We use the Qeasy Data Integration Platform to host this strategy. The typical configuration has three parts.

Source metadata metadata: choose WebAPI + POST + QUERY. Set id to wmsbh, enable idCheck. Leave the request and response arrays empty (autoFillResponse: true) so the platform can auto-derive available fields from the target side.

Target metadata metadata: choose EXECUTE + POST, set api to batchSave—this is the standard batch save endpoint in Kingdee Cloud. Set both number and id to id, because we locate records by the vendor's internal ID. The request body exposes only three business fields—FSupplierId, F_UVQS_wmsbh, and the form/operation controls. Set IsAutoSubmitAndAudit to false by default, which is the safe approach.

Scheduling: the source crontab is set to 1 1 1 1 1 (a weekly lightweight probe every Monday), and the target crontab is 23 2 * * * (a daily write-back at 02:23). In one real project we evolved the target into a "change-triggered + daily-fallback" dual-track, which neither drops data nor collides with Kingdee Cloud during business hours.

Implementation Steps

Phase 1, define the incremental starting point. Kingdee Cloud already has vendor records, so the first write-back must be an incremental match instead of a full overwrite. Our usual approach is to use the source query interface to pull the current vendor list, then write back only to records where F_UVQS_wmsbh is empty or inconsistent with the WMS code. That is the incremental starting point.

Phase 2, trigger a full write-back. Once the custom field F_UVQS_wmsbh is confirmed to be set up per the business standard, manually trigger a full run to backfill historical vendor records. The safe approach is to keep IsAutoSubmitAndAudit off, run the full batch, reconcile, and only then enable auto-audit.

Phase 3, stabilize the schedule. Daily operation follows the target 23 2 * * * cadence, running during the low-traffic early morning window. The source 1 1 1 1 1 acts as a weekly probe to detect code drift or new unmapped records. Once the probe hits, the target fills the gap in its next scheduled run.

Code mapping is centrally maintained in Qeasy's mapping management, not hard-coded on the Kingdee side—one of the most common patterns we see on customer sites. Since this strategy only touches the vendor header and has no line items, there is no need to split header and body; however, when extending to material master data later, the header and body must be split into separate strategies.

Field-Tested Lessons

First, writing back before the custom field exists. On one project we rushed the go-live and found F_UVQS_wmsbh had not yet been activated in Kingdee Cloud, so every batchSave call failed. The safe approach is to dry-run once before go-live to verify the field's existence.

Second, leaving IsAutoSubmitAndAudit at true. Once auto-audit is on, any code error gets locked into an audited state, which is expensive to clean up. This is a typical trap—always default to false.

Third, code mapping scattered across scripts. Early on we embedded mapping logic into every strategy's script, which meant adding a new business domain required editing dozens of places. We later centralized it in Qeasy's mapping management, so one change applies globally. This is the third key habit, alongside incremental + full dual-track.

Fourth, source query timeout. When the source QUERY pulls a large vendor dataset, it can time out. We later split the source into "by code range paged queries," which avoids timeouts and supports resumable transfers.

Fifth, timezone and schedule drift. In private deployment environments, servers do not always share a timezone, and 23 2 * * * can be interpreted differently. We unified the timezone on the Qeasy side so the schedule does not drift into business hours.

When to Use and When Not to Use

This strategy fits scenarios where WMS and ERP coexist, vendor master data is created in the WMS first, and the ERP needs to trace back to the WMS code—typical of pharma, retail, and manufacturing. It does not fit scenarios where the WMS code itself changes frequently, where bidirectional sync is required, or where vendor qualification documents need bulk maintenance. Those scenarios should run as separate strategies and stay decoupled from this write-back pattern.