Search Results xtr_xtrausrm_xmlp_pkg

Overview

The APPS.XTR_XTRAUSRM_XMLP_PKG package is a generated PL/SQL package that belongs to the Oracle E-Business Suite (EBS) Treasury (XTR) application module. Its name follows the standard EBS convention for packages produced automatically when a report is registered using Oracle Reports and the Oracle XML Publisher (BI Publisher) integration: the _XMLP_PKG suffix indicates that the package serves as the PL/SQL wrapper that drives a specific concurrent report executable. In this case, the report is associated with the XTRAUSRM report (the "User Report" or user-defined treasury report) in the Treasury management product.

The package is classified under the APPS schema and holds a status of VALID in both the 12.1.1 and 12.2.2 releases. Its API classification is recorded as OTHER, meaning it is not a public open interface but an internal, report-support routine. The business purpose is to provide the formula, formatting, and lifecycle hooks (before-report and after-report triggers) that the report engine calls during execution, allowing parameter-driven logic and post-processing behaviour to be applied to the user report output.

Key Procedures and Functions

The documented package exposes five program units, all of which are typical of the standard XML Publisher report wrapper template.

• BEFOREREPORT — The before-report trigger. It executes prior to the report query being run and is used to initialise package-level state, default parameter values, and any setup logic required before the report data is fetched.
• AFTERPFORM — The after-parameter-form trigger. It fires once the user has submitted the report parameter form, and is typically used to validate or transform parameter values captured through the concurrent program parameter window.
• AFTERREPORT — The after-report trigger. It runs following completion of the report query and is used to perform cleanup or finalisation logic after the report data set has been processed.
• CF_SET_PARAFORMULA — A helper routine for the "set parameter formula" mechanism. It is invoked to programmatically assign or compute the values of report parameters based on other parameters or runtime conditions.
• CP_PARA_P — The concurrent program parameter procedure. It handles the logic associated with passing concurrent program parameters into the report, commonly responsible for reading the parameter list maintained by the concurrent manager and mapping those values into the report's parameter structure.

No parameter lists are documented, and the procedures should be treated as internal callbacks invoked by the report runtime rather than as an API for direct external use.

Tables Accessed

The documented dependency metadata shows that the package references only DUAL (via its APPS synonym). This is consistent with report-control packages, which generally do not query or modify application data directly — the report query itself supplies the data. The use of DUAL typically corresponds to trivial in-line evaluations, such as generating a constant value, evaluating a system date, or assigning a literal to a package variable during initialisation. There are no documented inserts, updates, or deletes against business tables, so the package is effectively read-only with respect to application data.

Usage Notes

XTR_XTRAUSRM_XMLP_PKG is invoked indirectly and is not intended for manual calls from custom code. In normal operation, the package is executed automatically when the corresponding Treasury user report concurrent program is launched. The concurrent manager calls the report executable, which in turn triggers the before-report, parameter, and after-report callbacks defined in this package. The ETRM metadata records that the package is referenced by zero other packages, confirming that it is a leaf-level, report-specific wrapper rather than a shared library.

Because the object is owned by APPS and is regenerated whenever the associated report definition or template is recompiled, any customer-specific modification should be avoided; the supported approach is to place customisations in a separate package and invoke them through a custom report or a substituted executable. The package remains valid and stable across the 12.1.1 and 12.2.2 code lines, and no dependencies on customer data model objects are documented.