Search Results sub_party_type




Overview
Explore in AI Chat

Overview

APPS.CSC_HZ_PARTY_RELATIONSHIPS_V is a supplementary view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2, registered under FND Design Data as CSC.CSC_HZ_PARTY_RELATIONSHIPS_V. It presents party-to-party relationship data drawn from the Oracle Trading Community Architecture (TCA) model, combining the relationship record itself with denormalized names, types, and job titles for both the subject and object parties. Its documented purpose is to simplify forms coding within the Customer Care (CSC) module. Oracle explicitly warns that this is a supplementary view and does not recommend querying or altering data through it, as its definition may change dramatically in subsequent minor or major releases. The view carries a VALID status in the ETRM repository.

For the user search term "sub_party_name", this view is the relevant object: it exposes a SUB_PARTY_NAME column (VARCHAR2(360)) that returns the party name of the subordinate or object side of a relationship. That column is a primary reason developers and report authors locate this view.

Underlying Base Objects

The documented referenced base objects are HZ_RELATIONSHIPS, HZ_PARTIES, HZ_ORG_CONTACTS (all synonyms), and AR_LOOKUPS (a view). HZ_RELATIONSHIPS supplies the relationship record keyed by PARTY_RELATIONSHIP_ID and the subject/object party identifiers; HZ_PARTIES supplies party names and party types for both sides; HZ_ORG_CONTACTS contributes contact attributes such as SUB_JOB_TITLE; and AR_LOOKUPS resolves relationship codes into their stored meaning via the party_relationship_type lookup. Because the view joins these objects, it flattens the TCA relationship structure into a single denormalized row per relationship with both PARTY_ID and PARTY_RELATIONSHIP_ID as identifiers. The presence of two object version numbers—one for HZ_RELATIONSHIPS and one for HZ_PARTIES—confirms the join across both base entities.

Key Columns

Common Use Cases and Queries

Typical uses include identifying contacts and their employers, resolving who reports to whom in a party hierarchy, and populating customer care screens with both sides of a relationship. Because the view is non-supported for direct query, production integrations should prefer underlying TCA tables or supported public APIs, but ad hoc reporting against the view remains common.

A representative query retrieving the subordinate party name together with its related object name and relationship meaning:

  • SELECT party_id, party_relationship_id, sub_party_name, object_name, relationship_meaning
  • FROM apps.csc_hz_party_relationships_v
  • WHERE sub_party_name IS NOT NULL
  • AND TRUNC(effective_start_date) <= TRUNC(SYSDATE)
  • AND (effective_end_date IS NULL OR TRUNC(effective_end_date) >= TRUNC(SYSDATE));

Filtering on SUB_PARTY_TYPE or relting via RELATIONSHIP_CODE against AR_LOOKUPS values allows targeted extracts of contact-to-organization associations, while the effective date columns support as-of-date reporting. All access should be read-only.