Results for “ams_p_event_reg_contacts_v”

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

Overview

AMS_P_EVENT_REG_CONTACTS_V is a public Oracle E-Business Suite view owned by the APPS schema and registered as VALID in the AMS (Marketing) product family. It presents the registration contact details of participants registered to a marketing event, exposing one row per event registration record with the associated event offer, registrant party, registrant customer account, and registration status information. In EBS 12.1.1 and 12.2.2, the view functions as a reporting and integration surface for Oracle Marketing event enrollment data. It abstracts away several joins between the registration transaction table and the marketing lookup views, allowing downstream reports, concurrent programs, OBIEE extracts, and custom integrations to retrieve registration contact information without replicating the underlying join logic. Because it is a public view, it carries the stability expectations of the Apps data model and is suitable for use in customer-facing queries and interfaces rather than direct access to the base registration table. The user search term registrant_account_id corresponds directly to a column exposed by this view, indicating that this view is the documented access path for retrieving the customer account associated with an event registrant.

Underlying Base Objects

The view text defines a four-way join across documented base objects:

• AMS_EVENT_REGISTRATIONS (aliased REG) — the primary transactional source, providing event registration, confirmation code, cancellation code, registrant identifiers, and registration date.
• AMS_EVENT_OFFERS_VL (aliased EVO) — the event offer entity, supplying the offer name and the offer-level user status.
• AMS_USER_STATUSES_VL (aliased AUS) — the status lookup view, supplying the registration status identifier and name.
• AMS_PARTY_CUSTOMERS_V (aliased HZP) — the customer party view over the TCA party model, supplying the customer name for the registrant party.

The joins are: REG.EVENT_OFFER_ID = EVO.EVENT_OFFER_ID, EVO.USER_STATUS_ID = AUS.USER_STATUS_ID, and REG.REGISTRANT_PARTY_ID = HZP.PARTY_ID. Note that the registrant contact resolution is intentionally limited: the view exposes REGISTRANT_CONTACT_ID from the registration row and the party-level customer name from AMS_PARTY_CUSTOMERS_V, with the contact name position populated by a literal NULL in the view text, surfacing as the REGISTRANT_CONTACT_NAME column.

Key Columns

• EVENT_OFFER_ID / EVENT_OFFER_NAME — identifies the marketing event offer to which the registration belongs; the name is sourced from the translated (VL) offer view.
• EVENT_REGISTRATION_ID — the unique registration record identifier and the natural primary key for reporting.
• CONFIRMATION_CODE / CANCELLATION_CODE — the codes used operationally in event correspondence and self-service cancellation flows.
• REGISTRANT_PARTY_ID / REGISTRANT_PARTY_NAME — the TCA party identifier and resolved customer name for the registrant.
• REGISTRANT_ACCOUNT_ID — the customer account identifier associated with the registrant on the registration record; this is the column most commonly searched for when linking registrations back to account-level reporting.
• REGISTRANT_CONTACT_ID / REGISTRANT_CONTACT_NAME — the contact identifier and contact name positions; the name is returned as NULL by the view definition.
• DATE_REGISTRATION_PLACED — the date the registration was created, supporting time-based analysis.
• REGISTRATION_STATUS_ID / REGISTRATION_STATUS_NAME — the status of the event offer as resolved through AMS_USER_STATUSES_VL.

Common Use Cases and Queries

Typical uses include registrant roster reports, account-level event participation analysis, confirmation and cancellation tracking, and integration feeds that publish event registrations to external CRM or analytics platforms.

Basic registration roster for an event offer:

SELECT event_offer_name,
       event_registration_id,
       registrant_party_name,
       registrant_account_id,
       date_registration_placed,
       registration_status_name
FROM   ams_p_event_reg_contacts_v
WHERE  event_offer_id = :p_event_offer_id
ORDER BY date_registration_placed;

Locating registrations by account, which is the precise use case implied by the registrant_account_id search:

SELECT event_offer_name,
       event_registration_id,
       confirmation_code,
       registrant_party_name
FROM   ams_p_event_reg_contacts_v
WHERE  registrant_account_id = :p_account_id;

Volume analysis by event and status:

SELECT event_offer_name,
       registration_status_name,
       COUNT(*) registration_count
FROM   ams_p_event_reg_contacts_v
GROUP BY event_offer_name, registration_status_name;

Queries should be filtered on EVENT_OFFER_ID, REGISTRANT_PARTY_ID, REGISTRANT_ACCOUNT_ID, or DATE_REGISTRATION_PLACED wherever possible, since the view performs multi-view joins and unfiltered scans against high-volume registration data are expensive. Where the contact name is required, it must be resolved separately against the TCA contact tables, as the view returns NULL for REGISTRANT_CONTACT_NAME.