Search Results hz_relationship_types

Overview

The HZ_RELATIONSHIP_TYPES table is a core reference table within Oracle E-Business Suite's Trading Community Architecture (TCA), specifically under the Receivables (AR) product module. It serves as the master repository for defining the nature of associations between different parties within the system. A party can be an organization, a person, a group, or another entity. This table standardizes and controls the types of relationships that can be established, such as "Employee of," "Subsidiary of," or "Contact for." Its primary role is to provide a validated list of relationship types that can be used when creating records in the central relationship table, HZ_RELATIONSHIPS, ensuring data consistency and integrity across all customer and partner interactions.

Key Information Stored

The table's structure is designed to categorize and describe each valid relationship type. The primary key, RELATIONSHIP_TYPE_ID, uniquely identifies each type. Two critical columns, SUBJECT_TYPE and OBJECT_TYPE, define the participating entities in the relationship. The SUBJECT_TYPE represents the party initiating or holding the relationship role (e.g., "Employee"), while the OBJECT_TYPE represents the target party of that relationship (e.g., "Organization"). Other significant columns typically include a RELATIONSHIP_CODE for internal processing, a user-facing DISPLAY_NAME, a DESCRIPTION, and columns controlling status (STATUS, START_DATE_ACTIVE, END_DATE_ACTIVE). The table also maintains standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) for auditing.

Common Use Cases and Queries

This table is essential for setup, reporting, and data validation. Administrators query it to review or maintain the list of active relationship types available for assignment. A common reporting need is to list all relationships for a specific party, which requires joining HZ_RELATIONSHIP_TYPES with HZ_RELATIONSHIPS and HZ_PARTIES. For example, to find all employees of a specific organization, one might use a query pattern such as:

• SELECT pr.party_name, rlt.display_name, rs.subject_id
• FROM hz_relationships rs,
• hz_relationship_types rlt,
• hz_parties pr
• WHERE rs.relationship_type_id = rlt.relationship_type_id
• AND rs.object_id = <org_party_id>
• AND rlt.relationship_code = 'EMPLOYEE_OF'
• AND rs.subject_id = pr.party_id
• AND SYSDATE BETWEEN rs.effective_start_date AND NVL(rs.effective_end_date, SYSDATE+1);

It is also frequently referenced in Data Security (DSS) criteria and geographic hierarchy definitions.

Related Objects

HZ_RELATIONSHIP_TYPES is centrally linked to the primary relationship table, HZ_RELATIONSHIPS, via the RELATIONSHIP_TYPE_ID foreign key. As indicated in the metadata, it has foreign key relationships with FND_OBJECT_INSTANCE_SETS on its SUBJECT_TYPE and OBJECT_TYPE columns, linking it to the Flexfields mechanism. Furthermore, it is referenced by HZ_DSS_CRITERIA.OWNER_TABLE_ID1 for defining data security rules and by HZ_GEO_STRUCTURE_LEVELS.RELATIONSHIP_TYPE_ID for configuring geographic hierarchies. Key APIs for managing relationship data, such as those in the HZ_RELATIONSHIP_V2PUB package, rely on the definitions stored in this table to validate input parameters.