Search Results obj_attribute2




Overview
Explore in AI Chat

Overview

The CSC_GS_CUSTOMERS_PER_ADV_V view is a Customer Care (CSC) module database object owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to support the search operation performed against customer information within the Contact Center form. Rather than forcing the form to query the full normalized TCA (Trading Community Architecture) model directly, the view projects party, customer account, and contact point attributes into a single flattened row per customer, so the Advanced Customer Search region can resolve and display results efficiently.

The view is classified as a VIEW object type and is reported with a status of VALID. It is not a customer data source in its own right; it is a read-only reporting and lookup surface. The naming pattern ending in _V and the prefix CSC_GS_ indicate a Customer Care "GS" (general/search) view built specifically for form-level retrieval rather than for transactional DML.

The column naming convention is deliberate. Most columns carry a PTY_ prefix, denoting "party," which helps a caller distinguish fields belonging to HZ_PARTIES from those sourced from other base objects in the join. This matters because the view exposes similarly named attributes originating from multiple tables, and the prefix prevents ambiguity in the form's result grid and in any custom code that consumes the view.

Underlying Base Objects

According to the documented ETRM metadata, the view is defined over the following referenced base objects:

  • HZ_PARTIES (SYNONYM) – supplies the core party identity, name components, party type, group type, and the denormalized address columns (ADDRESS1–ADDRESS4, CITY, STATE, POSTAL_CODE, PROVINCE, COUNTRY).
  • HZ_CUST_ACCOUNTS (SYNONYM) – supplies the customer account identifier, account number, and account name, joined to the party record.
  • HZ_RELATIONSHIPS (SYNONYM) – supports relationship resolution between parties and accounts within the customer model.
  • CSC_GS_CONTACTS_V (VIEW) – provides the contact point data (phone, email, and associated contact identifiers) surfaced as the PTY_CONTACT_POINT_ID, PTY_EMAIL_ID, and phone columns.
  • AR_LOOKUPS (VIEW) – used for lookup code decoding, consistent with standard EBS lookup-driven display values.

Because CSC_GS_CONTACTS_V is itself a view, the customer search view is effectively a layered construct: the contact point projection is resolved through a subordinate Customer Care view before being joined to the party and account data. The synonyms reference the underlying TCA tables, so the view remains insulated from physical table reorganization.

Key Columns

The view exposes a broad set of customer attributes. The principal columns include:

The presence of multiple last-update columns from different base objects is notable: it allows a consumer to determine which component of the customer record changed most recently, which is useful for cache invalidation or delta detection in integration scenarios.

Common Use Cases and Queries

The primary use case is powering the Advanced Customer Search in the Contact Center form, where an agent supplies partial name, account number, phone, or email criteria and the form queries this view. Secondary use cases include custom reports, dashboards, and integrations that need a flattened, denormalized customer profile without navigating the TCA schema directly.

A typical search query filtering on the searchable columns would resemble the following:

SELECT pty_party_id,
       pty_party_number,
       pty_party_name,
       pty_account_number,
       pty_full_name,
       pty_area_code_phone_number,
       pty_email_id,
       pty_city,
       pty_state
  FROM apps.csc_gs_customers_per_adv_v
 WHERE pty_party_name LIKE :p_name
    OR pty_account_number = :p_acct_num
    OR pty_area_code_phone_number LIKE :p_phone;

Because the view is owned by APPS, consumers should reference it as APPS.CSC_GS_CUSTOMERS_PER_ADV_V and rely on the standard EBS APPS synonym or grant model rather than querying base TCA tables independently. This preserves the form's filtering semantics, such as the DECODE-based partial address construction and the party-prefixed column contract, ensuring consistent results between the contact center UI and any downstream reporting that consumes the same object.