Search Results object_table_name

Overview

QA_HZ_PARTY_RELATIONSHIPS_V is a compatibility view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exists because the Trading Community Architecture (TCA) obsoleted the legacy HZ_PARTY_RELATIONSHIPS view in Release 12. The Quality (QA) product delivers this replacement view to ease migration and uptake for customers, customizations, and integrations that referenced the pre-R12 name. It preserves the legacy application programming interface (API) surface so that dependent code continues to function without immediate rewrites.

The view exposes party-to-party relationships stored in the TCA relationship model. Its primary role is backward compatibility: it allows legacy queries, concurrent programs, and custom reports written against HZ_PARTY_RELATIONSHIPS to resolve against the current HZ_RELATIONSHIPS base table through a stable projected interface. Rather than a general-purpose reporting object, it is best understood as a migration shim scoped to non-directional (forward) party relationships.

Underlying Base Objects

The view is defined over a single documented base object: the HZ_RELATIONSHIPS synonym. This synonym resolves to the TCA table that stores all relationship records across subject and object entity types. The view filters that table down to the subset that replicates the legacy HZ_PARTY_RELATIONSHIPS semantics.

The defining filter is: SUBJECT_TABLE_NAME = 'HZ_PARTIES' AND OBJECT_TABLE_NAME = 'HZ_PARTIES' AND DIRECTIONAL_FLAG = 'F'. In other words, only rows where both the subject and the object of the relationship are parties are returned, and only forward-direction (non-directional) records are included. The view does not expose the table name discriminator columns themselves; instead it fixes them implicitly through the WHERE clause, presenting only party-to-party relationships. Because it references the synonym rather than the table directly, it remains valid across the standard APPS synonym configuration in both 12.1.1 and 12.2.2.

Key Columns

• PARTY_RELATIONSHIP_ID — Alias of RELATIONSHIP_ID, the surrogate primary key identifying the relationship record.
• SUBJECT_ID — The party identifier of the relationship subject (the originating party).
• OBJECT_ID — The party identifier of the relationship object (the related party).
• PARTY_ID — The party identifier associated with the relationship, retained for legacy compatibility.
• PARTY_RELATIONSHIP_TYPE — Alias of RELATIONSHIP_CODE, indicating the relationship type (for example, contact, employee, or other coded relationship).
• DIRECTIONAL_FLAG — Hard-coded as 'N' in the projection, reinforcing that the view returns only non-directional relationships.
• COMMENTS — Free-text notes attached to the relationship.
• START_DATE / END_DATE — The effective date range during which the relationship is active.
• STATUS — The record status (for example, active or inactive).
• OBJECT_VERSION_NUMBER — Optimistic locking column supporting concurrent update control.

Common Use Cases and Queries

Typical usage centers on legacy compatibility: reports, interfaces, and customizations that previously queried HZ_PARTY_RELATIONSHIPS can be repointed to QA_HZ_PARTY_RELATIONSHIPS_V with minimal change. It is also useful for quickly enumerating active party-to-party relationships without writing the table-name and directional filters manually.

Sample: retrieve active relationships for a given party.

• SELECT party_relationship_id, subject_id, object_id, party_relationship_type, start_date, end_date, status FROM apps.qa_hz_party_relationships_v WHERE status = 'A' AND TRUNC(SYSDATE) BETWEEN start_date AND NVL(end_date, SYSDATE);
• SELECT party_relationship_id, subject_id, object_id, party_relationship_type FROM apps.qa_hz_party_relationships_v WHERE subject_id = :p_party_id;

Because the view filters to DIRECTIONAL_FLAG = 'F', consumers requiring directional or cross-entity-type relationships must query HZ_RELATIONSHIPS directly and supply their own subject/object table filters. For current development, Oracle recommends the underlying TCA objects; QA_HZ_PARTY_RELATIONSHIPS_V should be treated as a transitional compatibility layer.