Oracle Fusion · Procurement · Transactional
Migrate open purchase orders into Oracle Fusion Procurement, covering headers, lines, schedules, distributions, receipt history and the open commitment position.
Purchase order migration is scoped by what is still open. A fully received and invoiced PO has no operational future in the new system; an open PO represents a commitment the business expects to receive against and pay. The migration exists to preserve that commitment.
The object is four levels deep — header, line, schedule, distribution — and each level carries quantities that must remain internally consistent. Partially received orders are where this typically breaks: the remaining quantity, not the ordered quantity, is what makes the new system behave correctly.
Scope is agreed in discovery; this is the shape of the object.
| Data area | Typical information |
|---|---|
| Header | PO number, supplier, site, buyer, currency, status, terms |
| Lines | Item or description, quantity, unit price, need-by date |
| Schedules | Ship-to organisation and location, promised dates, quantity per schedule |
| Distributions | Charge account, requester, quantity split across accounts |
| Receipts | Quantity already received against each schedule |
| Attachments | Contracts and specifications where in scope |
Dependency drives load sequence: a child cannot exist before its parent.
Confirm each of these before the first migration cycle.
Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.
Object-level equivalence. Field-level mapping is produced per engagement.
| Source system | Source entity | Target object |
|---|---|---|
| Oracle EBS | PO Headers / Lines / Distributions | Fusion PO header / line / distribution |
| SAP ECC | Purchasing document (EKKO/EKPO/EKET) | Fusion PO header / line / schedule |
| JD Edwards | Purchase Order Detail (F4311) | Fusion PO line |
Purchase Order Import FBDI (header, line, schedule, distribution files)
Open orders loaded at remaining quantity
Receipt history summarised rather than replayed transaction by transaction
In the correct procurement business unit.
Item-based lines fail without the organisation assignment.
Distribution quantities sum to schedule; schedules sum to line.
Zero-remaining orders should not be in scope.
For every distribution.
The PO references a valid procurement agent.
What has to exist before this object can load.
What actually fails on this object, and why.
Counts alone rarely prove this object migrated correctly.
Open PO count: source open orders vs loaded
Open commitment value in total, by business unit and by currency
Remaining quantity by line compared to source
Orders excluded (fully received) listed explicitly as an agreed exclusion
Supplier coverage: every open order resolves to a loaded supplier site
Where matched invoices are also in scope, the PO-invoice link is verified after both loads
Closed purchase orders are a natural archive candidate. They carry audit value — what was ordered, from whom, at what price — but no operational purpose once received and invoiced. Migrating open commitments and archiving closed order history keeps the procurement module clean while preserving the record for audit and spend analysis.
Extraction, mapping, transformation, validation preparation and target load generation.
Explore DataMove →Preserves source, prepared and target states for reconciliation, lineage and audit evidence.
Explore DataVault →Migration progress, data quality, exceptions and readiness across cycles.
Explore DataLens →Source-specific guidance for moving this object.
Published case studies whose scope included purchase orders.
Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.