Search Results cs_sr_contact_type




Overview
Explore in AI Chat

Overview

The view APPS.CS_SR_HZ_CUST_CONT_V is a Service (CS) module database object that exposes customer contact information drawn from the Oracle Trading Community Architecture (TCA) model. It consolidates party, customer account, and relationship data into a single denormalized result set intended for Service Request and contact-related reporting and integration. The view answers a common requirement in Oracle EBS 12.1.1 and 12.2.2: identifying the persons and party relationships that may serve as contacts against a customer account, together with a decoded contact-type description.

A distinctive feature of the view is its use of the CS_SR_CONTACT_TYPE lookup type. The final column, PARTY_TYPE_MEANING, is derived by joining CS_LOOKUPS on LOOKUP_TYPE = 'CS_SR_CONTACT_TYPE' and LOOKUP_CODE = PARTY_TYPE. This is the source of the cs_sr_contact_type reference that users typically encounter when searching for this object. The view therefore doubles as a decode mechanism for the contact-type lookup values maintained in the Service module, rather than relying on the raw PARTY_TYPE code.

Underlying Base Objects

The ETRM metadata documents the following base objects referenced by CS_SR_HZ_CUST_CONT_V: CS_LOOKUPS (VIEW), FND_GLOBAL (PACKAGE), HZ_CUST_ACCOUNTS (SYNONYM), HZ_PARTIES (SYNONYM), and HZ_RELATIONSHIPS (SYNONYM). The synonyms resolve to the TCA registry tables that hold party, account, and relationship data, while CS_LOOKUPS provides the Service-module lookup definitions used for the contact-type decode.

The view body is a UNION ALL of two queries. The first selects person parties directly, restricting HZ_PARTIES.PARTY_TYPE to 'PERSON' and joining HZ_CUST_ACCOUNTS with an outer join (A.PARTY_ID(+) = P.PARTY_ID) so that persons without an account are still returned. The second query returns party relationships: it joins HZ_RELATIONSHIPS so that the relationship record (R, where PARTY_TYPE = 'PARTY_RELATIONSHIP') is tied to the underlying person (P, where PARTY_TYPE = 'PERSON') through REL.PARTY_ID = R.PARTY_ID and REL.SUBJECT_ID = P.PARTY_ID. Both branches filter on STATUS IN ('A','I'), meaning only active and inactive records are exposed; other statuses are excluded.

Key Columns

  • PARTY_ID — Primary identifier of the party (person in the first branch, relationship in the second).
  • PARTY_NUMBER — The TCA-assigned party number, used as the external reference for the party.
  • PARTY_TYPE — The raw party type code, either 'PERSON' or 'PARTY_RELATIONSHIP'; this drives the lookup decode.
  • PARTY_NAME — The formatted party name as stored on HZ_PARTIES.
  • PERSON_FIRST_NAME / PERSON_LAST_NAME — The underlying person's name components; in the relationship branch these are taken from the related person P, not the relationship record.
  • ACCOUNT_NUMBER / ACCOUNT_NAME — Customer account attributes from HZ_CUST_ACCOUNTS, populated through the outer join and therefore nullable for parties without an account.
  • PARTY_TYPE_MEANING — The decoded description obtained from CS_LOOKUPS for lookup type CS_SR_CONTACT_TYPE; this is the user-facing contact type.

Common Use Cases and Queries

The view is typically queried in Service Request contact validation, LOV-style reporting, and integration extracts where a human-readable contact type is required. Because the contact type is decoded inline, consumers avoid a separate lookup join.

A basic query listing active contacts with their decoded type:

  • SELECT party_id, party_number, party_name, person_first_name, person_last_name, account_number, party_type_meaning FROM apps.cs_sr_hz_cust_cont_v;

A targeted query for a specific account or contact type:

  • SELECT party_id, party_name, account_number, party_type_meaning FROM apps.cs_sr_hz_cust_cont_v WHERE account_number = :acct AND party_type_meaning = 'Contact';

Because the view references FND_GLOBAL, it is subject to standard Multi-Org and security considerations, and callers should respect the operating unit context established at session level. Only records with STATUS of A or I are returned, so callers needing discontinued parties must query the base TCA tables directly. All access should be made through the APPS schema or the appropriate synonym, consistent with Oracle EBS 12.1.1 and 12.2.2 conventions.