Results for “obj_state”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CSC_GS_CUSTOMERS_PER_V is a read-only database view owned by the APPS schema within Oracle E-Business Suite, and it belongs to the CSC (Customer Care) product family. As documented in the ETRM metadata for release 12.2.2, its stated purpose is to "perform search operation on customer information in the contact center form." In practical terms, the view flattens and denormalizes party, customer account, and contact point data into a single queryable structure that the Contact Center agent-facing form can query with flexible search criteria without having to join the highly normalized TCA (Trading Community Architecture) tables at runtime.

Because the object is a view rather than a table, it holds no data of its own and cannot be written to directly. It presents a consistent, integration-friendly projection of customer master information, which makes it useful both for the originating Customer Care form and for downstream reporting and integration scenarios that need a consolidated customer picture. The object carries a status of VALID in the dictionary.

Underlying Base Objects

The documented referenced base objects for this view are three HZ synonyms: HZ_CONTACT_POINTS, HZ_CUST_ACCOUNTS, and HZ_PARTIES. These map to the core TCA tables that model customers in EBS. HZ_PARTIES stores the party record (person or organization, including name and address attributes). HZ_CUST_ACCOUNTS stores the customer account relationship, including account number and account name. HZ_CONTACT_POINTS stores phone, email, and other contact mechanisms associated with a party.

The view joins these sources on party and account identifiers, drawing party columns from HZ_PARTIES, account columns from HZ_CUST_ACCOUNTS, and phone/email columns from HZ_CONTACT_POINTS. The presence of both a phone contact point identifier and an email contact point identifier in the select list indicates that contact points are joined in a manner that surfaces both communication channels for the customer record.

Key Columns

• OBJ_PARTY_ID / OBJ_PARTY_NAME / OBJ_PARTY_NUMBER — the party identifier, display name, and party number from HZ_PARTIES.
• OBJ_CUST_ACCOUNT_ID / OBJ_ACCOUNT_NUMBER / OBJ_ACCOUNT_NAME — the customer account identity and display values from HZ_CUST_ACCOUNTS.
• OBJ_PARTY_TYPE / OBJ_GROUP_TYPE — distinguish person versus organization and the party group classification.
• OBJ_TITLE, OBJ_FIRST_NAME, OBJ_MIDDLE_NAME, OBJ_LAST_NAME, OBJ_FULL_NAME — component and concatenated person name attributes.
• OBJ_CONTACT_POINT_ID, OBJ_EMAIL_ID — phone and email contact point identifiers.
• OBJ_PHONE_COUNTRY_CODE, OBJ_PHONE_AREA_CODE, OBJ_PHONE_NUMBER, OBJ_PHONE_EXTENSION, OBJ_PHONE_TYPE, OBJ_AREA_CODE_PHONE_NUMBER — telephone detail used for search and display.
• OBJ_ADDRESS1 through OBJ_ADDRESS4, OBJ_PARTIAL_ADDRESS, OBJ_CITY, OBJ_STATE, OBJ_POSTAL_CODE, OBJ_PROVINCE, OBJ_COUNTRY — structured and concatenated address data.
• OBJ_LAST_UPDATE_DATE, OBJ_CUST_ID_LAST_UPDATE_DATE, OBJ_CONT_LAST_UPDATE_DATE, OBJ_EMAIL_LAST_UPDATE_DATE — audit timestamps for the party, account, phone, and email records.

Common Use Cases and Queries

The primary consumer is the Customer Care contact center search form. A typical search retrieves customer records by name or account number and returns contact and address detail for agent display:

• Search by name: SELECT OBJ_PARTY_ID, OBJ_FULL_NAME, OBJ_ACCOUNT_NUMBER, OBJ_AREA_CODE_PHONE_NUMBER FROM CSC_GS_CUSTOMERS_PER_V WHERE UPPER(OBJ_PARTY_NAME) LIKE 'ACME%';
• Lookup by account: SELECT OBJ_CUST_ACCOUNT_ID, OBJ_ACCOUNT_NAME, OBJ_EMAIL_ID FROM CSC_GS_CUSTOMERS_PER_V WHERE OBJ_ACCOUNT_NUMBER = :account_number;
• Search by phone: SELECT OBJ_PARTY_ID, OBJ_FULL_NAME FROM CSC_GS_CUSTOMERS_PER_V WHERE OBJ_PHONE_NUMBER = :phone;
• Identify recently changed records: SELECT OBJ_PARTY_ID, OBJ_LAST_UPDATE_DATE FROM CSC_GS_CUSTOMERS_PER_V WHERE OBJ_LAST_UPDATE_DATE >= SYSDATE - 7;

Because the view aggregates TCA sources, it is also convenient for ad hoc reporting where a single-row-per-customer display is required. Queries should filter on the indexed underlying identifier columns where possible, and consumers should treat the view as read-only, since it exposes no insert, update, or delete capabilities.