Search Results sub_party_name

Overview

CS_SR_HZ_RELATIONSHIPS_V is an APPS-owned database view within the Oracle E-Business Suite Service (CS) module. Its documented purpose is to expose details of Related, Subject, and Object parties associated with service request relationships. In the Trading Community Architecture (TCA) model, a relationship record in HZ_RELATIONSHIPS links two parties: a subject party and an object party. This view flattens those associations and joins them to HZ_PARTIES so that each row presents party demographic, address, and contact attributes for both sides of the relationship.

Because it sits in the APPS schema and is defined over standard TCA synonyms, the view is available to reporting tools, concurrent programs, forms personalizations, and integration interfaces without requiring direct joins to the underlying TCA tables. It is particularly relevant to users searching on sub_party_id, since the view explicitly exposes SUB_PARTY_ID as a projected column. This makes the view a convenient single source for retrieving the party identifier, party number, and party name of the subject party in a relationship, alongside the corresponding related party attributes.

Underlying Base Objects

The ETRM-documented referenced objects for this view are:

• HZ_PARTIES (SYNONYM) — the TCA master party table. The view references this twice, aliased as REL_PARTY (the related/object party) and SUB_PARTY (the subject party).
• HZ_RELATIONSHIPS (SYNONYM) — the TCA relationship table that defines the association between the subject and object parties.
• AR_LOOKUPS (VIEW) — the Receivables lookup view, typically used to decode relationship or status codes into meaningful display values.

The view therefore sits directly on the TCA foundation. Each output row is anchored by a relationship record in HZ_RELATIONSHIPS and enriched with party attributes pulled from two aliased instances of HZ_PARTIES. The lookup join supplies descriptive context for coded values.

Key Columns

The view projects parallel sets of columns for the related party (REL_ prefix) and the subject party (SUB_ prefix). Notable columns include:

• SUB_PARTY_ID — the PARTY_ID of the subject party; the primary key of the subject-side HZ_PARTIES record.
• SUB_PARTY_NUMBER, SUB_PARTY_NAME, SUB_PARTY_TYPE — the subject party's number, display name, and party type (person, organization, or group).
• REL_PARTY_ID, REL_PARTY_NUMBER, REL_PARTY_NAME, REL_PARTY_TYPE — equivalent identifier fields for the related/object party.
• SUB_/REL_ person name attributes — PERSON_PRE_NAME_ADJUNCT, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, and PERSON_NAME_SUFFIX, supporting structured person names.
• SUB_/REL_ address attributes — COUNTRY, ADDRESS1 through ADDRESS4, CITY, POSTAL_CODE, STATE, PROVINCE, COUNTY, plus a concatenated REL_ADDRESS expression built with DECODE to assemble the address lines.
• SUB_/REL_EMAIL_ADDRESS, SUB_/REL_LANGUAGE_NAME, SUB_/REL_STATUS — contact and status attributes for each party.
• REL_LAST_UPDATE_DATE and SUB_LAST_UPDATE_DATE — audit timestamps for the underlying party records.

Common Use Cases and Queries

Typical scenarios include identifying all parties related to a service request's customer, retrieving contact and address details for notification, and resolving a subject party by its identifier. A representative query locating relationships for a known subject party:

• SELECT sub_party_id, sub_party_name, rel_party_id, rel_party_name FROM cs_sr_hz_relationships_v WHERE sub_party_id = :p_party_id;
• SELECT sub_party_number, rel_party_name, rel_email_address FROM cs_sr_hz_relationships_v WHERE rel_party_type = 'PERSON';

Because the view resolves both the subject and object party in a single row, it reduces the join complexity normally required when working directly with HZ_RELATIONSHIPS and HZ_PARTIES, making it well suited to reporting and integration use cases.