Results for “as_party_relationships_v”

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

Overview

AS_PARTY_RELATIONSHIPS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, registered under the AS - Sales Foundation product. Its documented status is VALID in both the 12.1.1 and 12.2.2 releases. The view exposes the party-to-party relationship model maintained by Oracle Trading Community Architecture (TCA), presenting one row per relationship record whose lifecycle status is either Active ('A') or Inactive ('I'). It is the presentation-layer counterpart to the physical relationship store, offering a stable, denormalized access point for forms, concurrent programs, and downstream reporting against relationship data without requiring consumers to query HZ_RELATIONSHIPS directly.

In practice the view functions as a read façade over TCA relationships. Because its predicate filters on STATUS, callers receive only those relationships that have been logically created and are either currently active or have been inactivated, while records pending purge or otherwise flagged are excluded.

Underlying Base Objects

The view is defined over a single documented base object, HZ_RELATIONSHIPS, accessed through a synonym in the APPS schema. The defining text selects the relationship identifier and both endpoints of the relationship (SUBJECT_ID and OBJECT_ID), the party context, the relationship classification, and the full set of descriptive, date-effectivity, WHO-audit, concurrent-program, and DFF attribute columns, terminating with the CONTENT_SOURCE_TYPE column, which indicates the source system or origin from which the relationship record was created. The WHERE clause restricts rows to STATUS IN ('A','I').

All structural semantics therefore derive from HZ_RELATIONSHIPS. The view introduces no joins; it is a projection and filter, so column-level behavior, nullability, and datatypes mirror the base table.

Key Columns

• RELATIONSHIP_ID — the unique identifier of the relationship record; the primary correlation key for the row.
• SUBJECT_ID / OBJECT_ID — the two party identifiers participating in the relationship. DIRECTIONAL_FLAG determines whether the association is to be interpreted with direction.
• PARTY_ID — the party context under which the relationship is held (typically the subject party).
• RELATIONSHIP_CODE — the relationship classification (documented column list labels this PARTY_RELATIONSHIP_TYPE), referencing relationship type definitions.
• START_DATE / END_DATE — effectivity window for the relationship; NULL end date denotes an open-ended association.
• STATUS — Active ('A') or Inactive ('I'); the only values returned by the view.
• CONTENT_SOURCE_TYPE — identifies the originating content source of the record, permitting consumers to distinguish relationships created or imported from differing source systems.
• Audit and program columns — LAST_UPDATE_DATE, CREATION_DATE, LAST_UPDATED_BY, CREATED_BY, LAST_UPDATE_LOGIN, WH_UPDATE_DATE, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE support auditing and bulk-load reconciliation.
• ATTRIBUTE1–20 and GLOBAL_ATTRIBUTE_CATEGORY/GLOBAL_ATTRIBUTE1–20 — descriptive flexfield and global descriptive flexfield context/value pairs.

Common Use Cases and Queries

Typical uses include resolving a party's active relationships, identifying relationships by type, and reporting on relationships sourced from specific content sources. The following returns active relationship types for a given party:

SELECT relationship_id, subject_id, object_id,
       relationship_code, start_date, end_date
FROM   apps.as_party_relationships_v
WHERE  status = 'A'
AND    (subject_id = :p_party_id OR object_id = :p_party_id);

Filtering by the searched column isolates records by origin, useful when reconciling imported versus locally created relationships:

SELECT relationship_id, subject_id, object_id, relationship_code,
       content_source_type
FROM   apps.as_party_relationships_v
WHERE  content_source_type = :p_content_source_type;

Because the view exposes the DFF and global DFF columns, it is also a convenient source for extracts that must carry descriptive flexfield context. Consistently apply the STATUS, effectivity, and CONTENT_SOURCE_TYPE predicates to avoid over-broad result sets.