Search Results enrollee_number

Overview

APPS.AST_EVENT_ENROLLEES_V is an Oracle E-Business Suite reporting view that consolidates event registration and enrollee information drawn from the Advanced Management System (AMS) event registration tables and the Trading Community Architecture (TCA) party model. Its principal purpose is to present a denormalized, business-friendly projection of event registrants and their attendants, exposing party names, contact details, statuses, and confirmation data in a single queryable object. The view is defined with a UNION ALL, producing one logical row per registration-to-enrollee relationship across multiple registration paths, including primary registrants and associated contacts resolved through HZ_RELATIONSHIPS.

The object is particularly relevant to users searching for enrollee_number, which the view exposes as an alias for HZ_PARTIES.PARTY_NUMBER on the attendee party record. This makes the view a convenient source for retrieving the party number of the person actually enrolled or attending, as distinct from the customer or registrant party number captured elsewhere in the registration record.

Underlying Base Objects

The view is defined over the following documented base objects:

• AMS_EVENT_REGISTRATIONS (synonym) — the driving table, aliased aer, holding event registration header data such as event_registration_id, event_offer_id, attendant_account_id, confirmation_code, attended_flag, system_status_code, and reg_source_type_code.
• AMS_LOOKUPS (view) — referenced twice (al1, al2) to decode system status and registration source codes into descriptive meanings.
• HZ_PARTIES (synonym) — referenced three times (hp1, hp2, hp4) to resolve the customer, main contact, and enrollee party records.
• HZ_CONTACT_POINTS (synonym) — left-joined (hcp) to obtain the primary active phone contact point for the enrollee party.
• HZ_ORG_CONTACTS (synonym) and HZ_RELATIONSHIPS (synonym) — supporting the second branch of the UNION ALL, which resolves contacts related to organizations.

The join predicates restrict registrations to those with system_status_code in ('REGISTERED', 'WAITLISTED', 'CANCELLED') and require the registrant party and contact identifiers to match, ensuring only valid person-type registrants are returned. Lookup joins are outer and gated on enabled_flag, so decoded meanings appear only where active lookup codes exist.

Key Columns

• event_registration_id / event_offer_id — identifiers linking the row back to the registration and its event offering.
• customer_id, party_type, customer_name, title — registrant party attributes from HZ_PARTIES (hp1).
• main_contact_full_name — name of the registrant contact party (hp2), concatenated with the customer name in the second UNION branch.
• attendant_account_id — account associated with the attendant.
• enrollee_full_name — full name of the attendee party (hp4).
• enrollee_number — the HZ_PARTIES.PARTY_NUMBER of the attendee; the primary column of interest for the user's search.
• enrollee_phone_number — formatted from country code, area code, phone number, and extension, applying parentheses and 'ext' formatting as appropriate.
• system_status_code — decoded meaning of the registration status (REGISTERED, WAITLISTED, CANCELLED).
• reg_source_type_code — decoded registration source.
• confirmation_code, attended_flag, email_address — registration confirmation, attendance indicator, and enrollee email.

Common Use Cases and Queries

Typical scenarios include event attendance reporting, enrollee roster generation, and integration feeds that require party numbers for downstream systems. A representative query retrieving enrollee numbers for a given offer is:

SELECT event_offer_id, enrollee_number, enrollee_full_name, system_status_code FROM apps.ast_event_enrollees_v WHERE event_offer_id = :offer_id AND system_status_code = 'REGISTERED';

To list attendees with contact details:

SELECT customer_name, enrollee_full_name, enrollee_number, enrollee_phone_number FROM apps.ast_event_enrollees_v WHERE attended_flag = 'Y';

Because the view is a UNION ALL, callers should anticipate potential duplicate enrollee rows where multiple registration paths resolve to the same party; DISTINCT or aggregation may be required for reporting accuracy.