For Oracle professionals moving from Oracle E-Business Suite (EBS) to Oracle Fusion Cloud Applications, one of the first questions is often: “Where did my EBS table go?”
Sometimes, the answer is simple. Many familiar Oracle tables still exist in Fusion. AP_INVOICES_ALL, PO_HEADERS_ALL, GL_JE_HEADERS, and several other core transactional tables will look immediately familiar to an experienced EBS developer.
But familiarity can also be misleading.
Oracle Fusion is not simply EBS moved to the cloud. The underlying application architecture has evolved significantly. Some tables have been replaced, some have been split into multiple tables, new concepts have been introduced, and in some cases a familiar table name remains while the way you should use that table has changed.
In this article, we will look at some of the differences that matter most when working with Oracle Fusion data.
EBS Knowledge Is Valuable – But Don’t Assume Fusion Works the Same Way
For experienced EBS developers, moving to Fusion can initially feel familiar. You will still encounter tables such as:
| Area | Oracle EBS | Oracle Fusion |
|---|---|---|
| AP Invoices | AP_INVOICES_ALL | AP_INVOICES_ALL |
| AP Invoice Lines | AP_INVOICE_LINES_ALL | AP_INVOICE_LINES_ALL |
| Purchase Order Headers | PO_HEADERS_ALL | PO_HEADERS_ALL |
| Purchase Order Lines | PO_LINES_ALL | PO_LINES_ALL |
| GL Journal Headers | GL_JE_HEADERS | GL_JE_HEADERS |
| GL Journal Lines | GL_JE_LINES | GL_JE_LINES |
| SLA Headers | XLA_AE_HEADERS | XLA_AE_HEADERS |
| SLA Lines | XLA_AE_LINES | XLA_AE_LINES |
That continuity is useful. However, one of the biggest mistakes an experienced EBS developer can make is assuming: “The table exists in Fusion, so my EBS SQL should work with a few minor changes.”
Sometimes it will. Often, it won’t.
The differences become particularly clear when we look at HCM.
Suggested Read: Move Data from Oracle Fusion to Oracle Database Just Got Easy
A Great Example: PER_ALL_PEOPLE_F
Anyone who has worked extensively with Oracle EBS HRMS will recognize: PER_ALL_PEOPLE_F In EBS, this table was central to person information and included columns related to the person’s name.
An EBS developer could therefore retrieve person information and name-related information from the same core person record.
With Oracle Fusion HCM, the model changed.
PER_ALL_PEOPLE_F still exists, which can initially give an EBS developer the impression that the same approach can be followed. But Fusion separates person-name information into another date-effective table: PER_PERSON_NAMES_F
It is an important architectural difference.
EBS: Person and Name Information
Conceptually, an EBS query could work around PER_ALL_PEOPLE_F with the person’s name attributes available as part of the person record.
Fusion: Person and Name Are Separated
In Fusion, you commonly work with PER_ALL_PEOPLE_F together with PER_PERSON_NAMES_F
Fusion stores date-effective person-name records separately in PER_PERSON_NAMES_F, allowing multiple name representations to be maintained for a person.”
And there is another important concept: NAME_TYPE
A person can have different representations of their name depending on the name type and configuration.
It means that simply joining to PER_PERSON_NAMES_F is not necessarily enough. The developer needs to understand which name record is required for the reporting requirement.
It is a good example of an important Fusion principle: Don’t just look for the EBS table equivalent. Understand how Oracle redesigned the underlying business object.
Why Did Oracle Separate Person Names?
The Fusion model is designed for global organizations. A person’s identity and their name representation are not always a simple one-to-one relationship. Different countries, legislative requirements, languages and business processes may require different representations of a person’s name.
Separating person data from person-name data allows Oracle Fusion to support these requirements more flexibly. For someone coming from EBS, however, it means the SQL needs to change. What previously looked conceptually like:
Person → Name
within a single core table may now involve:
PER_ALL_PEOPLE_F
↓
PER_PERSON_NAMES_F
along with the appropriate effective-date and name-type conditions.
That last part is important. Both tables are date effective.
A query that joins them without considering effective dates can produce duplicate records or return historical information when the requirement is to show the current employee.
It is where understanding the Fusion data model becomes more important than simply knowing table names.
PER_ALL_ASSIGNMENTS_F Is Another Good Example
Assignments are another area where EBS knowledge remains valuable but where assuming the data model works exactly the same can lead to incorrect reporting.
Experienced EBS HRMS developers will already be familiar with: PER_ALL_ASSIGNMENTS_F
Oracle Fusion continues to use date-effective assignments, and PER_ALL_ASSIGNMENTS_F remains a key table in the HCM data model. However, the assignment no longer exists in isolation. It forms part of a broader employment model that introduces additional business concepts and relationships.
Fusion HCM supports workforce structures involving concepts such as:
- Work Relationships
- Employment Terms
- Assignments
- Assignment Statuses
- Business Units
- Legal Employers
- Jobs
- Positions
- Grades
As a result, reporting on an employee’s assignment often involves more than simply retrieving a row from PER_ALL_ASSIGNMENTS_F. Depending on the reporting requirement, developers may also need to consider related employment records, organizational structures, and other HCM entities.
This becomes particularly important when reporting current versus historical workforce information, or when employees have multiple assignments or more complex employment arrangements.
An EBS report that focuses only on PER_ALL_ASSIGNMENTS_F may therefore require additional joins and business logic when recreated in Oracle Fusion.
The key lesson is not that the assignment table has disappeared, it has not. Rather, Oracle has expanded the surrounding data model, meaning developers need to understand the relationships around the assignment as well as the assignment itself.
Date-Effective Data Matters More Than Ever
The _F suffix should already be familiar to experienced Oracle HRMS developers. Tables such as:
- PER_ALL_PEOPLE_F
- PER_PERSON_NAMES_F
- PER_ALL_ASSIGNMENTS_F
maintain effective-dated information.
The important columns commonly include: EFFECTIVE_START_DATE and EFFECTIVE_END_DATE
When joining multiple effective-dated Fusion tables, developers need to ensure that the records being joined are valid for the required date.
Consider a report joining: Person → Person Name → Assignment
You may be dealing with three independently effective-dated datasets. Ignoring those effective dates is one of the easiest ways to create duplicate or historically inconsistent results in Fusion reporting. This is why copying an EBS SQL and changing a few table names is rarely a reliable migration strategy.
Also Read: Master Oracle Fusion SQL Modifications with SQLProAI Agent
Some EBS Tables Have Completely Different Fusion Equivalents
The HCM example is only one part of the story. Across Fusion Applications, several familiar EBS objects have changed. Some commonly encountered examples include:
| Oracle EBS | Oracle Fusion | Area |
|---|---|---|
| AP_SUPPLIERS | POZ_SUPPLIERS | Suppliers |
| AP_SUPPLIER_SITES_ALL | POZ_SUPPLIER_SITES_ALL_M | Supplier Sites |
| FND_USER | PER_USERS* | User-related reporting |
| HR_OPERATING_UNITS | Fusion Business Unit model/views | Enterprise Structure |
| GL_SETS_OF_BOOKS | GL_LEDGERS | General Ledger |
| MTL_SYSTEM_ITEMS_B | EGP_SYSTEM_ITEMS_B | Product Management |
| MTL_PARAMETERS | INV_ORG_PARAMETERS | Inventory |
The exact tables/views required for user reporting depend on what information is being retrieved. Fusion identity and security should not be treated as a direct replacement of the EBS FND_USER model.
Notice something important here. The prefixes themselves tell part of the Fusion story.
EBS developers were accustomed to modules and prefixes such as:
- AP_
- PO_
- HR_
- MTL_
In Fusion you start encountering newer application areas and prefixes such as:
- POZ_
- EGP_
- FUN_
alongside familiar prefixes that continue to exist. It reflects how the application architecture itself evolved.
Operating Units vs Business Units
Another major conceptual change is organizational structure. EBS developers are accustomed to concepts such as Operating Units and Multi-Org Access Control.
Fusion introduced a different enterprise structure model, where Business Units play an important role across application modules. But an EBS Operating Unit should not simply be mentally renamed as a Fusion Business Unit.
Fusion enterprise structures can involve: Enterprise → Legal Entity → Business Unit → Ledger, along with other organizational and reference-data structures depending on the module.
The difference affects SQL.
A query may technically return data without the appropriate Business Unit logic while still producing a result that is functionally incorrect. And those are often the hardest reporting problems to identify.
Reference Data Sets and SET_ID
Another Fusion concept EBS developers frequently encounter is: SET_ID
Reference Data Sets allow certain reference information to be shared across Business Units. It is an important Fusion architectural concept because a developer cannot always assume that reference data belongs exclusively to one organization.
Understanding the relationship between: Business Units and Reference Data Sets is therefore important when developing Fusion reports and integrations.
Again, this is not merely a database difference. It represents a change in how the application itself models the enterprise.
The Real Challenge Isn’t Finding Tables – It’s Understanding Relationships
When an EBS developer first starts working with Fusion, the natural approach is often to search: “What is the Fusion equivalent of this EBS table?”
That is a useful starting point. But it shouldn’t be the final question. A better set of questions is:
- What business object does this table represent in Fusion?
- Has Oracle separated this information into multiple entities?
- Is the data date effective?
- Does Business Unit or Set ID affect the relationship?
- Are there multiple records for the same person or transaction?
- Should I use a table or an Oracle-provided view?
PER_ALL_PEOPLE_F and PER_PERSON_NAMES_F demonstrate this perfectly. If you only search for PER_ALL_PEOPLE_F, you may conclude that the EBS and Fusion models are almost identical.
Once you understand the surrounding tables and relationships, you realize that Oracle has changed how the business object itself is represented.
Why EBS SQL Often Needs More Than a Table-Name Replacement?
Suppose an organization has hundreds of custom EBS reports that need to be recreated in Oracle Fusion. A simple migration approach might be:
- Identify the EBS tables.
- Find their Fusion equivalents.
- Replace the tables.
- Fix the joins.
- Run the SQL.
For simple reports, that might work. For complex reporting, it can create subtle problems. A query can execute successfully and still be functionally wrong. It might:
- Return duplicate employees
- Use an incorrect person name
- Return historical instead of current assignment information
- Miss records belonging to another Business Unit
- Incorrectly join reference data
- Assume an EBS organizational relationship that no longer exists
- Miss additional Fusion entities introduced around the original business object
A successful SQL execution therefore doesn’t necessarily mean a successful EBS-to-Fusion conversion.
Oracle Fusion Requires Understanding the Application, Not Just SQL
It is something our experience at DataFusing has reinforced repeatedly.
- Writing SQL against Oracle applications is relatively easy.
- Writing correct Oracle application SQL requires understanding what the data represents.
That distinction becomes even more important with Fusion. You need to understand concepts such as:
- Person vs Person Name
- Person vs Work Relationship vs Assignment
- Supplier vs Supplier Site
- Legal Entity vs Business Unit
- Ledger vs Business Unit
- Reference Data Set vs Business Unit
- Current records vs effective-dated records
The table names are only the entry point. The relationships between those tables are where much of the real Oracle knowledge lives.
From Oracle EBS to Fusion: Decades of Oracle Experience Matter
Oracle applications have evolved enormously.
Our leadership’s experience with Oracle stretches back to the 1990s, through earlier generations of Oracle applications and E-Business Suite, and into today’s Oracle Fusion Cloud ecosystem.
DataFusing itself has spent the last six years working within the Oracle ecosystem, particularly around Oracle Fusion data, SQL, reporting, integrations and data movement.
That history matters because Fusion isn’t isolated from what came before it. Many of its concepts evolved from Oracle’s previous application generations. Knowing EBS helps you recognize the foundation.
Knowing Fusion helps you understand what Oracle changed and, more importantly, why it changed.
Must Read: How to Fix Oracle Fusion SQL With CloudSQL’s AI Agent?
Final Thoughts
Oracle Fusion is not simply Oracle EBS running in the cloud. There is significant continuity between the two products, which is why experienced EBS professionals often have a strong foundation for learning Fusion.
But there are also important architectural differences. PER_ALL_PEOPLE_F is a perfect example. Seeing the same familiar table name may suggest that nothing changed.
Then you discover PER_PERSON_NAMES_F, NAME_TYPE, effective-dated joins, assignment structures and the wider Fusion HCM model.
That is the difference between knowing an Oracle table name and understanding the Oracle Fusion data model.
Whether you are migrating reporting from EBS to Fusion, building new Fusion reports, extracting large volumes of Oracle Fusion data, developing integrations, or trying to understand how your existing Oracle knowledge translates into the cloud, understanding the data model is where it starts.
Working on an EBS-to-Fusion migration or struggling to identify the right Fusion tables and relationships? Talk to DataFusing about your Oracle Fusion data requirements.
