Purchase Inbound to Purchase Order Sync: U8 to Wangdiantong Pagination Practice
What This Strategy Solves
In a supply chain integration scenario for a retail enterprise, purchase inbound documents are already entered on the ERP side (Yongyou U8), and the front-end OMS (Wangdiantong) needs to receive these documents to drive inbound verification and document association. It may look like just "passing a document through," but in practice it hits three typical problems: paginated fetching, incremental starting points, and code mapping. The goal of this strategy is to take the paginated purchase inbound output from U8, transform it into a structured purchase order on the Wangdiantong side, and erase the implicit "page state" in the middle layer so that reconciliation only deals with business fields.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The overall flow is Yongyou U8 (purchase inbound, paginated) → Qeasy (Qingyi Cloud) middle layer → Wangdiantong OMS (purchase order). The source is pulled page by page; the middle layer handles deduplication, aggregation, code mapping, and field renaming; the target only sees a "clean purchase order structure."
Key field mapping (based on common conventions we have seen at customer sites; actual fields depend on each side's API):
| Business Meaning | U8 Purchase Inbound (Source) | Middle Layer (Qeasy) | Wangdiantong OMS Purchase Order (Target) |
|---|---|---|---|
| Document No. | ccode / djbh | doc_no (unified string) | outer_order_no |
| Document Date | ddate | biz_date (YYYY-MM-DD) | order_time |
| Supplier Code | cvencode | vendor_code (unified) | supplier_code |
| Warehouse Code | cwhcode | warehouse_code | warehouse_id |
| SKU Code | cinvcode | sku_code | goods_no |
| Quantity | iquantity | qty (unified positive) | purchase_num |
| Unit Price | iprice | price | unit_price |
| Remark | cmemo | remark | remark |
A few additional notes. First, the source is paginated; page number, page size, and has-next are "page state fields" that should not flow into the target. The middle layer consumes them and converts them into a unified doc_no + biz_date primary key. Second, supplier and SKU codes follow different systems on each side and must be mapped in the middle layer. We recommend maintaining mappings centrally rather than scattering them across strategies — this is a common pattern among Qeasy customers, called centralized code mapping management. Third, document sync usually has a header + body structure. We recommend handling header and body in stages: land the header first, confirm supplier and warehouse match, then push the body — this reduces half-baked documents.
How to Configure It on Qeasy
When configuring this strategy on the Qeasy data integration platform, we suggest the following:
- Source adapter: choose U8's query interface, enable pagination parameters (page number, page size), and define a termination condition — either "max page count" or "by time increment."
- Data cleansing and mapping: use Qeasy's "field mapping" node for the table above, and reference a centralized mapping dictionary via a "lookup table" node for supplier/SKU codes.
- Primary key and deduplication: use
doc_no + sku_codeas the composite key, combined with Qeasy's "deduplication" node, to avoid duplicate pushes at pagination boundaries. - Target write: call Wangdiantong's purchase order creation API in two calls — header first, then body (many customers get tripped up trying to push the whole document in one shot).
- Exception handling: enable Qeasy's retry and alerting. Classify "document already exists" and "unmapped code" as separate error types — skip the former and route the latter back to the mapping owner.
Implementation Steps (Phased Scheduling)
We generally proceed in three steps at customer sites:
- Step 1: Determine the incremental starting point. On the first run, we recommend a full trigger to pull all existing purchase inbound documents by document date. Once done, store "max document date + document no." as the watermark and switch to incremental scheduling.
- Step 2: Set scheduling frequency. Purchase inbound documents usually need to appear in the OMS shortly after the business event; we suggest every 5–15 minutes. Qeasy's strategy scheduler supports both cron and event triggers; for this business flow, use cron together with the source's "by modification time" parameter.
- Step 3: Incremental + full dual track. Daily incremental runs handle the live stream, while a "full reconciliation" switch (e.g., a full run during the early-morning lull) catches missed increments. This dual-track pattern is also common among Qeasy customers.
Lessons Learned
- Pitfall 1: Pagination boundary duplicates. When pulling by page, if the last page is exactly full, the first row of the next page can be pulled twice. The reliable approach is to use
(biz_date, doc_no)as a strictly increasing watermark; let pagination fetch only, and let the middle layer deduplicate by primary key. - Pitfall 2: Misaligned incremental start. If the first increment uses a "today" watermark, the full initialization afterwards can overwrite that day's data. The reliable approach: run the full stage to completion, then switch to increment, and snapshot the "current max watermark" at the moment of switch.
- Pitfall 3: Code mapping scattered across strategies. Within one enterprise, supplier/SKU mapping should have a single source of truth; do not maintain it separately in each strategy, or reconciliation will fail three months later.
- Pitfall 4: Pushing header + body in one shot. A typical mistake is concatenating header and body into one large JSON and POSTing it; any field error then fails the whole document. Push in stages — header first, body second — so rollback only affects one segment.
- Pitfall 5: Ignoring "already exists" semantics. Purchase orders on the OMS may have been partially written back; on resync, "document already exists" should be handled as business idempotency, not as a hard error.
When It Fits and When It Doesn't
Fits: document-type master or transactional data pushed from ERP to OMS, requiring paginated fetching, with well-specified APIs on both sides, and where incremental scheduling with full reconciliation as a fallback is acceptable. Does not fit: scenarios requiring real-time sub-second sync (e.g., POS receipts flowing into ERP instantly), where no mapping rules exist between the two systems, or where document structures differ so much that manual intervention is unavoidable — those cases are better served by real-time event streams or human coordination channels.