Results for “additional_information30”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HZ_RELATIONSHIPS is the central relationships table within the Oracle E-Business Suite Receivables (AR) schema, owned by AR and designated VALID across both 12.1.1 and 12.2.2. The table stores the associations that exist between entities in the Trading Community Architecture (TCA) model — most commonly relationships between parties such as customers, contacts, organizations, and persons. Each row captures a directional association between a subject entity and an object entity, qualified by a relationship code and bounded by effective dates. This structure underpins features including customer hierarchies, contact assignments, organizational rollups, and account ownership models.

From a Data Vault modeling perspective, the mined FK structure suggests a satellite-leaning classification. The table carries descriptive attributes (relationship code, status, dates, comments, and numerous descriptive flexfield and additional-information columns) alongside references to a primary party, which is characteristic of satellite-style descriptive storage rather than a pure hub of business keys.

Key Information Stored

The primary key is HZ_RELATIONSHIPS_PK, composed of RELATIONSHIP_ID and DIRECTIONAL_FLAG. The unique index HZ_RELATIONSHIPS_U1 mirrors this combination, making RELATIONSHIP_ID plus DIRECTIONAL_FLAG the documented business-key candidate. RELATIONSHIP_ID is the surrogate identifier for the relationship instance.

The most significant columns include:

• SUBJECT_ID / SUBJECT_TYPE / SUBJECT_TABLE_NAME — the source entity of the relationship, with its type and originating table.
• OBJECT_ID / OBJECT_TYPE / OBJECT_TABLE_NAME — the target entity of the relationship.
• PARTY_ID — the foreign key to HZ_PARTIES, anchoring the relationship to a party record.
• RELATIONSHIP_CODE / RELATIONSHIP_TYPE — the classification of the relationship (for example, contact-of, subsidiary-of).
• DIRECTIONAL_FLAG / DIRECTION_CODE — controls whether the relationship is treated as one-directional.
• START_DATE / END_DATE / STATUS — effective dating and lifecycle state.
• PERCENTAGE_OWNERSHIP — used for ownership relationships such as corporate hierarchy stakes.
• COMMENTS — free-text notes on the relationship.
• OBJECT_VERSION_NUMBER — optimistic locking control for concurrent updates.
• ATTRIBUTE1–20 and GLOBAL_ATTRIBUTE1–20 — descriptive flexfields for customer extensions.
• ADDITIONAL_INFORMATION1–30 — supplementary extensible data.
• CONTENT_SOURCE_TYPE / ACTUAL_CONTENT_SOURCE — origin of the relationship record.

Common Use Cases and Queries

Typical scenarios involve resolving party-to-party links, walking customer hierarchies, and reporting on contact assignments. A common query joins the table to HZ_PARTIES to resolve party names:

SELECT r.relationship_id, r.relationship_code, r.subject_id, r.object_id, p.party_name
FROM hz_relationships r
JOIN hz_parties p ON p.party_id = r.party_id
WHERE r.status = 'A' AND SYSDATE BETWEEN NVL(r.start_date, SYSDATE) AND NVL(r.end_date, SYSDATE);

Reporting use cases include active relationship extracts by RELATIONSHIP_CODE, effective-dated relationship audits using START_DATE and END_DATE, and ownership reports leveraging PERCENTAGE_OWNERSHIP. The DIRECTIONAL_FLAG must be included in predicates to distinguish directional variants of the same RELATIONSHIP_ID.

Related Objects

HZ_RELATIONSHIPS participates in several referential relationships. It references HZ_PARTIES through PARTY_ID, and references FND_OBJECT_INSTANCE_SETS through both SUBJECT_TYPE and OBJECT_TYPE. Two dependent tables reference it directly:

• HZ_HIERARCHY_NODES — references HZ_RELATIONSHIPS.RELATIONSHIP_ID, linking hierarchy structures to relationship rows.
• HZ_ORG_CONTACTS — references HZ_RELATIONSHIPS through PARTY_RELATIONSHIP_ID, tying organizational contacts to their underlying party relationships.

Together with HZ_PARTIES, FND_OBJECT_INSTANCE_SETS, HZ_HIERARCHY_NODES, and HZ_ORG_CONTACTS, these objects form the referential cluster surrounding HZ_RELATIONSHIPS and are the primary candidates for join-based reporting and dependency analysis.