Search Results trainer_name




Overview

OTFV_EVENTS_WITH_TRAINER is an APPS-owned database view in the Oracle E-Business Suite OTA (Learning Management) module. It is documented as a business view template from which the flexfield view is generated, meaning it serves as the canonical definition that the OTA flexfield/view generation process consumes when constructing user-facing inquiry and reporting views for events and their assigned trainers. The view consolidates event header data with trainer resource booking data, producing a denormalized result set that joins an event to the trainer booked against it, together with the booking's role, dates, and status. Its primary role is to support reporting and integration scenarios in which a flat, human-readable representation of event-to-trainer assignments is required, avoiding the need for callers to re-implement the multi-table join logic themselves. On EBS 12.1.1 and 12.2.2 the object resides in the APPS schema and carries a documented status of VALID.

Underlying Base Objects

The view is defined over three primary base objects, joined as follows: OTA_EVENTS (aliased EVT), OTA_SUPPLIABLE_RESOURCES (aliased TSR), and OTA_RESOURCE_BOOKINGS (aliased TRB). The join conditions are EVT.EVENT_ID = TRB.EVENT_ID and TSR.SUPPLIED_RESOURCE_ID = TRB.SUPPLIED_RESOURCE_ID, with a mandatory filter TSR.RESOURCE_TYPE = 'T' restricting the result set to trainer-type suppliable resources. A business group restriction is applied via EVT.BUSINESS_GROUP_ID = NVL(OTA_GENERAL.GET_BUSINESS_GROUP_ID, EVT.BUSINESS_GROUP_ID), and the view is declared WITH READ ONLY. The documented referenced base objects additionally include the synonyms OTA_EVENTS_TL, OTA_SUPPLIABLE_RESOURCES_TL, and OTA_RESOURCE_BOOKINGS, and the packages HR_BIS and OTA_GENERAL. The _TL synonyms supply translated name attributes used in the projection, HR_BIS supplies the BIS_DECODE_LOOKUP function used for status decoding, and OTA_GENERAL supplies GET_BUSINESS_GROUP_ID for the business group predicate.

Key Columns

  • EVENT_TITLE — the event title, sourced from the events table.
  • TRAINER_NAME — the name of the trainer resource returned from OTA_SUPPLIABLE_RESOURCES.
  • TRAINER_ROLE — the role the trainer is to play on the booking (TRB.ROLE_TO_PLAY).
  • DATE_OF_BOOKING — the date the resource booking was placed (TRB.DATE_BOOKING_PLACED).
  • BOOKING_STATUS — the decoded booking status, produced by HR_BIS.BIS_DECODE_LOOKUP('RESOURCE_BOOKING_STATUS', TRB.STATUS). This is the column that satisfies the common resource_booking_status search, returning the lookup meaning rather than the raw code.
  • REQUIRED_FROM / REQUIRED_TO — the required start and end dates for the trainer booking.
  • RESOURCE_BOOKING_ID — the unique identifier of the resource booking row.
  • SUPPLIED_RESOURCE_ID — the identifier of the supplied resource (trainer).
  • EVENT_ID and OFFERING_ID — the event and offering identifiers, enabling linkage back to the event and offering entities.

Common Use Cases and Queries

The most frequent use case is reporting trainer bookings by status, which aligns directly with the resource_booking_status search term. Because BOOKING_STATUS is already decoded through HR_BIS.BIS_DECODE_LOOKUP, consumers can filter or group on a readable status value without additional joins to lookup tables. A representative query is:

SELECT event_title, trainer_name, trainer_role, booking_status, required_from, required_to FROM apps.otfv_events_with_trainer WHERE booking_status = 'Confirmed' ORDER BY event_title;

A second scenario profiles trainer workload, aggregating bookings per trainer within a required date window:

SELECT trainer_name, booking_status, COUNT(*) FROM apps.otfv_events_with_trainer WHERE required_from >= :p_from AND required_to <= :p_to GROUP BY trainer_name, booking_status;

A third scenario joins the view back to the base event tables using EVENT_ID or OFFERING_ID when additional event attributes are required. Because the view is READ ONLY and filtered by business group through OTA_GENERAL.GET_BUSINESS_GROUP_ID, queries execute within the caller's business group context by default, which supports multi-org reporting and integration extracts. All access should use the APPS schema or a synonym granted to the reporting account.