Search Results ota_learner_enroll_ss




Overview

OTA_LEARNER_ENROLL_SS is a server-side PL/SQL package in the Oracle E-Business Suite (EBS) Applications (APPS) schema, classified as an "OTHER" API within Oracle Training Administration (OTA), the learning management component of Oracle HRMS. The package encapsulates the business logic required to enroll learners in OTA offerings and events, to validate those enrollments against organizational, financial, and security rules, and to cancel or delegate bookings when circumstances change. Its name reflects its role as the server-side (SS) enrollment engine used by the self-service and administrative learning flows. The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user and therefore relies on APPS synonyms and standard EBS security for data access. In both Release 12.1.1 and 12.2.2, it remains an internal implementation package rather than a documented public API, and it exposes 22 documented procedures and functions covering the enrollment lifecycle. It is referenced by five other packages, confirming its position as a shared dependency in the OTA transaction stack.

Key Procedures and Functions

The documented entry points fall into two broad groups:

Tables Accessed

The package reads and writes OTA transactional tables — OTA_EVENTS, OTA_OFFERINGS, OTA_ACTIVITY_VERSIONS, OTA_DELEGATE_BOOKINGS, and OTA_BOOKING_STATUS_TYPES with its _TL translation table — and validates against HR and TCA master data: PER_ALL_ASSIGNMENTS_F and FND_USER for the learner and supervisor, HR_ALL_ORGANIZATION_UNITS and HR_LOCATIONS_ALL for cost center and location, and HZ_PARTIES, HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, HZ_ORG_CONTACTS, and HZ_RELATIONSHIPS for external learners and customer organizations.

Usage Notes

OTA_LEARNER_ENROLL_SS is normally invoked indirectly through the OTA self-service enrollment forms and the associated booking/cancellation flows, as well as from related packages that call it for validation and status resolution. Because it is not a published public API, customizations should call the documented OTA public APIs where available and treat this package as internal, since signatures may change between patch levels. Custom code that does invoke it should ensure the session's responsibility and security group context is set, because checks such as CHK_FOR_SECURE_EVT and CHK_FOR_RESTRICTED_EVT depend on FND_USER responsibility data. The AUTHID CURRENT_USER declaration means grants on the underlying tables and synonyms must be in place for any non-APPS caller.