Results for “ams_event_payment_status”

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

Overview

APPS.AMS_EVENT_REGISTRATIONS_V is an Oracle E-Business Suite (EBS) 12.1.1 / 12.2.2 marketing dictionary view that presents enriched event registration data for the Oracle Marketing (AMS) module. It flattens the AMS_EVENT_REGISTRATIONS transactional table, joining it to user-defined registration statuses, party (customer and contact) details, and lookup translations. The view serves as the principal reporting and integration access path for seminar, trade show, and web event registrations, exposing both the raw registration lifecycle attributes and resolved descriptive values such as the registrant's customer name, person names, and the decoded payment status meaning.

Because it consolidates denormalized descriptive columns into a single object, AMS_EVENT_REGISTRATIONS_V is the canonical source for BI Publisher reports, Discoverer worksheets, OBIEE extracts, and inbound/outbound interface programs that require registration details without re-implementing the joins. The user's search term ams_event_payment_status corresponds directly to the lookup type referenced in the view's definition: AMS_EVENT_PAYMENT_STATUS, which populates the decoded PAYMENT_STATUS_CODE column as MEANING via AMS_LOOKUPS.

Underlying Base Objects

The documented base objects are AMS_EVENT_REGISTRATIONS (synonym), AMS_LOOKUPS (view), AMS_USER_STATUSES_VL (view), HZ_PARTIES (synonym), and HZ_RELATIONSHIPS (synonym). The view text reveals the join architecture:

• AMS_EVENT_REGISTRATIONS REG — the driving table, supplying registration identifiers, statuses, flags, order references, and the coded payment status.
• AMS_USER_STATUSES_VL AUS — joined on USER_STATUS_ID to resolve the user-facing status name (AUS.NAME).
• HZ_PARTIES HZ — joined on REGISTRANT_PARTY_ID to supply the registrant party name, first name, and last name.
• AMS_LOOKUPS LKUP1 — an outer join on LOOKUP_TYPE(+) = 'AMS_EVENT_PAYMENT_STATUS' and LOOKUP_CODE(+) = REG.PAYMENT_STATUS_CODE, decoding the payment status into a meaningful description.

HZ_RELATIONSHIPS is listed as a referenced component of the consolidated object (supporting the registrant/contact party linkage). A UNION ALL structure repeats the projection, indicating the view unions registration rows with a parallel selection (for example, contact-based or account-based registrants) to yield one uniform result set.

Key Columns

• EVENT_REGISTRATION_ID, EVENT_OFFER_ID, REGISTRATION_GROUP_ID — primary registration identity and the event offer against which the registration was placed.
• CONFIRMATION_CODE, DATE_REGISTRATION_PLACED, ACTIVE_FLAG — registration confirmation, timestamp, and active state.
• USER_STATUS_ID / NAME, SYSTEM_STATUS_CODE, LAST_REG_STATUS_DATE — user status name alongside the internal system status and its last change date.
• CUSTOMER_NAME (HZ.PARTY_NAME), PERSON_FIRST_NAME, PERSON_LAST_NAME, REGISTRANT_PARTY_ID, REGISTRANT_ACCOUNT_ID, REGISTRANT_CONTACT_ID — registrant identity details.
• ATTENDEE_PARTY_ID, ATTENDANT_CONTACT_ID, ATTENDANT_ACCOUNT_ID, ATTENDED_FLAG — the actual attendee, which may differ from the registrant.
• PAYMENT_STATUS_CODE, MEANING — the coded payment status and its decoded lookup meaning from AMS_EVENT_PAYMENT_STATUS.
• CONFIRMED_FLAG, WAITLISTED_PRIORITY, CANCELLATION_CODE, CANCELLATION_REASON_CODE — workflow, waitlist, and cancellation attributes.
• ORDER_HEADER_ID, ORDER_LINE_ID, SALESREP_ID — links to the order and sales representative associated with the registration.
• EVENT_JOIN_TIME, EVENT_EXIT_TIME, ATTENDANCE_RESULT_CODE, ATTENDANCE_FAILURE_REASON — attendance capture and outcome.

Common Use Cases and Queries

The view is typically queried to report registrations by event, reconcile payment status, and track attendance. A representative query for payment status reporting resolves the user's search term directly:

• Registration listing by event with decoded payment status:
  SELECT event_registration_id, confirmation_code, customer_name, payment_status_code, meaning FROM apps.ams_event_registrations_v WHERE event_offer_id = :p_offer_id;
• Pivot of attendees versus non-attendees:
  SELECT event_offer_id, attended_flag, COUNT(*) FROM apps.ams_event_registrations_v GROUP BY event_offer_id, attended_flag;
• Outstanding payments:
  SELECT event_registration_id, customer_name, payment_status_code, meaning FROM apps.ams_event_registrations_v WHERE payment_status_code IN ('PENDING','UNPAID');
• Cancellations with reasons:
  SELECT event_registration_id, customer_name, cancellation_code, cancellation_reason_code FROM apps.ams_event_registrations_v WHERE cancellation_code IS NOT NULL;

Because the lookup join is an outer join, registrations without a matching AMS_EVENT_PAYMENT_STATUS value still appear, with a NULL MEANING; this behaviour should be accounted for in report logic.