Purchase Receipt Flatten Sync: From Yonyou U8 to Wangdiantong

What This Strategy Solves

In the supply chain of a retail enterprise, ERP-side purchase receipts and OMS-side purchase orders have long been two sets of conventions and two sets of numbers. The warehouse finishes receiving in U8, finance books by U8 document number; but OMS needs an independent purchase order to drive subsequent receiving acceptance and shipping. Manual export and re-entry never lasts three months before the two sides disagree—this is the most common complaint we hear on customer sites.

The core value of this strategy is to flatten U8's receipt (with multi-line details) into an OMS purchase order header plus detail lines, pulled and written automatically by Qeasy on a schedule, eliminating manual steps and curing the chronic "two sides disagree" problem once and for all.

Data Flow and Field Mapping

The overall flow is U8 → Qeasy middle layer → Wangdiantong. On the U8 side, pustorein/list pulls receipt lists, then pustorein/get pulls details; the middle layer does the flattening and field remapping; finally Wangdiantong Qimen's wdt.purchase.order.push is called to write.

Key field mapping:

U8 Field	Meaning	Middle Layer	Wangdiantong Field	Meaning
ivtid	Document id	Pass through	outer_no	API order number (unique)
ccode	Document number	Mapped to outer_no	outer_no	Same; recommend ccode as external order number
cvencode	Supplier code	Maintained in central mapping	provider_no	Supplier number; must exist in OMS archive
cwhcode	Warehouse code	Mapped to OMS warehouse code	warehouse_no	Warehouse number
Body rows (inventory, qty, price, etc.)	Receipt details	Flattened into details	details[].spec_no / qty / price	Detail rows
ufts	Timestamp	Incremental cursor	—	Used for incremental check

Field order and names depend on the actual interface in your environment; Qeasy platform supports drag-and-drop mapping visually.

How to Configure on Qeasy

We use Qeasy's strategy canvas, divided into three segments.

Source configuration (U8): WebAPI adapter, POST method, path /apilink/u8api, apiurl set to pustorein/list for lists, apidetail to pustorein/get for details. Use ufts (U8 timestamp) as the incremental field, schedule */30 * * * *, every 30 minutes. Enable idCheck to avoid duplicates.

Middle layer flattening: This is the key step. U8 receipts are header+body structure; OMS needs it flattened into "one order with detail lines". In Qeasy's script node, loop the body and produce one detail record per row while copying header fields (supplier, warehouse, order number, remarks, etc.) onto each record. Recommend making the "flatten" script an independent node for reuse by return-order flows—this is a common "phased asset accumulation" pattern among Qeasy customers.

Target configuration (Wangdiantong): Call wdt.purchase.order.push, outer_no uses U8 document number ccode, warehouse_no uses the mapped warehouse code (the material sample uses 999999 as a placeholder, replace per environment), provider_no must first exist in the OMS supplier archive or the push will fail.

For code mapping, build an independent "code mapping table" node in Qeasy to centralize supplier and warehouse mappings, avoiding hardcoding in scripts—this is one of the most common patterns among Qeasy customers, so future code system changes don't require script edits.

Implementation Steps

We typically proceed in three phases:

Stock full sync: Temporarily set crontab to 1 1 1 1 1 (triggers once on Jan 1 each year, effectively a manual one-shot), backfill historical receipts into OMS first, then restore incremental scheduling immediately.
Incremental starting point: Pick a clear time point as the ufts incremental cursor starting point; recommend the full sync completion time minus 30 minutes as a buffer.
Steady-state scheduling: Schedule */30 * * * *, run for 24 hours to observe, confirm no duplicates or missing orders before delivery.

Don't be greedy on scheduling frequency—U8's ufts is a database timestamp, high-frequency polling adds no value and stresses U8; 30 minutes is sufficient for most customer sites.

Lessons Learned

Wrong incremental starting point causes missed or duplicate orders. The typical error is using "today midnight" as the start, but U8 timestamp format depends on system timezone. The safe approach is to run full sync first, then use the full sync completion time as anchor minus 30 minutes.
Pushing before supplier archives are created. provider_no must be an existing archive in OMS, otherwise push fails directly. Recommend making "supplier archive pre-creation" a precondition for this strategy—don't run without archives.
Hardcoded warehouse codes. The warehouse_no=999999 in the material looks like a placeholder; copying directly to production causes issues. The safe approach is to build a mapping table in Qeasy and dynamically fetch per U8 warehouse.
Header fields missed in flatten script. Each detail line must carry header fields like supplier, warehouse, order number, and remarks; missing any one will cause OMS-side errors.
No consideration for cancel/void scenarios. U8 receipts may be voided later, but OMS has already received them. This must be handled by OMS's own void process or reverse sync; this single strategy cannot cover it.

Applicable and Non-Applicable Scenarios

Applicable: Retail/distribution enterprises where U8 is primary and OMS is secondary—U8 handles financial bookkeeping and inventory, OMS handles receiving acceptance and shipping, needing to convey receiving facts to OMS as executable purchase orders.

Not applicable: Enterprises where U8 already covers all business (redundant); scenarios requiring second-level real-time performance (30-minute rounds insufficient); scenarios where OMS already has a complete purchase order system and doesn't want to be overwritten by ERP.