Search Results person_pre_name_adjunct

Overview

The CS_SR_PARTY_ADDRESS_V view is a Service (CS) module database object owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes address and identity information for every party registered in the Trading Community Architecture (TCA) registry, presenting that data in a denormalized, report-friendly format. Rather than requiring callers to join multiple TCA address tables, the view delivers a single concatenated ADDRESS column alongside discrete components such as city, state, province, postal code, and country.

The view is primarily consumed by Service Request (SR) functionality, where agent-facing screens and correspondence templates must display a party's location without traversing the full TCA address model. Because it is a view and not a table, it carries no stored data of its own; every query is resolved against the underlying HZ_PARTIES record at runtime. The metadata confirms the object is VALID in both the 12.1.1 and 12.2.2 releases, with HZ_PARTIES registered as a synonym reference rather than a direct base table.

Underlying Base Objects

The view is defined exclusively over HZ_PARTIES, the master TCA table holding party records for persons, organizations, and groups. The join is implicit—there is no join predicate in the view text because the view selects directly from that single source, projecting a subset of HZ_PARTIES columns plus the constructed ADDRESS expression.

Notably, the view reads the ADDRESS1 through ADDRESS4 columns directly from HZ_PARTIES rather than from HZ_LOCATIONS or HZ_PARTY_SITES. This design means the view reflects the party-level address attributes stored on the party record itself, which in TCA is typically the "party" address used for identification and display rather than a specific site address. Consequently, multi-site parties may show only their primary or party-level address here.

Key Columns

• ADDRESS — A concatenation of ADDRESS1 with ADDRESS2, ADDRESS3, and ADDRESS4, each appended with a semicolon separator when non-null. This is the view's signature column and the reason it is useful for display and mail-merge purposes.
• PARTY_ID — Primary identifier of the party; the join key back to HZ_PARTIES and to other TCA and Service objects.
• PARTY_NAME / PARTY_NUMBER — The party's display name and system-assigned party number, used for identification in reports.
• PARTY_TYPE — Classifies the record as a person, organization, or group.
• KNOWN_AS — The alternate or "known as" name for the party, captured as a separate attribute on HZ_PARTIES. This column answers the frequent search for known-as identity data, allowing reports to display both a legal name and an operating name.
• STATUS — The party's active/inactive status flag.
• PERSON_LAST_NAME, PERSON_FIRST_NAME, PERSON_PRE_NAME_ADJUNCT — Person-specific name components, populated for party type PERSON.
• EMAIL_ADDRESS — The party's electronic mail address.
• CITY, STATE, PROVINCE, POSTAL_CODE, COUNTRY — Discrete geographic components accompanying the concatenated address.

Common Use Cases and Queries

Service organizations use this view for SR agent dashboards, correspondence generation, and party lookups by name or known-as identifier. A typical query retrieves the full address block for a given party:

SELECT party_id, party_name, known_as, address, city, state, postal_code, country FROM apps.cs_sr_party_address_v WHERE party_id = :p_party_id;

For locating a party by its known-as name, the view removes the need to reference HZ_PARTIES directly:

SELECT party_number, party_name, known_as, address FROM apps.cs_sr_party_address_v WHERE UPPER(known_as) LIKE UPPER(:search_text)||'%' AND status = 'A';

Because the view contains no filtering, queries against large TCA installations should always constrain on PARTY_ID, PARTY_NUMBER, or an indexed party attribute. Reports requiring site-specific addresses should query HZ_PARTY_SITES and HZ_LOCATIONS instead, as this view exposes only party-level address fields.