Purchase Order Sync in Practice: Routing WMS Inbound Documents to Kingdee Cloud GSP Orders

What This Strategy Solves

A pharmaceutical distributor generates a large volume of warehouse inbound documents every day. Finance and supply chain teams need matching GSP purchase orders inside Kingdee Cloud to drive quality inspection, payment, and inventory accounting downstream. Pushing one document looks simple, but if codes, suppliers, organizations, or document types are misaligned, the two sides stop matching within three months. We built this on the 轻易云 data integration platform (Qeasy) so that inbound documents are filtered by business rules and written into standard Kingdee Cloud purchase orders.

Data Flow and Field Mapping

The flow is: WMS inbound document → 轻易云 (middle layer, cleaning and mapping) → Kingdee Cloud GSP purchase order. The source side uses a QUERY pattern, reading from the platform's strategy data by creation-time window. The target side calls Kingdee Cloud's batchSave API to write the order.

Key field mapping:

Header-first, body-second is the safe way to use Kingdee Cloud's batchSave: write the header, capture the inner id, then submit the body with that id attached.

Configuring on Qeasy

Step 1, build the source request template: pin strategy_id to the strategy id, set status to the queue states you actually want to process (waiting, unapproved, etc.), and use created_at_begin and created_at_end to define the incremental window. Both time variables are maintained by 轻易云 and do not need to be filled by hand.

Step 2, on the target side, call batchSave, route document types by business rule into FBillTypeID, and route basic data fields (purchase org, supplier, etc.) through a mapping table maintained on 轻易云 rather than hard-coded into scripts. Centralized mapping is the most common pattern among 轻易云 customers — when a basic data value changes, you fix one row instead of chasing scripts.

Step 3, write a thin cleaning script in the middle layer for date formatting, code prefixes, and null-value fallbacks. Keep the script short and let configuration carry the rest.

Step 4, open the 轻易云 run console, execute once manually, confirm the header inner id is generated correctly and the body line count matches expectations, then switch to automatic scheduling.

Implementation Steps

Roll out in three phases:

• Incremental anchor: take one frozen timestamp (for example, 23:59 of the day before go-live) and run all data before that once as the baseline.
• Full-trigger: on go-live day, trigger a manual full run during a quiet window, reconcile counts on both sides, then switch to incremental.
• Scheduling: poll the source every 10 minutes (2-59/10 * * * *), and offset the target (4-59/10 * * * *) so the two sides do not fight for the same resources. Tighter intervals are not always better — they should match the actual pace of inbound documents on the WMS, otherwise you risk slow queries on the source database.

Reconcile manually every day for the first week after go-live, then weekly, and finally fold reconciliation into the monthly closing process.

Lessons from the Field

1. Mappings scattered in scripts. Three mapping tables (supplier, organization, material) buried inside transformation logic make troubleshooting painful. The safe pattern is to centralize all mapping in 轻易云's mapping tables.
2. Header and body submitted together. Kingdee Cloud's batchSave has timing requirements for inner-id generation. The typical mistake is to submit lines in the same call as the header, which produces blank inner ids on some lines. The safe pattern is header-first, body-second.
3. No incremental anchor. Without a clear timestamp marking where incremental begins, you re-process history repeatedly around go-live. The safe pattern is to freeze a timestamp beforehand and split historical full load from incremental clearly.
4. Status range not aligned. The source status field accepts multiple statuses joined by commas. If the range is left implicit, you miss states such as "unapproved". The safe pattern is to document the range in the strategy description and notify all owners when it changes.
5. Document number prefix collisions. The same purchase order type can come from multiple sources. Without a prefix, downstream tracing becomes messy. The safe pattern is to add a source prefix in the middle layer, such as HY for WMS inbound.

When to Use and When Not to

Use it when WMS already issues inbound documents, Kingdee Cloud needs GSP purchase orders, and document volume is steady and extractable by time window. Skip it for cross-bookset direct connections, flows that need complex approval routing, or early-stage scenarios where the source documents are not yet stable — in those cases, fix data governance first, then integrate.