Results for “ast_l_contact_points_v”

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

Overview

AST_L_CONTACT_POINTS_V is a TeleSales (AST) module view owned by the APPS schema and defined in Oracle E-Business Suite 12.1.1 and 12.2.2. Its purpose is to consolidate a party's email address with each of the telephone contact points registered against that same party, producing a single denormalized row per party/phone-contact-point pair. The view joins the party-level contact information exposed by AS_PARTY_CONTACTS_V to the raw contact-point records in HZ_CONTACT_POINTS, which is the foundation table of the Oracle Trading Community Architecture (TCA) contact point model.

The view is frequently surfaced in reporting and integration contexts where a TeleSales agent, a marketing campaign, or a downstream interface requires a combined telephony and email profile for a party. It is commonly reached indirectly by developers who search for as_party_contacts_v, the base view that AST_L_CONTACT_POINTS_V extends. The ETRM metadata records the object as VALID with a documented status of APPS ownership, and the documented columns include CUSTOMER_ID, PHONE_ID, PARTY_ID, CONTACT_POINT_ID, CONTACT_POINT_TYPE, EMAIL_ADDRESS, PHONE_TYPE, AREA_CODE, PHONE_NUMBER, and EXTENSION.

Underlying Base Objects

The documentation identifies two referenced base objects: AS_PARTY_CONTACTS_V (a VIEW) and HZ_CONTACT_POINTS (a SYNONYM). The view definition demonstrates the join relationship between them:

• AS_PARTY_CONTACTS_V (alias CONT) — supplies the party identity and the email address. The view text references CONT.PARTY_ID and CONT.EMAIL_ADDRESS.
• HZ_CONTACT_POINTS (alias PHONE) — supplies the telephone attributes. The view text references PHONE.CONTACT_POINT_ID, PHONE.CONTACT_POINT_TYPE, PHONE.PHONE_LINE_TYPE, PHONE.PHONE_AREA_CODE, PHONE.PHONE_NUMBER, and PHONE.PHONE_EXTENSION.

The join is not made on a stored foreign key but through the polymorphic owner columns of HZ_CONTACT_POINTS: PHONE.OWNER_TABLE_NAME must equal 'HZ_PARTIES' and PHONE.OWNER_TABLE_ID must equal CONT.PARTY_ID. In other words, the view returns only those contact points whose owner is a party record. Because the join is an equi-join between the party view and the contact-point table, a party with no phone contact points yields no rows, and a party with multiple phone records produces one row per phone record.

Key Columns

• PARTY_ID — identifier of the party in the TCA model; the effective join key between the two source objects.
• CUSTOMER_ID — the customer identifier associated with the party, as exposed through the party contacts view.
• CONTACT_POINT_ID / PHONE_ID — the unique identifier of the telephone contact point in HZ_CONTACT_POINTS.
• CONTACT_POINT_TYPE — classifies the contact point, typically distinguishing phone from email entries.
• EMAIL_ADDRESS — the party's email address carried from AS_PARTY_CONTACTS_V.
• PHONE_TYPE / PHONE_LINE_TYPE — categorizes the telephone number (for example, business, home, or mobile).
• AREA_CODE, PHONE_NUMBER, EXTENSION — the decomposed telephone number components, allowing formatting and dialing logic in TeleSales and integration layers.

Common Use Cases and Queries

The view supports TeleSales agent screens, customer contact extracts, and outbound campaign feeds. A typical query retrieves all telephone numbers for a given party:

• SELECT party_id, phone_number, area_code, extension, phone_type FROM apps.ast_l_contact_points_v WHERE party_id = :p_party_id;
• SELECT party_id, customer_id, email_address, phone_number FROM apps.ast_l_contact_points_v WHERE phone_type = 'MOBILE';

Because the view performs no filtering beyond the owner-table predicate, additional selection criteria should be applied by the caller. Consumers should also be aware that the polymorphic join may return contact points for parties whose phone data is not specifically designated as an AST contact, so business rules must validate CONTACT_POINT_TYPE where required. The view is read-only and should be treated as a reporting and integration convenience rather than a transactional data source.