HZ_PARTIES Table in Oracle Fusion: Customers, Suppliers & Employees

In Oracle Fusion, the HZ_PARTIES table stores basic identity information about parties. A party represents a uniquely identifiable real-world entity that the enterprise interacts with, such as a customer, supplier, bank, contact, or, in specific integration scenarios, an employee.

Although each record in HZ_PARTIES represents a unique party, multiple parties can share the same name, and name uniqueness is not enforced at the database level.

Oracle Fusion supports three party types only: Organization, Person, and Group. An organization party represents entities such as companies or banks, a person party represents individuals such as customers, contacts, or employees, and a group party represents collective entities such as industry associations or consortiums.

The HZ_PARTIES table stores identity data only and does not contain transactional or role-specific information. Functional roles such as customer accounts, suppliers, or employees are defined in module-specific tables that reference HZ_PARTIES using PARTY_ID.

The HZ_PARTIES table also contains denormalized identity attributes sourced from other Trading Community Architecture tables, including HZ_LOCATIONS, HZ_PERSON_PROFILES, HZ_ORGANIZATION_PROFILES, HZ_CONTACT_POINTS, and HZ_PERSON_LANGUAGE.

The identifying address stored in HZ_PARTIES is denormalized from the HZ_LOCATIONS table. Party records can be created or enriched using third-party data providers, such as Dun & Bradstreet Global Data Products, allowing organizations to maintain consistent and externally validated identity data.

An authoritative description of the HZ_PARTIES table and its attributes is available in Oracle’s official documentation.

What Is Trading Community Architecture (TCA)?

Trading Community Architecture (TCA) is a party-centric data architecture that originated in Oracle E-Business Suite and continues to underpin Oracle Fusion Cloud’s management of party information.

Although Oracle Fusion documentation does not position TCA as a separately configurable feature, the same architecture and table structures are used to organize identity data across Sales, Service, and ERP modules.

In Oracle Fusion, TCA provides a single source of truth for party identity. It ensures that real-world entities such as customers, suppliers, contacts, partners, and related organizations are created once and reused consistently across applications. This prevents identity duplication and allows the same entity to participate in multiple business processes without redefining who that entity is.

At the center of TCA is the concept of a party. A party represents a uniquely identifiable entity and is stored in the HZ_PARTIES table.

Oracle Fusion supports three party types: Organization, Person, and Group. While the party type defines the nature of the entity, party usage defines how that entity participates in a specific functional context. 

For example, a sales account created in Sales Cloud is stored as an organization party, and its role as a customer is determined by usage rather than by creating a separate identity record. The same party can later be associated with supplier usage in ERP, still referencing the same PARTY_ID.

This separation of identity from business role is the key reason HZ_PARTIES is referenced across multiple Fusion modules. Customer accounts, supplier records, contacts, and other role-specific definitions all rely on the same party record while storing their functional attributes in module-specific tables.

The table below summarizes the core tables that make up the TCA data model in Oracle Fusion and their responsibilities.

Table Name	Purpose in TCA
HZ_PARTIES	Stores high-level, basic identity information for all parties and assigns a unique PARTY_ID.
HZ_ORGANIZATION_PROFILES	Stores detailed attributes for organization parties, including extended account-related information.
HZ_PERSON_PROFILES	Stores detailed attributes for person parties, such as contact-related information from Sales Cloud.
HZ_PARTY_SITES	Stores address associations for parties and acts as a link between parties and locations.
HZ_LOCATIONS	Stores geographical and address information identified by LOCATION_ID.
HZ_PARTY_USAGES_B	Stores the purpose of a party site, such as billing, shipping, or selling contexts.
HZ_CONTACT_POINTS	Stores communication methods such as phone numbers and email addresses used primarily in back-office processes.

Understanding TCA in this context is essential before working with HZ_PARTIES, because every customer, supplier, or contact-related query ultimately relies on this shared identity model. Misinterpreting TCA often leads to incorrect joins, duplicate reporting, and inconsistent results across Fusion modules.

What Is the HZ_PARTIES Table?

The HZ_PARTIES table is the central identity table in Oracle Fusion for all parties managed through the party-based data model. Each record in HZ_PARTIES represents a single, unique party, which is a real-world entity that the enterprise interacts with, such as a customer, supplier, contact, bank, or, in integrated scenarios, an employee.

Although each party is uniquely identified by PARTY_ID, party names are not unique, and multiple parties can legitimately share the same name. For this reason, PARTY_ID is the only reliable identifier used to link party records across Oracle Fusion modules.

