Purchase Order Sync in Practice: Link Design and Pitfall Guide from WDT to Kingdee Cloud
What This Strategy Solves
A retail enterprise uses one system for front-end store and procurement collaboration, and another for back-end finance and supply chain settlement. Hundreds of purchase orders flow between them every day. Manual export is slow and error-prone; after three months, quantities and amounts on both sides often fail to match. Handing this link to the Qeasy data integration platform for automatic sync narrows the problem to a single strategy: purchase orders flow from the front-end system into the back-end ERP, accurately, stably, and traceably.
Data Flow and Field Mapping
The source is the front-end system's purchase order (the interface typically uses "purchase order" or "goods receipt", depending on enterprise configuration). The data passes through Qeasy's standardization layer and lands on the target ERP's purchase order document. Key field mapping is as follows:
| Business Meaning | Source Field | Target Field | Handling Notes |
|---|---|---|---|
| Document No. | order_no | FBillNo | Strip prefixes to avoid conflicts with existing target numbers |
| Supplier Code | supplier_code | FSupplierId | Resolve via supplier master mapping; target must exist |
| Warehouse Code | warehouse_code | FStockId | Warehouse master must be synced in advance |
| SKU Code | sku_code | FMaterialId | Material master must be completed before this strategy |
| Quantity | qty | FQty | Use base unit strictly; no conversion |
| Unit Price | price | FPrice | Tax-inclusive flag must align with target tax fields |
| Expected Arrival | expect_date | FDeliveryDate | Unify date format to yyyy-MM-dd |
| Remarks | remark | FNote | Truncate overlong strings |
Qeasy's centralized code mapping is the ballast at this step: supplier, warehouse, and material codes are maintained in one place, and downstream strategies (goods receipt, payment, etc.) reuse them directly—no reinventing the wheel.
How to Configure on Qeasy
Enter strategy editing; there are four typical configuration points:
- Source interface selection: Pick the front-end purchase order query interface, define return fields, and filter out deleted orders.
- Target interface selection: The target ERP's "Save Purchase Order" interface. Confirm with the enterprise version whether header + entries are submitted in one call, or save-then-audit.
- Field mapping table: In Qeasy's mapping canvas, drag source fields to target fields, attach conversion functions as needed (date formatting, string truncation, numeric rounding).
- Validation and failure retry: Enable non-null validation, enum validation, and duplicate document-no blocking; failed tasks enter a retry queue with exponential backoff, and alerts go to enterprise IM when thresholds are exceeded.
Implementation Steps
In one real project, we split the rollout into three phases:
- Phase 1: Materials and suppliers first. This strategy depends on material and supplier masters being in place, so run the master-data strategies until stable, observe for 1–2 days with no exceptions, then enable purchase order sync.
- Phase 2: One-shot full-volume backfill. On the go-live night, run a one-time full-volume backfill covering the past 30 days to flatten in-flight unsettled orders. Switch to incremental mode immediately after—avoid repeated pulls.
- Phase 3: Scheduling frequency and windows. Incremental runs every 5 minutes, polling the source for changed orders; during off-peak hours (e.g., early morning), run a reconciliation patrol that compares both sides' document status and routes discrepancies into work orders. This is the common "incremental + full-volume dual-track" pattern among Qeasy customers.
Pitfall Review
- Dependency order reversed. We enabled purchase order sync directly and got floods of "material not found" errors. The safer approach is to declare upstream strategies explicitly in the dependency config; Qeasy will block and warn when the order is wrong.
- Unit conversion done on both sides. The same batch showed up as 12 boxes vs. 144 bottles. We decided to use base units only on the source and skip conversion on the target—problem vanished.
- Tax-inclusive flag left unclear. A reconciliation was off by a few hundred; the root cause was one side defaulting to tax-inclusive and the other to tax-exclusive. Mapping must pin down the tax-field source, and the conversion script must state the calculation rule clearly.
- Document number conflicts. The target ERP has its own numbering rule; passing the source's order_no directly triggers "document number already exists". Add a prefix on the source side (e.g., business-domain abbreviation) and validate the number range on the target side.
- Ignoring change orders. The source allows quantity and arrival-date changes; syncing only new orders causes in-flight data on the target to drift. When configuring, be sure to bring "change order" or "status change" events into the incremental pull scope.
Applicable and Non-Applicable Scenarios
Applicable: Enterprises using one system for procurement collaboration and another for finance and supply chain settlement; daily order volume from tens to hundreds, requiring near-real-time sync; existing master-data (material, supplier, warehouse) sync already in production.
Not applicable: Either side has not completed master-data initialization; document state machines differ widely (e.g., the source's "shipped" has no equivalent on the target); or scenarios where real-time needs are below minute-level and small enough that manual export is more cost-effective.