Search Results gml_po_recv2_pkg




Overview
Explore in AI Chat

Overview

GML_PO_RECV2_PKG is an Oracle EBS PL/SQL package owned by the APPS schema that supports purchasing and receiving integration for process manufacturing (OPM/GML) environments. Its principal business role is to maintain the mapping between Oracle Purchasing documents (headers, lines, line locations, and releases) and their counterparts in the process manufacturing receiving and order management data model, and to synchronize status and quantity information between the two models. The package is declared AUTHID CURRENT_USER, so execution privileges are evaluated against the calling user's schema rather than the package owner, a design choice typical of integration utilities that must observe the caller's security context on the underlying tables.

The header comment indicates the source file (GMLRCMVS.pls, version 115.4) was last shipped in November 1999, making this a long-standing utility that has been carried forward into EBS 12.1.1 and 12.2.2 without structural change. The ETRM classification of the package is OTHER, meaning it is not a formally published public API such as the Oracle Purchasing Receiving APIs, but is nevertheless a documented, callable program unit referenced by at least one other package.

Key Procedures and Functions

  • GET_ORACLE_ID — Resolves the Oracle Purchasing identifiers (header, line, line location, and release) corresponding to a given OPM-side purchase order and line identifier pair. It returns the mapped identifiers through OUT parameters, making it the translation routine used before any update processing.
  • UPDATE_HEADER_STATUS — Updates status information at the purchase order header level for a given header, operating unit, and audit context (last updated by and last update date).
  • UPDATE_LINE_STATUS — Updates status information at the purchase order line level. This is the procedure targeted by searches for "update_line_status." It accepts the header identifier, line identifier, organization, and the standard audit columns, and propagates the current line status into the mapped structures.
  • UPDATE_RELEASE_STATUS — Performs the equivalent status synchronization for blanket agreement releases, using the header and release identifiers together with the audit context.
  • UPDATE_LINE_LOCATIONS — Maintains line location (shipment) level data, including the purchase order status, received quantity, returned quantity, and creation and timestamp audit values, keyed by header, line, line location, release, and organization.

Tables Accessed

The package reads and writes CPG_ORAGEMS_MAPPING, the cross-reference table that stores the correspondence between OPM document identifiers and Oracle Purchasing identifiers; GET_ORACLE_ID and UPDATE_LINE_LOCATIONS both depend on it. GL_PLCY_MST supplies the organization identifier used in the update signatures. The transactional purchasing tables PO_ORDR_HDR and PO_ORDR_DTL provide the OPM-side order header and line records, while PO_RECV_DTL and PO_RTRN_DTL supply receipt and return quantities consumed by UPDATE_LINE_LOCATIONS. Through APPS synonyms, the package also reaches the standard EBS purchasing entities PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_RELEASES_ALL, and FND_USER is referenced for user validation or audit stamping.

Usage Notes

GML_PO_RECV2_PKG is ordinarily invoked indirectly rather than from end-user forms. It is called by the one dependent package documented in ETRM, and would also be reached by receiving-related concurrent programs, workflow background processes, or custom integration code that must keep OPM receiving status and quantities aligned with Oracle Purchasing. Because update procedures require explicit last_updated_by and last_update_date values, callers are expected to supply the correct audit context rather than relying on WHO columns. The procedures do not commit internally in typical EBS API fashion, so transaction control remains with the calling program. Customizations should treat the package as an integration utility and avoid direct DML on the mapping table, using GET_ORACLE_ID first to validate identifier resolution and invoking the appropriate status or location update only within a controlled transaction.