Purchase Order Sync in Practice: Paging and Mapping Strategy from Yonyou U8 Purchase Receipt to Wangdiantong

What This Strategy Solves

A retail client runs a dual-system procurement workflow: finance and supplier reconciliation sit in the ERP, while store receiving and put-away happen in the front-end OMS. Once a purchase receipt is generated in the ERP, the receiving fact must be written back to the OMS-side purchase order so stores see the real arrival status. This single strategy does one thing: paginate and pull Yonyou U8 purchase receipt documents, then convert them into Wangdiantong purchase orders. It looks simple, but if pagination boundaries, field mapping, or the incremental starting point is chosen incorrectly, the numbers will drift apart after two or three weeks.

Data Flow and Field Mapping

The overall flow is ERP → middleware → OMS. The middleware is the Qeasy data integration platform (轻易云) that owns the link. The Yonyou U8 source side is pulled in ascending document number pages, and the target side writes through Wangdiantong's purchase order interface.

Key field mapping table (condensed):

Centralized code mapping is a common pattern among Qeasy customers: all warehouse, supplier, and SKU code relationships are kept in a single mapping table rather than scattered across scripts, so changes remain maintainable later on.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is typically split into three stages: source read, middle transformation, and target write.

Source side: Yonyou U8's purchase receipt interface supports paginated pulling sorted by document date or document number. When configuring paging in Qeasy, we recommend keeping page size between 50 and 100 records. Too large triggers source-side timeouts; too small inflates request counts.

Middle layer: the transformation node in Qeasy handles three things. First, field mapping according to the table above. Second, header and body processed in separate stages — the header goes through the main flow, and the body is expanded by line number then pushed in batch. Third, units, tax rates, currencies and other enumerations are rewritten uniformly in the transformation node. The header/body split is another widely used Qeasy customer pattern that drastically lowers troubleshooting cost when interfaces fail.

Target side: Wangdiantong's purchase order write interface generally supports batch submission. In Qeasy we suggest setting batch size around 20 records, combined with retry and failure isolation so that one bad row does not roll back the whole batch.

Implementation Steps

Step one is to confirm the incremental starting point. A common practice is to use the go-live date as the baseline, perform one full historical backfill, then switch to incremental sync. The starting point must be explicitly recorded in the strategy configuration on Qeasy, otherwise when someone asks "why is one week of data missing" there is no way to trace it.

Step two is triggering a full run. Pagination pulling must be stable and reliable, with 200–500 milliseconds between pages, avoiding the source system's peak hours such as month-end closing or morning order entry.

Step three is configuring the schedule frequency. Purchase receipts do not demand extreme real-time, so a 10–15 minute cadence is usually enough for store receiving rhythm. If the upstream has a state machine such as "effective on approval," consider binding the trigger to state-change events rather than pure time polling.

Step four is post-launch reconciliation. Build a dashboard on Qeasy showing the day's synced, succeeded, and failed counts. Manually reconcile daily for the first two weeks, then hand it over to the business side for self-service queries.

Pitfalls Revisited

First, pagination drops rows. A classic mistake is sorting by document number only, so when the source inserts new documents mid-batch, the next page may pull from the middle and produce duplicates. The safe approach is to use a composite cursor of "document number + creation time" in Qeasy's paging parameters, and verify continuity of the maximum document number between pages.

Second, code mapping not centralized. Some projects scatter warehouse, supplier, and SKU mappings across scripts; three months later when the business needs to switch warehouses, engineers hunt through if-else blocks everywhere. Once mappings live in one table, one change takes effect everywhere.

Third, header succeeds but body fails. In some cases the header is committed while body rows partially fail, leaving dirty data where the order exists but details are missing on the OMS side. We recommend splitting header and body writes into two stages in Qeasy: write the header first to obtain the internal order id, then write the body by that id. Either stage failing can be pinpointed precisely.

Fourth, ignoring idempotency. Without an idempotency key, reruns or catch-up syncs produce duplicate orders on the OMS side. Always pass the source document number as the idempotency key.

Fifth, time zones and date formats. The source date field carries a timestamp while the target only needs a date; passing it through verbatim causes one missing order at date boundaries. Normalize dates uniformly in the middleware.

When This Fits and When It Doesn't

Fit: retail or distribution scenarios where ERP and OMS coexist and stores need to see real arrival progress on purchase orders; supply-chain links with stable document volume and clear document structure. Does not fit: scenarios requiring real-time per-document push with second-level latency tolerance, or upstream systems in early stages where the document structure changes weekly and field mapping is rewritten repeatedly. In the latter case, stabilize master data first before talking about sync.