Search Results cont_em




Overview
Explore in AI Chat

Overview

APPS.CSC_GS_CUSTOMERS_PER_V is an Oracle E-Business Suite view that presents a consolidated, denormalized picture of customer parties together with their associated contact points. It belongs to the Customer Care / TeleService schema family (the CSC object prefix) and is intended to serve reporting, search, and integration requirements where customer identity data must be joined with telephone and e-mail contact information in a single result set.

The suffix "PER_V" indicates a person-oriented presentation layer, and the column prefixes (obj_ and cont_) reflect the view's dual purpose: it exposes the "object" customer record alongside its "contact" attributes. The view is defined in the APPS schema and is available in both EBS 12.1.1 and 12.2.2, where it is commonly consumed by OA Framework pages, concurrent programs, and custom reports that need a flat customer-contact projection without authoring the underlying TCA joins manually.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view is defined over three base objects, all referenced through public synonyms in the APPS schema:

  • HZ_PARTIES (SYNONYM) — the Trading Community Architecture (TCA) master entity table, supplying party identity, naming, group type, and address attributes.
  • HZ_CUST_ACCOUNTS (SYNONYM) — the customer account table, supplying account number, account name, and account-level audit information.
  • HZ_CONTACT_POINTS (SYNONYM) — the contact point table, supplying telephone and e-mail contact records linked to the party.

The view text shows that HZ_CONTACT_POINTS is joined more than once within the definition, producing separate aliases (cont_ph for phone contact points and cont_em for e-mail contact points). This dual reference explains why the view exposes both obj_contact_point_id and obj_email_id. Because these are TCA base tables, any customization or extension of TCA (for example, descriptive flexfields) is not surfaced here; the view is a fixed projection.

Key Columns

The columns are grouped by the two logical concerns of the view. The object-level columns derive from HZ_PARTIES and HZ_CUST_ACCOUNTS:

  • obj_party_id, obj_party_name, obj_party_number, obj_party_type, obj_group_type — party identity and classification.
  • obj_title, obj_first_name, obj_middle_name, obj_last_name, obj_full_name — person name components, where obj_full_name is concatenated from first and last name.
  • obj_cust_account_id, obj_account_number, obj_account_name — customer account identity.
  • obj_address1 through obj_address4, obj_city, obj_state, obj_postal_code, obj_province, obj_country — address attributes; obj_partial_address is built by nested DECODE logic that concatenates non-null address lines with semicolon separators.

The contact-level columns derive from HZ_CONTACT_POINTS:

  • obj_contact_point_id — the phone contact point identifier; obj_email_id — the e-mail contact point identifier.
  • obj_phone_country_code, obj_phone_area_code, obj_phone_number, obj_phone_extension, obj_phone_type — telephony details, where obj_phone_type maps to the phone line type.
  • obj_area_code_phone_number — a concatenation of area code and phone number for display purposes.
  • obj_cust_id_last_update_date, obj_last_update_date, obj_cont_last_update_date, obj_email_last_update_date — audit timestamps recording the last update of each contributing record.

Common Use Cases and Queries

The view is typically used for customer lookup, contact verification, and outbound communication extracts. A representative query retrieves a customer's display name and phone number by account number:

  • SELECT obj_party_name, obj_account_number, obj_area_code_phone_number FROM apps.csc_gs_customers_per_v WHERE obj_account_number = :p_account;
  • SELECT obj_full_name, obj_email_id, obj_phone_number FROM apps.csc_gs_customers_per_v WHERE obj_party_id = :p_party_id;
  • SELECT obj_account_name, obj_partial_address, obj_city, obj_country FROM apps.csc_gs_customers_per_v WHERE obj_party_number = :p_number;

Because the view aggregates person-level and account-level attributes, consumers should be aware that a single party may appear across multiple rows when multiple phone or e-mail contact points exist for that party and account combination. Reports requiring one row per customer must therefore apply DISTINCT or aggregate logic. The view does not surface contact point primary flags or status filters, so callers requiring only active or primary contact points should join back to HZ_CONTACT_POINTS directly. Where the metadata is silent on view-level joins (the excerpt truncates the FROM clause), the documented base-object list remains the authoritative statement of lineage.