The table is intentionally limited to identity-related attributes. It does not store transactional data or role-specific business details. Instead, functional areas such as Sales, Procurement, Receivables, and HCM reference HZ_PARTIES to associate their business records with a shared identity.

Party Types in HZ_PARTIES

Oracle Fusion supports exactly three party types in the HZ_PARTIES table. The party type defines the fundamental nature of the entity and remains consistent regardless of how the party is used across modules.

PARTY_TYPE	Description
ORGANIZATION	Represents legal or business entities such as customers, suppliers, banks, or partner companies.
PERSON	Represents individuals such as contacts, consumers, or employees in integrated environments.
GROUP	Represents collective entities such as associations or consortiums.

Party type determines which profile tables apply to the party, but it does not define the business role of the party, which is handled separately through usage and module-specific relationships.

Identity Versus Business Context

A key principle when working with HZ_PARTIES is the separation between identity and business context. The HZ_PARTIES table defines who the party is, while role-specific tables define how the party participates in business processes.

Customer accounts, supplier records, and other functional definitions store their own attributes and reference HZ_PARTIES using PARTY_ID. This design allows a single party to participate in multiple business roles without identity duplication and ensures consistent cross-module reporting.

Key Columns in HZ_PARTIES

The HZ_PARTIES table contains a large number of columns, but in practice only a small subset is consistently used by developers, BI analysts, and integration teams. Understanding these key columns is essential because they form the foundation for nearly all joins, filters, and validations involving party data in Oracle Fusion.

The table below highlights the most commonly used columns in HZ_PARTIES and explains their purpose in real-world usage.

Column Name	Description
PARTY_ID	The primary key of the table and the global identifier for a party across Oracle Fusion. This column is used in joins with customer, supplier, contact, and other party-related tables.
PARTY_NAME	The name of the person, organization, or group represented by the party. This value is descriptive only and is not guaranteed to be unique.
PARTY_TYPE	Indicates whether the party represents a PERSON, ORGANIZATION, or GROUP. This column determines which profile tables are applicable.
STATUS	Indicates whether the party record is active or inactive. Inactive parties may still exist in the database due to soft deletion behavior.
PARTY_NUMBER	A system-generated party reference number that is often displayed in user interfaces and used for functional identification.
CREATED_BY	Stores the identifier of the user or process that created the party record.
CREATION_DATE	Stores the date and time when the party record was created.

Among these columns, PARTY_ID is the most critical from a technical standpoint. It is the only column that uniquely identifies a party and the only column that should be relied upon for joins across Oracle Fusion modules. Columns such as PARTY_NAME and PARTY_NUMBER are useful for display and validation, but should never be used as join keys.

Filtering on PARTY_TYPE and STATUS is also a common best practice when querying HZ_PARTIES, as it helps limit result sets to the relevant type of entity and avoids inadvertently including inactive or obsolete party records.

Understanding PARTY_ID

The PARTY_ID column represents the global identity key for a party in Oracle Fusion. It is generated when a party record is created in the HZ_PARTIES table and remains constant for the lifetime of that party, regardless of how the party is used across different modules.

From a data model perspective, PARTY_ID is the only reliable identifier for a party. It is reused consistently across customer, supplier, contact, bank, and related tables to ensure that all functional definitions reference the same real-world entity.

No other column in HZ_PARTIES, including PARTY_NAME or PARTY_NUMBER, provides this level of stability or uniqueness.

Why PARTY_ID Is Reused Across Modules?

Oracle Fusion deliberately reuses PARTY_ID across functional areas to avoid identity duplication. When a party participates in multiple business roles, those roles are represented in module-specific tables while continuing to reference the same PARTY_ID.

For example, when an organization is created as a customer, a customer account record is created in HZ_CUST_ACCOUNTS that references the party using PARTY_ID. If the same organization later becomes a supplier, the supplier definition references the same party record, not a new one. This allows Oracle Fusion to recognize both roles as belonging to the same underlying entity.

This design is what enables cross-module visibility and prevents the same organization from being treated as separate entities in different parts of the system.

Common Misconceptions About PARTY_ID

• A frequent mistake made by developers new to Oracle Fusion is assuming that PARTY_ID is module-specific. In reality, PARTY_ID is enterprise-wide and has no inherent association with a particular functional area such as Receivables, Procurement, or Sales.
• Another common misconception is treating PARTY_ID as interchangeable with business identifiers such as customer numbers or supplier numbers. Those identifiers are role-specific and can change over time, while PARTY_ID remains constant and purely represents identity.

