Production Manufacturer WMS Number Write-Back to Kingdee Cloud: A Single-Strategy Write-Back Tutorial

What this strategy solves

In pharma and manufacturing supply chains, WMS and ERP often drift apart: WMS maintains its own manufacturer code (wmsbh), while Kingdee Cloud also keeps a manufacturer master file with its own numbering. The moment procurement receiving validation, batch traceability, or three-way reconciliation kicks in, the mismatch surfaces again and again. In one real project we built a deliberately small strategy on the Qeasy integration platform — its sole job is to write the WMS-side manufacturer number back into a custom field on the Kingdee Cloud manufacturer record, acting as the "last mile" of the larger supply chain integration.

Data flow and field mapping

The data flow of this strategy is unusual: the source is the Qeasy integration platform itself, the target is Kingdee Cloud. It looks like platform → ERP, but in practice the platform acts as a relay — it first pulls wmsbh from WMS together with the ERP association keys (KDFormId, KDFNumber, KDID), and then calls Kingdee's batchSave to write wmsbh back to the matching record.

The source request is a POST WebAPI with an empty body (a "do-nothing" query). The fields that matter in the response are:

Field	Meaning	Purpose
strategyId	Strategy identifier	Link tracing
wmsbh	WMS-side manufacturer number	The actual payload of this write-back
wmscode	WMS-side manufacturer code	Auxiliary identifier
KDFormId	Kingdee business object form Id	Targets the right master type
KDFNumber	Kingdee-side code	Unique key to find the manufacturer

The target side is Kingdee's batchSave. The key field mappings are:

Target field	Source	Notes
FID	{{KDID}}	Master record key, used as the update anchor
F_UVQS_wmsbh	{{wmsbh}}	Custom field carrying the WMS number
FormId	{{KDFormId}}	Business object form Id
Operation	Save	Save only, no submit
IsAutoSubmitAndAudit	false	Audit is triggered manually or by a later strategy

Note: wmsbh is string on both sides, so no type conversion is needed. But case, whitespace, and hidden characters are notorious cross-system landmines; in Qeasy we centralize trimming at the field cleaning node.

How to configure it in Qeasy

Here is how we wired it up on a real project:

Source metadata: choose WebAPI, effect = QUERY, method = POST. Bind the number field to KDFNumber as the unique identifier and turn on idCheck. The request body is usually empty; the platform fills pagination automatically.
Target metadata: type = EXECUTE, binding Kingdee's batchSave. Hard-wire FID to the KDID variable, inject FormId via variable, set Operation to Save, and set IsAutoSubmitAndAudit to false.
Field mapping: map wmsbh → F_UVQS_wmsbh. We use Qeasy's built-in variable resolution with {{wmsbh}} and add no transformation function — that way nothing hides a real bug.
Uniqueness policy: because this is an Update, not an Insert, idCheck must stay on, and number must locate a unique record on the target side, otherwise the whole batch fails.

A pattern we often see among Qeasy customers: keep all code-mapping relations in a single "mapping table" — the source query uses KDFNumber to retrieve KDID and KDFormId, which then drive the write-back. New manufacturers follow the same path, and when you troubleshoot later, the whole chain is visible at a glance.

Implementation steps

We split it into three scheduling phases and it runs steadily:

Bootstrap (one-shot full trigger): manually trigger once in Qeasy to backfill all historical records that already have a KDFNumber but an empty F_UVQS_wmsbh. Usually scheduled before the night shift.
Incremental start point: pull manufacturer records from the source that are new or changed since the last successful write-back, skipping rows where wmsbh is already empty.
Scheduling frequency: the source crontab 1 1 1 1 1 (monthly full trigger), the target crontab 23 2 * * * (daily early-morning write-back, off-peak). Day-to-day we run incremental; once a month we run a full reconciliation. This is the classic "incremental + full dual track" pattern among Qeasy customers.

In an on-premise deployment, keep the credentials for both platforms inside their respective connectors in Qeasy rather than hard-coding them into the strategy.

Lessons from the field

A common mistake is setting Operation to Submit. We saw this at a customer site: the write-back succeeded, but the document was auto-submitted for audit before downstream documents were ready, causing a chain reaction of rollbacks. The safer approach is Save + IsAutoSubmitAndAudit=false, leaving audit to the business team.
Missing KDFormId fails the whole batch silently. FormId is the entry point for Kingdee to locate the master type; when it's missing, batchSave returns an error but no per-row detail. Put a null-value check in front of it in Qeasy.
Trailing whitespace in wmsbh. Numbers exported from WMS sometimes carry invisible characters. Once they're written into a Kingdee custom field, cleaning them up in bulk is painful. We run a single trim() in the source response cleaning step.
Turning idCheck off causes silent misalignment in batch update. This is the easiest way to crash a write-back strategy: with strict checking off, wmsbh may be written to the wrong manufacturer without any error. For write-back strategies, idCheck must stay on.
Write-back success ≠ business effect. Kingdee sometimes needs a cache refresh for the custom field to display on documents, which can mislead the operator during troubleshooting.

When to use it, when not to

Use it when: both systems need to maintain a side-number on the same object and the ERP side has reserved a custom field; the WMS code is stable and rarely changes; or you need a "number-filling" fallback for the broader supply chain sync. Don't use it when: master data is owned by ERP and WMS is only a consumer; or wmsbh changes frequently on the WMS side and the ERP field length would force truncation.