Search Results po_poxsuruc_xmlp_pkg

Overview

PO_POXSURUC_XMLP_PKG is an Oracle Application Object Library style PL/SQL package owned by the APPS schema, catalogued as VALID and classified under ETRM as an "OTHER" API. The naming convention is diagnostic in itself: the "XMLP_PKG" suffix indicates that the package was auto-generated by Oracle XML Publisher (BI Publisher) to wrap a report definition, and the embedded identifier "POX" ties it to the Oracle Purchasing module. Specifically, the "POX" prefix is used throughout the Purchasing schema for the family of standard reports and concurrent programs that render purchasing business documents as XML output. PO_POXSURUC_XMLP_PKG therefore belongs to the supplier and purchasing-document reporting layer rather than to the transactional application logic itself.

Its function is to provide the XML Publisher runtime with the two entry points it expects when executing a data model against a PL/SQL package: an initialization hook executed before the data template is processed, and a completion hook executed afterward. In Oracle EBS 12.1.1 and 12.2.2 this pattern is pervasive — nearly every seeded XML Publisher report is accompanied by a package of this shape — and the packages are delivered as part of the standard patch cycle rather than as customer extensions.

Key Procedures and Functions

The ETRM metadata documents exactly two callable units on this package:

• BEFOREREPORT — The pre-processing hook. XML Publisher invokes this procedure before the report data model is evaluated. Its purpose within the generated-report pattern is to perform setup work required by the report: initializing package-level and global variables, resolving concurrent program parameters passed by the requesting user, establishing session context, and preparing any temporary structures or data caches that the report query will consume. In generated XML Publisher packages this procedure is also where the report's lexical and bind parameters are bound so that the subsequent query executes with the correct runtime values.
• AFTERREPORT — The post-processing hook. It is invoked once the report data has been generated and is typically used for cleanup and teardown: releasing or truncating temporary tables and global temporary table content, clearing package state, and freeing any resources acquired by BEFOREREPORT. In the standard generated pattern this procedure contains little or no business logic and exists primarily to guarantee that repeated executions of the concurrent request do not leak state between runs.

No parameter signatures are published in the ETRM extract, and none should be assumed beyond the conventional no-argument form used by XML Publisher's generated packages.

Tables Accessed

The ETRM extract records no direct table references for this package via APPS synonyms. This is characteristic of generated XML Publisher wrapper packages: the heavy data extraction is performed by the report's SQL query or data template, while the package itself touches little or nothing directly. Any SQL embedded in the package body would ordinarily be limited to session and parameter context rather than to purchasing business tables. Consumers should not infer that the report reads no purchasing data — only that the package object is not the documented owner of those accesses.

Usage Notes

The package is not intended for direct invocation by developers. It is called exclusively by the XML Publisher engine at runtime, on behalf of the concurrent program whose short name shares the "POX" root. The ETRM metadata confirms the isolation of the object: it references only SYS.STANDARD and is referenced by no other packages, and no external package depends upon it. Consequently, it appears in dependency reports only as a leaf node.

Typical usage scenarios are limited to diagnosing a failing purchasing report through the concurrent manager log or the XML Publisher Administrator responsibility, and to impact analysis before applying a patch. Because the package is regenerated with each XML Publisher report definition change, customizations should be applied to the underlying data template or report definition rather than to the package body, which will be overwritten. The presence of both BEFOREREPORT and AFTERREPORT confirms the package is complete and executable in its current VALID state.