Practical Guide: Syncing Kingdee Cloud Purchase Inbound Orders to WMS Fast Inbound Orders

What This Strategy Solves

A retail enterprise runs Kingdee Cloud as its ERP and a WMS for warehouse execution. After goods arrive, the warehouse needs to perform fast inbound receiving in the WMS, but the upstream purchase inbound order has already been posted in Kingdee Cloud. Re-entering the document manually in the WMS is slow and error-prone—once quantity, unit, or batch number is mistyped, every downstream inventory and finance reconciliation is affected. This strategy incrementally pushes Kingdee Cloud purchase inbound orders to the WMS fast inbound interface, so the WMS receives upstream documents and generates inbound tasks directly. The effect is "post upstream, receive downstream"—without retyping.

Data Flow and Field Mapping

The overall flow is: Kingdee Cloud (source) → Qeasy Data Integration Platform (middleware, responsible for extraction, transformation, and scheduling) → WMS (target).

On the source side, purchase inbound orders are fetched from Kingdee Cloud via executeBillQuery, filtered to approved documents and pulled incrementally. The middleware performs field mapping, organization validation, and ID composition. On the target side, the WMS /inOrders/v4/fast_1 endpoint is called to write fast inbound orders.

Key field mapping:

Code mapping is the lifeline of this integration. The three code sets—organization, warehouse, and owner—must be maintained centrally. Any inconsistency will cause downstream inbound failures. We usually place the mapping table in Qeasy's code-mapping module so a single edit takes effect everywhere.

How to Configure in Qeasy

In the Qeasy Data Integration Platform, this strategy is configured as a source integration linked to a target integration.

Source configuration:

• API: executeBillQuery, method POST, effect QUERY.
• Filter only documents where FDocumentStatus = 'A' and FStockOrgId.FNumber belongs to a specified set.
• Use FInStockEntry_FEntryId as the line ID, FBillNo as the document number.
• Enable incremental watermark and paginate by last-modified time.

Target configuration:

• API: /inOrders/v4/fast_1, method POST, effect EXECUTE.
• idCheck = true to prevent duplicate writes.
• orderItems is an array field bound to the source detail collection.
• Warehouse code and owner code are replaced automatically via code mapping.

The middleware uses Qeasy's field mapping and script nodes to compose Kingdee Cloud's two-dimensional detail rows into the orderItems JSON expected by the WMS. Typical processing: map the material code, quantity, and unit from FInStockEntry to the WMS's SKU, qty, and uom; map Kingdee Cloud's batch field to the WMS's batchNo.

Implementation Steps

We split this strategy into three phases to avoid the chaos of a single cutover.

Phase 1: Full backfill, baseline reconciliation. After deployment, run a one-shot job to push all purchase inbound orders from a recent window to the WMS and align both sides. Do not enable scheduling yet—run once, then have staff spot-check several documents.

Phase 2: Incremental start, low-traffic validation. Set the source watermark to a historical point in time, schedule hourly (crontab: 0-59/60 * * * *), and observe for two to three hours. On the WMS side, assign warehouse staff to verify inbound tasks are generated correctly.

Phase 3: Stable operation, higher frequency. Once confirmed, raise the frequency to every five minutes (crontab: 3-59/5 * * * *), offset from the hour to avoid peak load on the source system. Note that the leading 3 is the start offset in minutes—it staggers target-side polling away from source-side polling to reduce pressure on both.

After go-live, keep a parallel run period of at least one week: the WMS still allows manually created inbound orders while upstream-pushed orders also flow in. Once the business side confirms full alignment, close the manual entry.

Lessons Learned from the Field

1. Code mapping scattered across strategies; one fix, one forgotten. A typical mistake is maintaining a separate warehouse code table inside every integration strategy. Later, after an org change, strategy A is updated but strategy B is not—and three months later the numbers on both sides no longer match. The safe approach is to use Qeasy's centralized mapping module so all strategies share a single code table.

2. Header and body pushed together cause WMS detail-format errors. Kingdee's inbound order has a header-plus-entries structure. Pushing it flat leaves the WMS orderItems array missing fields. The safe approach is staged assembly: write the header first, then loop through entries, or have the middleware script pack the entries into a JSON array before the single write.

3. Wrong incremental watermark causes old orders to be re-pushed. On the first scheduling setup, if the watermark start is left empty, the platform pulls from the beginning by default and re-sends every historical order—flooding the WMS with duplicate inbound tasks. The safe approach is to explicitly specify a go-live point in time as the watermark start.

4. Scheduling collisions spike pressure on the source system. When both source and target poll on the hour, two strategies fire in the same minute and Kingdee's interface queue backs up. The simplest effective fix is offsetting the start minutes of the two crontab entries.

5. WMS-side idCheck left off, leading to duplicate inbound. On retry after a push failure, the WMS does not deduplicate by line ID, and the same inbound order appears twice in the WMS. The safe approach is to set idCheck = true on the target side so the WMS deduplicates by id.

When to Use and When Not to Use

Use when: deployment is private, Kingdee Cloud is the ERP, the WMS is the warehouse executor, and purchase inbound orders need to trigger downstream inbound tasks quickly. Do not use when: cross-legal-entity scenarios, cases where the WMS must perform receiving and quality inspection before posting back to the ERP, or any reverse sync that writes the WMS actual-received quantity back to the ERP—that needs a separate strategy and cannot reuse this design.