Results for “asf_email_contact_points_v”

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

Overview

ASF_EMAIL_CONTACT_POINTS_V is a reporting and integration view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 code lines, classified under the ASF – Sales Online product family. Per the ETRM metadata, the object is described simply as "Used for email popup," indicating that its primary purpose is to supply a filtered, presentation-ready result set of email contact points that the Sales Online (ASF) forms and associated popup windows consume at runtime.

Rather than exposing the entire contents of the trading community contact point repository, the view restricts its output to records where the contact point type is EMAIL and the status is either active (A) or inactive (I). This restriction makes the view a lightweight, purpose-built access path for email address selection, lookup, and validation within order capture, quoting, and customer-facing Sales Online flows. Because it is a view and not a table, it carries no storage of its own and inherits the read consistency and security posture of the underlying base objects.

The ETRM record also notes "Not implemented in this database" for the implementation/DBA data section. This indicates that the view is a seeded, shipped definition delivered with the application rather than a customer-specific or database-local construct, and it may not physically exist in every environment where ASF is not fully installed.

Underlying Base Objects

The view text confirms a two-table join. The driving table is HZ_CONTACT_POINTS, aliased EML, which is the Oracle Trading Community Architecture (TCA) repository for all contact point types including phone, fax, email, and URL. Every column projected from the view that carries business data—CONTACT_POINT_ID, EMAIL_ADDRESS, EMAIL_FORMAT, PRIMARY_FLAG, DO_NOT_USE_FLAG, and the DFF attribute columns—originates from this table.

The second object is AR_LOOKUPS, aliased CODE_STATUS, joined on the STATUS column. This lookup supplies the decoded STATUS_MEANING value through the MEANING column. Notably, both lookup predicates are outer-joined (indicated by the (+) syntax), so an email contact point is returned even when no matching CODE_STATUS lookup row exists; in that case STATUS_MEANING is null.

The filter set is narrow and explicit: CONTACT_POINT_TYPE must equal 'EMAIL', and STATUS must be in ('A','I'). Records in other statuses, such as deleted or merged, are excluded by design. The join to AR_LOOKUPS is constrained to LOOKUP_TYPE = 'CODE_STATUS'.

Key Columns

• ROW_ID — the EML.ROWID pseudo-column, used by Oracle Forms for row-level identification and update processing.
• CONTACT_POINT_ID — primary key of the underlying HZ_CONTACT_POINTS record.
• CONTACT_POINT_TYPE — always 'EMAIL' in this view.
• STATUS / STATUS_MEANING — the code ('A' or 'I') and its decoded meaning from AR_LOOKUPS.
• EMAIL_ADDRESS, EMAIL_FORMAT — the actual address string and its format classification.
• PRIMARY_FLAG, DO_NOT_USE_FLAG — indicators for primary address designation and suppression.
• OWNER_TABLE_NAME, OWNER_TABLE_ID — identify the parent entity (for example, a party or location) that owns the contact point.
• ORIG_SYSTEM_REFERENCE — cross-reference to the originating source system.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — descriptive flexfield segments.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, plus REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

Typical usage centers on resolving an email address for a given owner entity during Sales Online popup invocation, or auditing which parties hold active versus inactive email addresses.

SELECT contact_point_id, email_address, primary_flag
FROM   asf_email_contact_points_v
WHERE  owner_table_name = 'HZ_PARTIES'
AND    owner_table_id   = :party_id
AND    status           = 'A';

To surface suppressed or inactive addresses for data-quality review:

SELECT owner_table_id, email_address, status_meaning
FROM   asf_email_contact_points_v
WHERE  do_not_use_flag = 'Y'
OR     status = 'I';

Because the view already filters CONTACT_POINT_TYPE and status, callers avoid re-implementing those predicates and receive a consistent, decoded result set suitable for both form-driven popups and lightweight integration extracts.