Search Results hz_relationships




Overview
Explore in AI Chat

Overview

The HZ_RELATIONSHIPS table is a core data object within the Oracle E-Business Suite (EBS) Trading Community Architecture (TCA) model, specifically under the AR (Receivables) product family. It serves as the central repository for defining and storing all types of relationships between entities, known as parties, within the system. Its primary role is to establish and maintain the complex web of associations between organizations, people, and other party types, enabling critical business functions such as customer hierarchy management, contact assignment, and relationship-based reporting. The integrity of these connections is fundamental to modules like Order Management, Receivables, and CRM, which rely on accurate party relationships for transaction processing and customer data analysis.

Key Information Stored

The table's structure is designed to capture the bidirectional nature of relationships. The primary key is a composite of RELATIONSHIP_ID and DIRECTIONAL_FLAG, indicating that a single logical relationship is stored with two records to represent each direction (e.g., "Company A is parent of Company B" and "Company B is child of Company A"). Key columns include RELATIONSHIP_ID, which uniquely identifies the relationship instance; SUBJECT_ID and OBJECT_ID, which store the identifiers for the two related parties; and SUBJECT_TYPE and OBJECT_TYPE, which define the party types (e.g., ORGANIZATION, PERSON, GROUP) for each participant. Other critical fields include RELATIONSHIP_TYPE, which classifies the nature of the association (e.g., EMPLOYMENT, CONTACT, PARENT_OF), PARTY_ID which links to the HZ_PARTIES table, and status columns to manage the relationship's lifecycle.

Common Use Cases and Queries

A primary use case is navigating customer organizational hierarchies for reporting and credit management. For example, to find all child organizations of a specific parent company, one would query the HZ_RELATIONSHIPS table filtered by the parent's PARTY_ID and a RELATIONSHIP_TYPE of 'PARENT_OF'. Another common scenario is identifying all contacts for a given organization, which involves joining HZ_RELATIONSHIPS (with a relationship type like 'CONTACT') to HZ_PARTIES. A typical query pattern is: SELECT hr.relationship_id, p1.party_name subject_name, p2.party_name object_name, hr.relationship_type
FROM hz_relationships hr,
hz_parties p1,
hz_parties p2
WHERE hr.subject_id = p1.party_id
AND hr.object_id = p2.party_id
AND hr.subject_type = 'ORGANIZATION'
AND hr.relationship_code = 'PARENT_OF'
AND hr.status = 'A'; This retrieves active parent-child relationships between organizations for reporting.

Related Objects

HZ_RELATIONSHIPS is intrinsically linked to several key TCA objects. Its primary foreign key relationship is with HZ_PARTIES via the PARTY_ID column, which is the master table for all entity definitions. As per the provided metadata, it is also referenced by HZ_HIERARCHY_NODES (for building relationship trees) and HZ_ORG_CONTACTS (for storing detailed contact role information at an organization). Furthermore, the table has foreign key constraints to FND_OBJECT_INSTANCE_SETS on the SUBJECT_TYPE and OBJECT_TYPE columns, which govern the valid party types. For data integrity and application logic, operations on this table are typically performed via the public TCA APIs rather than through direct DML.