VMI Transfer-Inbound Mapped to Purchase Orders: A Single-Strategy Integration Walkthrough from Jky to Kingdee Cloud

What this strategy solves

In a VMI (Vendor Managed Inventory) setup, transfer-inbound documents must stay consistent across systems: the source system records the physical transfer and inbound, while the target system wants to carry the same business as a purchase order so that receiving, invoicing, and payment can flow naturally. A common field requirement is to pull VMI transfer-inbound documents from the source system incrementally by a time window and write them into the target system as purchase orders, with auto push-down enabled. It looks like a trivial sync, but if cross-system codes, organizations, and supplier master data are not aligned, the two ledgers will not reconcile after three months — that is what we see again and again on customer sites.

Data flow and field mapping

End-to-end flow: Source ERP → Qeasy middleware → Target ERP. The source side is queried with paging by inbound document number and creation time, while the target side is written through the batchSave API as a purchase order header plus its line entries.

Key field mapping:

The supplier and purchase-organization columns are where things typically break: a "warehouse code" on the source side must be interpreted as a "supplier profile" on the target side, so the middleware has to perform one semantic conversion.

How to configure it on the Qeasy platform

The source side uses a QUERY WebAPI (POST). Paging parameters pageIndex and pageSize are fixed, the time window is built from {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}, and the document number goodsDocNo is used as the idempotency key written into the middleware. idCheck=true prevents duplicate loads from being persisted twice.

The target side uses an EXECUTE WebAPI (POST) that calls batchSave, sending the header fields and the line entries FPOOrderEntry in a single payload. We usually recommend that customers keep all code mappings (warehouse→supplier, organization mapping, document-type mapping) in a centralized mapping table on the Qeasy platform rather than hard-coding them in scripts — when business rules change after go-live, only one place needs editing.

Implementation steps

Roll out in three phases to avoid hammering the target system with a full sync on day one:

1. Align the incremental start point. Before the first run, set LAST_SYNC_TIME to the agreed historical cutoff, do a cold start, and confirm that the source side returns data and the target side accepts it.
2. Backfill the full history. After the cold start succeeds, switch to full mode to backfill historical documents; during this phase, watch closely the target write performance and any organization or supplier validation errors.
3. Steady-state scheduling. The source cron is set to 9 6-23/2 * * * (minute 9 past every 2 hours from 06:00 to 23:00), and the target cron to 55 */2 * * * (minute 55 past every 2 hours). The two ends run offset, leaving the middleware a buffer window to handle abnormal documents.

Lessons learned from the field

• Classic mistake #1: writing the source warehouse code directly as the target supplier. The source side is a logistics concept, the target side is a business concept — a semantic conversion must happen in the middleware. The safe pattern is to maintain the mapping explicitly in the Qeasy mapping table and add a fallback that routes unmapped records to an exception queue.
• Classic mistake #2: time windows are passed in local time, causing missing records across time zones. Always make the time zone explicit for startDate / endDate on the source side; a clean approach is to normalize both ends to a single time zone inside the Qeasy platform.
• Classic mistake #3: quantity, price, and unit are mixed inside the same JSON node on the source side without being split out. The target FPOOrderEntry requires structured fields; the source returns a nested array, so the middleware must flatten it and validate non-null values before writing.
• Classic mistake #4: Fisautopush=true is left on throughout, so dirty data during debugging also gets pushed down. A safer pattern during early go-live is to keep auto push-down off until you are confident, then turn it on.
• Classic mistake #5: the source uses pageSize=50, but the target batchSave accepts fewer lines per call. The robust approach is a header-then-lines phased flow: write the header first, capture the returned FBillNo, then fill the lines and write again. The Qeasy orchestrator handles this two-stage flow naturally — a common pattern we use with customers.

When to use it and when not to

Use it when the source has well-formed VMI transfer-inbound documents, the target wants to host them as purchase orders, and both sides have clear master-data profiles. Do not use it when the source document status is highly unstable and needs complex judgement, when the target requires an approval workflow before a document can be persisted, or when cross-entity scenarios require organizational isolation before sync — those cases are better served by a combination of multiple strategies rather than a single sync.