Understanding Oracle Fusion Cloud Data Model

Why the data model matters

OIC integrations and VBCS service connections interact with Fusion data through REST APIs. But understanding the underlying data model helps you:

• Find the right REST endpoint for your use case
• Understand why some data needs multiple API calls
• Design efficient integrations that minimise API round trips
• Debug data issues by knowing where data lives

Multi-org architecture

Fusion Cloud is multi-organisation at its foundation. Key concepts:

• Ledger: the financial entity (company, legal entity)
• Business Unit (BU): operational unit — Procurement and Receivables operate at BU level
• Legal Entity: the registered legal company
• Inventory Organisation: for SCM, warehousing
• Set ID: a shared configuration set that can be applied to multiple BUs

Every Fusion record is anchored to one or more of these entities. PO headers belong to a BU; GL journals belong to a Ledger.

Common Fusion table patterns

Document headers and lines: most transactional data follows this pattern:

• PO_HEADERS_ALL / PO_LINES_ALL / PO_LINE_LOCATIONS_ALL / PO_DISTRIBUTIONS_ALL
• AP_INVOICES_ALL / AP_INVOICE_LINES_ALL / AP_INVOICE_DISTRIBUTIONS_ALL

The _ALL suffix contains all records across all operating units. Use the view without _ALL when there’s a security context set.

Descriptive Flexfields (DFF)

DFFs are custom fields added to standard Fusion tables without schema changes. They’re stored in ATTRIBUTE1 through ATTRIBUTE30 columns on the table. When building OIC/VBCS integrations that need to capture/read custom attributes, you’ll frequently work with DFFs.

Access via REST: DFF values appear in Fusion REST responses as DFF.<segment_name> under a DFF context object.

Who columns (audit tracking)

Every Fusion table has CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN. Use LAST_UPDATE_DATE for change-detection watermarks in scheduled OIC integrations.

The _HISTORY tables

For slowly changing dimension data (cost centre history, position history), Fusion maintains history tables with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. Always filter these with SYSDATE BETWEEN EFFECTIVE_START_DATE AND NVL(EFFECTIVE_END_DATE, DATE '4712-12-31') to get current records only.

REST API to table mapping

The Fusion REST API documentation lists which tables each endpoint reads from. Use My Oracle Support (MOS) note “Oracle Fusion Application Tables and Columns” for a comprehensive mapping when you need to go directly to the data.