Best Practices When Using PARTY_ID

When writing SQL queries or building reports, PARTY_ID should always be treated as the primary join key for party-related data. All joins between HZ_PARTIES and role-specific tables must be based on PARTY_ID, and not on descriptive columns such as names or reference numbers.

Using PARTY_ID consistently ensures accurate joins, prevents duplicate records, and guarantees that the same real-world entity is represented correctly across Oracle Fusion modules.

Also Read: HZ_CUST_ACCOUNTS Explained

How HZ_PARTIES Is Used for Customers?

In Oracle Fusion, customer-related identity information is derived from the party model, with HZ_PARTIES acting as the master identity table. A customer does not exist independently as a standalone entity; instead, a customer is defined by associating a party with customer-specific attributes stored in customer tables.

The core relationship between parties and customers is established through the HZ_CUST_ACCOUNTS table. While HZ_PARTIES defines who the customer is, HZ_CUST_ACCOUNTS defines how that party behaves as a customer within Receivables and related modules.

Customer Data Flow in Oracle Fusion

When a customer is created in Oracle Fusion, the system follows a clear and consistent data flow. First, a party record is created in HZ_PARTIES to represent the customer’s identity.

Next, a customer account is created in HZ_CUST_ACCOUNTS, which references the party using PARTY_ID. Any customer-specific attributes, such as account status or credit-related information, are stored at the customer account level rather than in the party table.

This separation allows the same party to have multiple customer accounts if required, and also allows that party to participate in other roles, such as supplier, without redefining identity.

Key Tables Involved in Customer Representation

The table below summarizes the primary tables involved when working with customer data in relation to HZ_PARTIES

Table Name	Purpose
HZ_PARTIES	Stores the core identity of the customer as a party.
HZ_CUST_ACCOUNTS	Stores customer account–specific attributes and references the party using PARTY_ID.

Common Customer Join Pattern

SELECT
    hp.party_id,
    hp.party_name,
    hp.party_type,
    hca.cust_account_id,
    hca.account_number,
    hca.status
FROM
    hz_parties hp,
    hz_cust_accounts hca
WHERE
    hp.party_id = hca.party_id
    AND hp.party_type = 'ORGANIZATION'
    AND hp.status = 'A'
;

This query returns customer account data anchored to party identity. The join ensures that customer records are consistently linked to the correct party, and the filters restrict the result set to active organization parties, which is appropriate for most customer reporting scenarios

Common Customer Use Cases

• This data model is commonly used for customer master reporting, customer account validation, and cross-module reconciliation. Using PARTY_ID as the join key ensures that customer data remains consistent with Oracle Fusion’s centralized identity model.

How HZ_PARTIES Is Used for Suppliers?

In Oracle Fusion, suppliers are represented using the same party-based identity model as customers. The supplier’s core identity is stored in HZ_PARTIES, while supplier-specific attributes and operational behavior are stored in procurement tables. This design ensures that supplier identity is centralized and reusable across modules.

A supplier record does not redefine who the supplier is. Instead, it references an existing party using PARTY_ID, allowing the same real-world entity to act as a supplier, customer, or both, without creating duplicate identity records.

Supplier Representation in Oracle Fusion

When a supplier is created, Oracle Fusion creates or reuses a party record in HZ_PARTIES to represent the supplier’s identity. Supplier-specific details, such as supplier number, status, and procurement attributes, are stored in the supplier tables. These tables reference the party to maintain a consistent identity across the system.

This separation allows Oracle Fusion to:

• Maintain a single identity for the supplier.
• Support multiple business roles for the same entity.
• Enable accurate cross-module reporting and reconciliation.

Key Tables Involved in Supplier Representation

Supplier data in Oracle Fusion is split between identity and role-specific tables. The identity of the supplier is maintained at the party level, while operational and procurement attributes are stored separately. This structure prevents identity duplication and supports reuse of the same party across different business contexts.

Table Name	Purpose
HZ_PARTIES	Stores the core identity information for the supplier as a party.
POZ_SUPPLIERS	Stores supplier-specific attributes and links the supplier record to the party.

Common Supplier Join Pattern

Supplier reporting and validation queries typically anchor supplier records to party identity using PARTY_ID. This join pattern ensures that supplier data is consistently associated with the correct real-world entity.

SELECT
    hp.party_id,
    hp.party_name,
    hp.party_type,
    ps.vendor_id,
    ps.segment1 supplier_number
