Practical Configuration for Incremental Push of Customer Master Data from Kingdee Cloud to WMS

What This Strategy Solves

In a supply-chain integration project at a pharmaceutical distribution enterprise, customer master data must be distributed from the source ERP (Kingdee Cloud) down to the WMS. Kingdee is the system of record; the WMS only receives, never writes back. If the customer code, name, or owning organization drifts between the two systems, downstream shipping, invoicing, and traceability all break. This strategy implements "incremental push of customer changes," keeping the WMS customer master in sync with Kingdee.

Data Flow and Field Mapping

The pipeline is Kingdee Cloud → Qeasy intermediate layer → WMS.

The source side calls Kingdee's executeBillQuery API (POST, QUERY type) to pull customer records incrementally; the time window is controlled by the Qeasy scheduler. The target side invokes the WMS unitChange API (POST, RESTful, EXECUTE type), with the unit type hard-coded as "Customer".

Key field mapping:

Centralized code mapping is a common pattern among Qeasy customers: keep the source-code-to-target-wmsbh mapping table in the intermediate layer. When source fields change, only the mapping needs updating, not the interfaces.

How to Configure on Qeasy

Source-side key points

• Select the executeBillQuery API, method=POST, effect=QUERY.
• Set the primary key to FNumber and turn on idCheck so changes are idempotent by code.
• Check FNumber, FName, FCreateOrgId.FNumber, FUseOrgId.FNumber in the request body; Qeasy will auto-build the request structure based on buildModel.
• Place the incremental filter on the source WHERE clause: filter by last-modified timestamp and organization.

Target-side key points

• Select the unitChange API, method=POST, effect=EXECUTE, set buildModel=false (parameters are fixed and maintained manually).
• Turn on idCheck, use bh as the idempotency key to avoid dirty data from duplicate pushes.
• Hard-code dwlx to "Customer" since this strategy only handles customer records.
• On first push, wmsbh=0 is assigned by the WMS; subsequent incremental pushes must first look up the existing wmsbh before sending.

Implementation Steps

1) Initialize the incremental baseline (full trigger) On first go-live, run a full load to push all active customer records into the WMS in one shot. On Qeasy, configure a manually-triggered full task: the source has no time window, and the target sends wmsbh=0 so the WMS deduplicates by bh. After completion, export the mapping table as the baseline for subsequent incremental runs.

2) Switch to incremental scheduling Set the source crontab to */10 8-22 * * * (every 10 minutes during business hours) and the target crontab to 4-59/10 8-22 * * * so the two ends don't contend for the same second. The incremental filter uses the last-modified timestamp so each round only pulls changes.

3) Recycle the returned id Before each incremental run, run a lightweight query to pull the wmsbh values back into the intermediate mapping table. That way the next push carries the real WMS primary key, so the API goes UPDATE instead of INSERT.

4) Retry and alerting Enable failure retry on the Qeasy side (recommend 3 attempts with exponential backoff). Records exceeding the threshold fall into an exception queue for manual review and replay.

Lessons Learned

1. Code mapping not centralized — A typical mistake is writing FNumber → bh translation inline in every strategy. Three months later, changing one code means hunting through dozens of places. The safer approach is a single mapping table in the intermediate layer; every strategy that references customer codes reads from it.

2. Wrong incremental start time — If you start incremental sync with "midnight today," all customer changes before that moment are lost. Always run a full load first, then switch to incremental.

3. wmsbh return not handled — On first push wmsbh=0 is assigned by the WMS. But if subsequent incremental pushes don't look up wmsbh first, the target will INSERT duplicate records. The safe approach is "look up before push": in Qeasy's pre-write hook, query wmsbh by bh first.

4. Organization dimension mismatch — Kingdee has both "create org" and "use org"; the WMS only has warehouse-level organization. Before mapping use-org into a WMS default org, confirm with the business who is responsible for invoicing — otherwise downstream documents lose their owning org.

5. Schedule clashing with business peaks — 8-22 is a reasonable business window, but check whether the WMS runs nightly batch jobs. If so, schedule around them, or you'll hit lock-timeout errors.

Applicable vs. Not Applicable

Applicable: Customer master data is pushed one-way from ERP to WMS/OMS/TMS, needs incremental consistency, and organization dimensions can be collapsed into a single mapping.

Not applicable: Customer records must be synchronized bi-directionally (e.g., new customers created in WMS must flow back to ERP), or customer records carry many custom fields that need approval workflow — the latter should be handled by a master-data governance platform, not direct API sync.