Purchase Inbound Sync: A Single-Strategy Implementation from YiWeiMeng WMS to Kingdee Cloud

What This Strategy Solves

In a real pharmaceutical distribution project, purchase inbound receipts generated in the WMS need to be written back into Kingdee Cloud's inventory module, which then becomes the source of downstream financial postings and stock ledger updates. It looks like a simple "push-and-receive", but the actual trap we kept hitting was that foundational fields—posting date, organizations, supplier master—were not centrally mapped, so within three months the numbers on both sides stopped matching. This article walks through one concrete inbound strategy end-to-end: fields, flow, scheduling, and the pitfalls we learned the hard way.

Data Flow and Field Mapping

The overall direction is: WMS → Qeasy Integration Platform → Kingdee Cloud. On the source side, the WMS exposes an inResult API (POST/QUERY) that returns inbound results; on the target side, Kingdee's batchSave API (POST/EXECUTE) writes inbound documents in batch. The Qeasy middle layer does the field translation and also performs the lookups and backfills for organization, posting date, and document number.

Key field mapping table:

Note: Kingdee's FDate must not be filled with the WMS current timestamp, otherwise you get the classic "received today, posted yesterday" problem. Always use the actual WMS inbound timestamp.

How to Configure on Qeasy

On the Qeasy (轻易云数据集成平台) side, we split this strategy into two integration flows:

1. Source flow: pick the WMS adapter, choose the inResult API, leave the request body empty for a default full query, use zdzt as the filter, set a conservative page size (e.g., 200 per page), and enable bh as the idempotency key.
2. Target flow: pick the Kingdee Cloud adapter, choose batchSave, and configure the request fields per the table above. FBillNo references the source via {{wmsbh}}; FDate uses _findCollection against an intermediate table keyed by {{bh}}; organization-type fields go through Qeasy's encoding map, never hard-coded inside the strategy itself.
3. Orchestration: use Qeasy's strategy orchestrator to chain the two flows. Once the source flow finishes, it triggers the target flow; the target flow then writes back status to the intermediate table for downstream reconciliation.

Two patterns we routinely use on customer sites are worth highlighting. First, encoding mappings (organizations, suppliers, warehouses, materials) are all centralized in Qeasy's mapping center, so when a new organization goes live, no strategy body needs to change. Second, roll out header and lines in phases—get the header (document number, date, organization) running stably for one week before adding line details, which dramatically cuts first-time rollout risk.

Implementation Steps

We typically cut the rollout into three phases:

• Phase 1: Bootstrap (full trigger). The very first run uses a full-load mode to backfill historical in-transit inbound documents; schedule it in the low-peak window before dawn, then immediately switch to incremental mode.
• Phase 2: Incremental scheduling. The source runs a daily full reconciliation at night plus an incremental poll every 5–15 minutes; the target writes during business hours (e.g., every 5 minutes from 08:00–22:00), avoiding the financial closing window. Placeholder crons like the 1 1 1 1 1 shown in the source materials must be replaced with business-suitable expressions in production.
• Phase 3: Steady state. Turn on Qeasy's failure retry and alerting; run an end-of-day reconciliation job that compares document numbers and amounts between the two sides, with any diffs routed to a manual repair workflow.

Pitfalls and Lessons Learned

1. Wrong timezone on posting date. When the WMS and Kingdee servers sit in different timezones, new Date() produces an 8-hour drift. The safe pattern is to have the source include an explicit UTC+8 timestamp in the payload and let Qeasy skip timezone conversion.
2. Organization codes hard-coded inside the strategy. We once watched a new receiving org rollout force changes across every strategy. Correct pattern: organizations live in a mapping table; the strategy only references variables.
3. Idempotency key not enabled. Duplicate source pushes created duplicate documents in Kingdee. Always set bh as the idempotency key and enable duplicate-write validation on the target.
4. Too many line items in one call. Kingdee's batchSave has a per-call row limit; oversized batches get truncated. Slice the row count in Qeasy—keep each batch under 100 rows.
5. Ignoring the zdzt status filter. Unapproved WMS documents were also pushed, producing "draft-status" inbound documents in Kingdee. Only fetch approved inbound results on the source side.

When to Use and When Not to

This approach fits single-entity, private-cloud deployments where a WMS and ERP need to sync purchase inbound results in near real time, with daily volumes from a few thousand to tens of thousands of documents. It does not fit cross-entity, cross-book complex supply chain collaboration, nor is it recommended to cover a multi-org, multi-plant landscape with a single strategy—those scenarios need strategies split by organization, or a distributed integration hub with an intermediate database.