Search Results poa_oltp_generic_pkg




Overview
Explore in AI Chat

Overview

APPS.POA_OLTP_GENERIC_PKG is a PL/SQL package body residing in the APPS schema of the Oracle E-Business Suite. The "POA" prefix associates the package with the Purchasing Analytics / Procurement Online Transaction Processing (OLTP) product family, specifically the ETRM (Enterprise Transaction Reporting Model) or Procurement Analytics data extraction layer that supplies the Oracle EBS purchasing operational datastore. In EBS 12.1.1 and 12.2.2, packages of this class exist to support the acquisition, staging, and reporting of transactional purchasing data — purchase orders, releases, and line locations — for downstream analytics and archival reporting. The package is classified as OTHER, indicating that it is not a published Oracle public API but rather an internal component consumed by the analytics extraction framework. Its status is VALID in the documented environment. The package body is not referenced by any other database object according to the dependency metadata, but the metadata notes it is referenced by eleven other packages, indicating it acts as a shared utility layer for the analytics family rather than an end-user entry point.

Key Procedures and Functions

The documented package exposes three procedures or functions, all of which serve to retrieve approval dates from archived purchasing records:

  • GET_APPROVED_DATE_POH — Returns the approved date associated with a purchase order header. It is the header-level accessor used when the analytics layer needs the point in time at which a PO header was approved, derived from the archived header table.
  • GET_APPROVED_DATE_POR — Returns the approved date associated with a purchase order release. This accessor supports release-level approval reporting, using the archived releases table as its source.
  • GET_APPROVED_DATE_PLL — Returns the approved date associated with a purchase order line location. This accessor supports line-location-level approval reporting against the archived line locations table.

Each routine follows the same naming convention — GET_APPROVED_DATE_ followed by the entity abbreviation (POH, POR, PLL) — reflecting a consistent design where approval dates are retrieved for each level of the purchasing document hierarchy: header, release, and line location. Parameter lists are not documented in the ETRM metadata and are therefore not enumerated here.

Tables Accessed

The package reads from three archive tables, referenced through APPS synonyms, all belonging to the purchasing archive family:

  • PO_HEADERS_ARCHIVE_ALL — The archived purchase order headers table, used by GET_APPROVED_DATE_POH to source header-level approval dates.
  • PO_RELEASES_ARCHIVE_ALL — The archived purchase order releases table, used by GET_APPROVED_DATE_POR to source release-level approval dates.
  • PO_LINE_LOCATIONS_ARCHIVE_ALL — The archived purchase order line locations table, used by GET_APPROVED_DATE_PLL to source line-location-level approval dates.

The use of archive (rather than the live PO_HEADERS_ALL, PO_RELEASES_ALL, and PO_LINE_LOCATIONS_ALL) tables confirms that this package is designed for historical or closed-document reporting, where transactional records have been migrated into the archival schema by the purchasing archival process.

Usage Notes

POA_OLTP_GENERIC_PKG is an internal utility package invoked by higher-level analytics and reporting components rather than directly by end users. It is typically called from concurrent programs, ETRM extraction routines, or dependent analytics packages that require approval-date attributes for purchasing documents. Because the package is not referenced by other database objects yet is cited as referenced by eleven packages, it functions as a shared dependency in the analytics call graph. Developers extending procurement analytics should treat it as a non-public API whose behavior may change between releases; direct invocation from custom code should be avoided in favor of the supported analytics interfaces. Any modification or recompilation should account for its dependencies on STANDARD and the APPS synonyms for the three archive tables.