Practical Tutorial: Syncing Kingdee Receipt Notices to Wangdiantong Purchase Orders
What This Strategy Solves
In supply-chain system integration, a "receipt notice" in Kingdee Cloud Galaxy and an "external-warehouse purchase order" in Wangdiantong are usually two views of the same business event. A typical real-world scenario: the buyer raises a purchase order in Kingdee, receives goods, and generates a receipt notice — but actual warehousing and settlement are performed by an external warehouse operator in Wangdiantong. This means material codes, quantities, and batch information from the Kingdee receipt notice must reliably land as an external-warehouse purchase order in Wangdiantong. If the two sides drift, external-warehouse receiving becomes chaotic and financial reconciliation stalls, and the business grinds to a halt.
We use the Qeasy data integration platform to carry this link. The core value is: convert Kingdee receipt notices into Wangdiantong "external-warehouse" purchase orders according to defined rules, while keeping codes, quantities, and batch conventions consistent on both sides.
Data Flow and Field Mapping
The overall flow is a one-way sync: Kingdee Cloud Galaxy (receipt notice) → Qeasy middle layer (clean, map, fill) → Wangdiantong (external-warehouse purchase order).
The middle layer does not persist business data; it only transforms. Key field mapping is shown below:
| Business Meaning | Kingdee Cloud Galaxy (Source) | Wangdiantong (Target) | Mapping Handling |
|---|---|---|---|
| Document number | Receipt notice number | Purchase order number | Carry over with a prefix to avoid collisions |
| Business date | Business date | Order date | Direct mapping |
| Supplier | Supplier code | Supplier code | Centrally managed code mapping |
| Warehouse | Receipt warehouse | External-warehouse code | Fixed value + code table |
| Material code | Material code | Product code | Centrally managed code mapping |
| Received quantity | Actual received quantity | Purchase quantity | Direct mapping |
| Batch | Batch number | Batch number | Direct mapping |
| Unit price (tax-incl.) | Tax-included unit price | Purchase unit price | Direct mapping |
Material codes usually differ between the two systems. We adopt "centrally managed code mapping" — the mapping table is maintained in a Qeasy dataset, so adding materials or changing codes only requires editing one place, avoiding scattered hard-coded values.
How to Configure on Qeasy
When configuring this strategy on Qeasy, we follow a three-stage pattern: source ingestion → transformation → target write.
-
Source ingestion (Kingdee Cloud Galaxy): Use the Kingdee Cloud Galaxy connector in Qeasy to configure the account set, and use the incremental interface to pull receipt notices by "last-modified time". Make sure to enable an "approved" filter so draft documents are not pushed through.
-
Middle transformation: In the Qeasy "data transformation" node, perform three things: field mapping, code mapping (materials, suppliers, warehouses), and constant-field filling (for example, order type fixed as "external-warehouse purchase order"). This stage usually uses visual mapping plus a few script expressions, which makes later maintenance easier.
-
Target write (Wangdiantong): Use the Wangdiantong connector to call its purchase-order creation API, applying a "header + lines" staged submission — first create the header to obtain the Wangdiantong-side purchase order number, then write the lines one by one. This staged approach is a common pattern among Qeasy customers and prevents a single failing line from rolling back the entire document.
Implementation Steps
We recommend going live in stages: "incremental starting point → full-trigger → scheduling frequency".
Step 1: Define the incremental starting point. Use the most recent successful integration timestamp from the customer's production environment as the initial cursor, to avoid flooding the pipeline with months of historical data. This cursor must be persisted in a Qeasy "state recording" node, which is what makes resume-on-failure work.
Step 2: Run one full backfill. Before go-live, do a full backfill in the test environment. The purpose is to validate code mapping, field conventions, and inventory organizations. This is the step that most often goes wrong at customer sites — only when a full run is clean do we switch to production.
Step 3: Enter the scheduling frequency. We recommend an incremental run every 10–15 minutes, plus an overnight reconciliation catch-up. This "incremental + full dual-track" mode is also a stable pattern frequently used by Qeasy customers: high-frequency incremental during the day for timeliness, and a full backfill at night as a safety net.
Step 4: Monitor for one week after go-live. Focus on discard rate, empty-field rate, and Wangdiantong-side rejection reasons.
Pitfall Recap
Pitfall 1: Draft documents also get synced. Kingdee receipt notices have both "saved" and "approved" states. If you do not filter on approved at the source, unapproved documents will be pushed to Wangdiantong, causing external-warehouse receiving to happen while the Kingdee-side document is later cancelled — the two sides then contradict each other. Stable practice: always add a status filter on the source interface.
Pitfall 2: One material maps to many products. A Kingdee material may be linked to two Wangdiantong products (for example, different packaging specs), and naive mapping will scramble quantities. Stable practice: in the mapping table, use a composite key of "Kingdee material + receipt warehouse" to uniquely locate the target, instead of a single-field mapping.
Pitfall 3: Whole-document submission causes one bad line to roll everything back. Submitting the header plus all lines in one call means a single malformed batch number can fail the entire document, and any Wangdiantong-side order number already generated has to be cleaned up manually. Stable practice: submit header and lines in stages, line by line, with separate alerts for failed lines.
Pitfall 4: No incremental starting point set, so the first run pulls a year of historical data. This has happened more than once at customer sites. Stable practice: the incremental starting point must be explicitly specified, and even the first full run should be split into chunks rather than dumped all at once.
When It Applies and When It Does Not
Applies to: Private-deployment projects where Kingdee handles purchase orders and receiving, while Wangdiantong handles external-warehouse inbound and settlement; stable document structure, materials in the tens of thousands, and T+1 reconciliation timeliness.
Does not apply to: Wangdiantong also serving as the main warehouse; Kingdee-side receipt notices being frequently revised; sub-second real-time requirements (this strategy runs on a 10–15-minute schedule); complex bidirectional business — this strategy is one-way sync only.