FROM
    hz_parties hp,
    poz_suppliers ps
WHERE
    hp.party_id = ps.party_id
    AND hp.party_type = 'ORGANIZATION'
    AND hp.status = 'A'
;

Supplier and Customer Overlap Scenarios

It is common for an organization to act as both a supplier and a customer. Oracle Fusion supports this by allowing the same party record to be referenced by both customer and supplier tables. Because both roles point to the same PARTY_ID, reporting across Receivables and Procurement can correctly identify overlaps without relying on names or external reference numbers.

This behavior is a direct outcome of the centralized party model and reinforces why HZ_PARTIES must be treated as the authoritative identity table.

How is HZ_PARTIES Used for Employees?

Employee data in Oracle Fusion is managed primarily within Human Capital Management, but employee identity can also participate in the centralized party model. In integrated environments, employees are represented as person parties, allowing their identity to be reused consistently across modules such as Financials, Approvals, and Workflow.

In this design, HZ_PARTIES stores the employee’s identity as a PERSON party, while HCM tables store employment-specific and effective-dated information.

Employee Identity and Party Representation

An employee’s identity is represented in HCM through the PER_PERSONS table. When an employee is associated with the party model, the corresponding person record is linked to a PERSON party in HZ_PARTIES. This linkage allows Oracle Fusion to reference the same individual across HCM and non-HCM modules without duplicating identity data.

Employment-specific attributes such as assignments, grades, and effective-dated personal information are maintained separately and do not redefine the party identity.

Key Tables Involved in Employee Representation

Employee identity and employment context are stored in separate tables, each with a distinct responsibility.

Table Name	Purpose
HZ_PARTIES	Stores the core identity of the employee as a person party.
PER_PERSONS	Stores the HCM person record and links the person to a party.
PER_ALL_PEOPLE_F	Stores effective-dated employment and person details.

This separation ensures that identity remains stable even as employment data changes over time

Common Employee Join Pattern

Employee reporting that requires party information typically resolves identity through PER_PERSONS before accessing effective-dated HCM data.

SELECT
    hp.party_id,
    hp.party_name,
    hp.party_type,
    pp.person_id,
    papf.person_number
FROM
    hz_parties hp,
    per_persons pp,
    per_all_people_f papf
WHERE
    hp.party_id = pp.party_id
    AND pp.person_id = papf.person_id
    AND hp.party_type = 'PERSON'
    AND hp.status = 'A'
    AND SYSDATE BETWEEN papf.effective_start_date AND papf.effective_end_date
;

Suggested Read: Oracle Fusion Joins Explained

Common HZ_PARTIES Joins

While customer and supplier joins are usually handled within their respective functional contexts, HZ_PARTIES is most often involved in cross-module joins that relate to addresses, contact information, and shared identity attributes. These joins apply regardless of whether the party is a customer, supplier, or contact and are a common source of confusion and row duplication.

This section focuses on join patterns that are not module-specific and are frequently reused across reporting and integration scenarios.

Joining HZ_PARTIES to Party Sites and Addresses

Addresses in Oracle Fusion are not stored directly on the party record. Instead, they are associated through party sites, which act as a link between a party and one or more physical locations.

A single party can have multiple party sites, and each party site references a location record. This relationship is commonly used when reporting customer or supplier addresses.

SELECT
    hp.party_id,
    hp.party_name,
    hps.party_site_id,
    hl.address1,
    hl.city,
    hl.country
FROM
    hz_parties hp,
    hz_party_sites hps,
    hz_locations hl
WHERE
    hp.party_id = hps.party_id
    AND hps.location_id = hl.location_id
    AND hp.status = 'A'
;

Joining HZ_PARTIES to Contact Points

Contact information such as phone numbers and email addresses is stored in HZ_CONTACT_POINTS. This table does not store a direct PARTY_ID column because contact points can be associated with different owning entities. Instead, ownership is determined using OWNER_TABLE_NAME and OWNER_TABLE_ID.

When a contact point belongs to a party, the owning table is identified as HZ_PARTIES, and the owning identifier corresponds to the party’s PARTY_ID.

SELECT
    hp.party_id,
    hp.party_name,
    hcp.contact_point_type,
    hcp.phone_number,
    hcp.email_address
FROM
    hz_parties hp,
    hz_contact_points hcp
WHERE
    hcp.owner_table_name = 'HZ_PARTIES'
    AND hcp.owner_table_id = hp.party_id
    AND hp.status = 'A'
;

One-to-Many Relationships and Row Explosion

