Search Results hz_party_relationships




Overview
Explore in AI Chat

Overview

The HZ_PARTY_RELATIONSHIPS table is a core data object within the Oracle E-Business Suite Trading Community Architecture (TCA) model, specifically owned by the Receivables (AR) module. It serves as the central repository for defining and storing all formal relationships between entities (parties) in the system. A party can be an organization, a person, or a group. This table is fundamental to modeling complex business hierarchies, affiliations, and contacts, such as defining which person is a contact for a specific customer organization, establishing parent-child relationships between corporate entities, or linking an employee to their employer. Its integrity is critical for downstream processes in Order Management, Receivables, and CRM applications that rely on accurate party relationship data.

Key Information Stored

The table's structure is designed to capture the nature and context of a relationship between two parties. The primary identifier is the PARTY_RELATIONSHIP_ID. The core relationship is defined by the SUBJECT_ID and OBJECT_ID columns, which are foreign keys to HZ_PARTIES. These represent the two parties in the relationship, where the subject party is related to the object party (e.g., a PERSON (subject) is a CONTACT_OF an ORGANIZATION (object)). The RELATIONSHIP_TYPE column categorizes the association (e.g., 'CONTACT', 'EMPLOYMENT', 'PARENT_OF'). The PARTY_ID column typically holds the identifier for the primary party involved, often matching either the subject_id or object_id. Additional columns manage data such as the effective start and end dates (START_DATE, END_DATE), the status of the relationship (STATUS), and the context or role (SUBJECT_TYPE, OBJECT_TYPE) of each party within the relationship.

Common Use Cases and Queries

A primary use case is retrieving all contacts for a given customer account, which is essential for sales, service, and communications. Another is analyzing corporate hierarchies for consolidated reporting or credit management. Common reporting queries involve joining HZ_PARTY_RELATIONSHIPS with HZ_PARTIES and HZ_CUST_ACCOUNTS. For example, to find active contacts for an organization, a developer might use a SQL pattern such as:

  • SELECT hp_person.party_name, hpr.relationship_type, hpr.role
  • FROM hz_party_relationships hpr,
  • hz_parties hp_org,
  • hz_parties hp_person
  • WHERE hpr.subject_id = hp_person.party_id
  • AND hpr.object_id = hp_org.party_id
  • AND hp_org.party_name = '<Customer Name>'
  • AND hpr.relationship_type = 'CONTACT'
  • AND SYSDATE BETWEEN hpr.start_date AND NVL(hpr.end_date, SYSDATE)
  • AND hpr.status = 'ACTIVE';

Related Objects

As indicated by the foreign key constraints, HZ_PARTY_RELATIONSHIPS has a fundamental dependency on the HZ_PARTIES table, which supplies the subject, object, and party identifiers. A key dependent object is the HZ_ORG_CONTACTS table, which uses the PARTY_RELATIONSHIP_ID as a foreign key to store additional, contact-specific information. This table is also heavily referenced by various TCA Public APIs (e.g., HZ_PARTY_RELATIONSHIP_PUB) which are the supported method for creating and maintaining relationship data. Furthermore, it is integral to views like HZ_CUSTOMER_PROSPECTS_V and HZ_RELATIONSHIPS_V that simplify reporting and application logic.