Purchase Order Sync in Practice: End-to-End Delivery from WMS to UFIDA BIP
What This Strategy Solves
In a retail supply chain, purchase orders are typically created in the upstream commerce platform — store replenishment, category restocks, and ad-hoc transfers all start there. But the financial posting, payment clearing, and receiving accounting must live in the downstream ERP. Once the two diverge, purchasing, warehouse, and finance start arguing in circles.
Our job is to push purchase orders from the upstream system to the ERP, with the Qeasy integration platform acting as the middle layer — handling data movement, code translation, and exception routing.
Data Flow and Field Mapping
The flow is straightforward: Source (upstream commerce platform) → Middle layer (Qeasy integration platform) → Target (downstream ERP).
Header field mapping:
| Business meaning | Source field | Target field | Conversion notes |
|---|---|---|---|
| Document number | order_no | vbillcode | Pass-through, add prefix if needed |
| Vendor | supplier_code | vendor_code | Maintain vendor map in Qeasy |
| Warehouse | warehouse_code | warehouseid | Centralized code mapping |
| Document date | order_date | dbilldate | Normalize to yyyy-MM-dd |
| Operator | creator | creatorid | Pre-map personnel archive ID |
| Remarks | remark | vmemo | Truncate to target length |
Line-item field mapping:
| Business meaning | Source field | Target field | Conversion notes |
|---|---|---|---|
| Material code | sku_code | materialcode | Unify coding differences |
| Quantity | qty | nnum | Align precision to target |
| Tax-included price | price_tax | norigprice | Lock rounding rules |
| Tax-included amount | amount_tax | norigtaxprice | Post amount directly |
| Tax rate | tax_rate | ntaxrate | Percent ↔ decimal |
Configuring on Qeasy
We typically split the configuration into three blocks:
1. Source extraction. Use the Qeasy adapter for the upstream platform to pull both the order header and line items. The filter is normally status = approved, so only valid documents flow downstream.
2. Middle-layer mapping and cleansing. Code mapping, field renaming, length truncation, and default-value filling all happen here. Qeasy provides a visual field-mapping view. Primary keys that almost never match across systems — material, vendor, organization codes — should go through a centralized code-mapping table, not be scattered across strategies. Maintenance becomes much easier later.
3. Target write. Call the ERP's order save/audit interface. A common pattern on customer sites is phased delivery: first do save-only (draft), then layer in auto-audit once stability is proven. When audit fails, the blast radius explodes.
Implementation Steps
We usually push in four phases:
Phase 1: Full backfill (cold start). Push all historically approved purchase orders in one shot, with a time window (e.g. last 3 months) for initial reconciliation. Full backfill is normally triggered manually through a Qeasy batch task, not by the scheduler.
Phase 2: Align the incremental start point. Determine the incremental start timestamp, usually the moment the full backfill ends; use update_time as the incremental cursor to avoid missing documents. This point must be jointly confirmed by both IT teams and recorded — it is the anchor for every future investigation.
Phase 3: Bring up the schedule. Purchase orders do not demand real-time; a safe choice is every 15–30 minutes. Some customers push to 5 minutes, but only after observing source API pressure and target write throughput. Qeasy's scheduler supports cron expressions, retry, and alert routing out of the box.
Phase 4: Exception and rerun. Configure "failed-into-queue + auto-retry N times + over-threshold alert" in Qeasy, and write the failed target document numbers back into the source-side remarks so operators can chase them manually. This is the most overlooked but most critical piece on customer sites.
Pitfall Recap
- Code mapping scattered everywhere. When material/vendor/warehouse maps are written into every strategy, numbers diverge within three months and the team hunts for mapping rules across the platform. The safe practice is centralized code mapping — maintain once, reference everywhere.
- Full and incremental not separated. Mixing them means historical documents get pushed repeatedly, leading to duplicates or false dedup kills on the target. Full and incremental must run on two tracks — full runs once, incremental only watches the cursor afterwards.
- Audit automation activated too early. Letting Qeasy handle "save + audit" from day one means that any target-side field validation or approval-flow mismatch instantly amplifies errors. Save-only first; layer in audit after stabilization — the most valuable lesson in phased delivery.
- Wrong timestamp cursor. Some engineers, trying to save time, use
create_timeas the incremental cursor, which means downstream never sees documents that were modified after approval. For purchase orders,update_timeis required, and the source must agree on "approval counts as a modification." - Target-side rate limits ignored. The downstream ERP APIs generally have concurrency limits. Without explicit QPS caps and backoff strategies on the Qeasy write component, a batch trip on rate limiting will fail everything. Set the QPS cap explicitly.
When It Fits, and When It Does Not
Fits: Relatively standard document structure, source system where approval is terminal, and a target that exposes a stable write API.
Does not fit: Source systems with multi-level approval and frequent status rollback, or targets that need heavy customization to land a document. In those cases, finish interface adaptation first, then design the sync strategy.