Several tables linked to HZ_PARTIES, such as party sites and contact points, have one-to-many relationships with the party record. A single party can have multiple addresses, multiple phone numbers, and multiple email addresses.

When these tables are joined together without careful filtering, result sets can grow exponentially. This behavior often surprises developers who expect a single row per party. Managing this requires:

• Filtering by purpose or type where applicable
• Being deliberate about which related entities are required
• Avoiding unnecessary joins when identity data alone is sufficient

Safe Join Principles When Using HZ_PARTIES

Queries involving HZ_PARTIES are most reliable when they follow a few consistent principles. Joins should always be driven by PARTY_ID, and descriptive attributes such as names should be used only for display purposes. Filters on party status should be applied early to exclude inactive or soft-deleted records.

HZ_PARTIES should be treated as an identity anchor, not as a transactional table. Keeping joins limited to what is functionally required helps maintain accuracy, performance, and predictable results across Oracle Fusion environments.

Common Mistakes When Querying HZ_PARTIES

The table below summarizes the most common mistakes encountered when working with HZ_PARTIES in Oracle Fusion, along with their typical impact on query results and reporting accuracy.

Mistake	What Typically Happens	Why It Causes Issues in Fusion
Using PARTY_NAME as a join key	Queries return duplicate or incorrectly merged records.	Oracle Fusion does not enforce uniqueness on party names, and multiple parties can legitimately share the same name.
Ignoring PARTY_TYPE in filters	Person or group records appear in customer or supplier reports.	HZ_PARTIES stores organizations, persons, and groups in the same table, and party type determines how the record should be interpreted.
Assuming one-to-one relationships	Result sets grow unexpectedly when additional tables are joined.	A single party can have multiple customer accounts, party sites, or contact points, which creates one-to-many join behavior.
Joining contact points directly on PARTY_ID	Contact details appear mismatched or duplicated across parties.	HZ_CONTACT_POINTS uses OWNER_TABLE_NAME and OWNER_TABLE_ID, not a direct PARTY_ID foreign key.
Missing status-based filtering	Inactive or soft-deleted parties appear in reports.	Oracle Fusion uses soft deletion for party records, and inactive parties remain in the database until purged.
Joining directly to transactional tables	Queries become complex and difficult to reconcile with UI data.	Transactional tables are not designed to represent identity and may reference parties indirectly or through intermediate tables.
Skipping validation against the Fusion UI	Reports appear technically correct but do not match application screens.	Incorrect joins can still return valid-looking data that does not reflect how Fusion resolves party relationships in the UI.

Performance & Querying Best Practices

Queries involving HZ_PARTIES often sit at the center of master data, reporting, and integration workloads. Applying a few consistent design practices helps avoid performance issues, incorrect results, and unnecessary complexity.

The table below summarizes recommended best practices and explains why they matter specifically in Oracle Fusion environments.

Best Practice	How It Should Be Applied	Why It Matters in Fusion
Always filter by PARTY_TYPE	Restrict results to ORGANIZATION, PERSON, or GROUP based on the business context.	HZ_PARTIES stores multiple entity types in a single table, and unfiltered queries frequently return irrelevant records.
Always filter by STATUS	Include only active parties unless historical data is explicitly required.	Party records are soft-deleted, and inactive records remain in the database until purged.
Use PARTY_ID for all joins	Join role-specific and related tables using PARTY_ID only.	PARTY_ID is the only stable and globally unique identifier for a party.
Avoid SELECT *	Select only the columns required for the use case.	HZ_PARTIES contains many denormalized columns that increase I/O and reduce query efficiency when selected unnecessarily.
Limit joins early	Apply filters before joining to one-to-many tables such as sites or contact points.	Early filtering reduces row explosion and improves both performance and result predictability.
Be deliberate with address joins	Join through party sites and locations only when address data is required.	Address-related tables introduce multiple rows per party and significantly increase result set size.
Validate against the Fusion UI	Compare query output with application screens for representative records.	Incorrect joins can return technically valid data that does not reflect how Fusion resolves party information.

How CloudSQL Simplifies Working with HZ_PARTIES?

Working with HZ_PARTIES and related tables often involves iterative querying and result validation rather than one-shot query execution. Many issues such as duplicate rows, incorrect joins, or unexpected one-to-many behavior only become visible after the query runs.

CloudSQL Desktop supports this workflow by focusing on faster SQL authoring, better schema visibility, and more effective result analysis.

Faster SQL Authoring and Schema Discovery

