Search Results ota_om_upd_api




Overview
Explore in AI Chat

Overview

OTA_OM_UPD_API is a public PL/SQL package owned by APPS in Oracle E-Business Suite 12.1.1 and 12.2.2. It serves as the integration bridge between Oracle Training Administration (OTA) and Oracle Order Management (OM). Its business purpose is to synchronize training-related commercial activity with the order management schema: creating sales orders, creating return material authorizations (RMAs), cancelling order lines, and reconciling order messages back into the OTA booking model. The package header declares AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, so callers must themselves hold the necessary OM and Trading Community Architecture (TCA) privileges.

The header comment block explicitly states that the procedures are "only used for OTA and OM integration," confirming the package is an internal integration surface rather than a general-purpose order management API. The version string (ottomupd.pkh 115.4) indicates the package has been stable since the early 11i code line and was carried forward largely unchanged into Release 12.

Key Procedures and Functions

ETRM documents five callable procedures:

  • CANCEL_ORDER — Cancels an order line. It accepts a line identifier and an operating unit (org_id) and returns no value. It is the counterpart routine used when a training booking is cancelled and the corresponding order line must be terminated.
  • CREATE_RMA — Creates a Return Material Authorization. Like CANCEL_ORDER, it is driven by the order line identifier and operating unit. This is the procedure most commonly referenced when users search for "create_rma"; it is the documented entry point for generating an RMA from an OTA booking context (for example, a student cancellation or refund that must flow back through OM).
  • CREATE_ORDER — Creates a sales order from the OTA side. The header excerpt is truncated before its comment block completes, but its naming and its placement alongside the other integration routines confirm its role as the forward-direction counterpart to CREATE_RMA.
  • RETRIEVE_OE_MESSAGES — Retrieves Order Management processing messages (error and status messages) so that OTA can surface OM results, such as order import or booking failures, to the caller.
  • CREATE_ENROLL_FROM_OM — Creates an enrollment from an OM-side event, completing the bidirectional flow by allowing order activity to drive training enrollment records.

No parameter lists beyond p_Line_id and p_org_id (for CANCEL_ORDER and CREATE_RMA) are documented in the excerpt, and none should be assumed.

Tables Accessed

All tables are referenced through APPS synonyms. The package touches three functional groups. First, TCA/party tables support customer and contact resolution: HZ_PARTIES, HZ_PARTY_SITES, HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, HZ_CUST_ACCT_SITES, HZ_CUST_SITE_USES, HZ_CONTACT_POINTS, HZ_LOCATIONS, and HZ_RELATIONSHIPS. These supply the ship-to, bill-to, and contact data required to build a valid order or RMA. Second, the OM transactional tables OE_ORDER_HEADERS and OE_ORDER_LINES (and their _ALL counterparts) hold the order and return documents that are created or modified. Third, OTA control tables OTA_BOOKING_STATUS_TYPES and OTA_DELEGATE_BOOKINGS link the order activity back to booking status and delegate-booking records so that training bookings remain consistent with OM outcomes.

Usage Notes

Because the package is classified as a public API and is referenced by three other packages, it is normally invoked indirectly rather than from end-user forms. Typical callers are OTA booking and cancellation flows that delegate order creation, RMA generation, and line cancellation to this package, then call RETRIEVE_OE_MESSAGES to obtain OM feedback. Custom extensions should call the documented procedures by name and supply the line identifier and operating unit rather than writing directly to OE_ORDER_HEADERS_ALL or OE_ORDER_LINES_ALL, which bypasses the integration logic. In Release 12, note that the AUTHID CURRENT_USER declaration means responsibility-level or custom-code grants on the underlying HZ and OE objects must be verified before invoking the API.