Writing queries against wide tables such as HZ_PARTIES requires frequent reference to column names and key structures. CloudSQL Desktop assists this process through auto-completion of table names and column names, reducing the need to switch between documentation and the editor.

The advanced database browser complements this by exposing column details and primary key information directly from the schema. This is particularly useful when working with party-related tables that contain a mix of identity, status, and denormalized attributes.

Assisting Query Correction with SQLProAI

Complex joins and legacy Oracle join syntax can easily introduce syntax or aliasing errors. SQLProAI helps developers identify and fix common SQL issues during query authoring. This capability focuses on SQL correctness, not on validating business rules or Oracle Fusion data relationships.

By reducing time spent on resolving syntax errors, developers can focus on refining joins and validating results.

Using the Dynamic Result Grid to Validate Party Data

Most challenges with party data surface in the result set rather than in the query itself. CloudSQL Desktop’s dynamic result grid is designed to support this phase of analysis, especially when working with one-to-many relationships common in the party model.

The dynamic result grid allows developers to:

Capability	How It Helps with HZ_PARTIES Queries?
Inline filtering	Quickly narrow results to a specific party, status, or identifier without rewriting the query.
Sorting	Order results by effective dates, identifiers, or descriptive columns to identify anomalies.
Grouping	Group records to spot duplicate parties or unexpected row multiplication caused by joins.
In-grid search	Search within large result sets to locate specific values or patterns.
Column navigation	Jump directly to relevant columns in wide result sets such as HZ_PARTIES.
Record isolation	Inspect a single party record independently to understand its relationships and attributes.

These capabilities are particularly useful when validating joins involving party sites, contact points, or customer and supplier relationships, where multiple rows per party are expected but must still be understood and controlled.

When to Extend Beyond HZ_PARTIES?

HZ_PARTIES defines party identity, but Oracle Fusion deliberately avoids modeling relationships and associations directly in the party table. Concepts such as organizational hierarchies or links between organizations and contacts are stored separately so that identity remains stable while relationships evolve independently.

This distinction becomes relevant in reporting scenarios that go beyond identifying a party and require understanding how parties are related.

Party-to-Party Relationships Using HZ_RELATIONSHIPS

Relationships between parties are explicitly stored in HZ_RELATIONSHIPS. This table captures associations between two party records without altering either party’s identity. The same party can participate in multiple relationships, each with a different meaning or direction.

Typical use cases include organizational hierarchies, parent–child structures, and account-to-account relationships.

SELECT
    hp.party_id,
    hp.party_name,
    hr.subject_id,
    hr.relationship_code
FROM
    hz_parties hp,
    hz_relationships hr
WHERE
    hp.party_id = hr.object_id
    AND hp.status = 'A'
;

Organization-Contact Associations Using HZ_ORG_CONTACTS

Associations between organizations and their contacts are modeled through a combination of relationship and contact context tables. The relationship between an organization and a person is first defined in HZ_RELATIONSHIPS. HZ_ORG_CONTACTS then references that relationship and optionally associates it with a specific party site.

This design allows the same contact to be linked to an organization in different contexts, such as different addresses or operational roles, without redefining either party’s identity.

SELECT
    org.party_id organization_party_id,
    org.party_name organization_name,
    per.party_id contact_party_id,
    per.party_name contact_name,
    hoc.party_site_id
FROM
    hz_parties org,
    hz_relationships hr,
    hz_org_contacts hoc,
    hz_parties per
WHERE
    hr.object_id = org.party_id
    AND hr.subject_id = per.party_id
    AND hoc.party_relationship_id = hr.relationship_id
    AND org.status = 'A'
    AND per.status = 'A'
;

Conclusion

HZ_PARTIES sits at the center of Oracle Fusion’s party-based data model and acts as the single source of identity for customers, suppliers, contacts, and related entities. It defines who the entity is, while other tables define how that entity participates in business processes.

Most issues encountered with party data are not caused by data quality problems, but by incorrect assumptions about identity, relationships, or join behavior. Treating PARTY_ID as the universal identifier, respecting party boundaries, and understanding where relationships and context are stored avoids many common reporting and integration errors.

Working effectively with HZ_PARTIES requires careful joins, deliberate filtering, and validation of results against real data. Queries that follow these principles remain predictable, accurate, and aligned with how Oracle Fusion models party identity.

Must Read: Top Oracle Fusion SQL Mistakes Developers Make

FAQs

Internal Links

• Oracle Fusion Joins Explained
• Top Oracle Fusion SQL Mistakes Developers Make