Search Results ar_arxasr_xmlp_pkg

Overview

AR_ARXASR_XMLP_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its naming convention and structure identify it as the database-side implementation of an Oracle Reports (XML Publisher–enabled) concurrent program within the Oracle Receivables (AR) module. The "XMLP" suffix indicates that the report output is generated through the BI Publisher/XDO engine, while the package itself provides the standard report trigger logic, data-model queries, and formatting helpers that Oracle Reports expects when a report is registered as a concurrent program.

The business function of this package is to support the "ARXASR" report — an Accounts Receivable summary or statement-style report — by supplying the programmatic hooks (report-level triggers and formula columns) that Oracle Reports invokes at defined points during execution: prior to the report body, after the report, and after the parameter form. In ETRM 12.2.2 the object is classified as "OTHER" (not a public or private API), confirming it is an internal report-support package rather than a callable business API. No other database object references it, so its use is confined to the Oracle Reports runtime.

Key Procedures and Functions

The ETRM metadata documents ten procedures and functions, none of which expose parameters through a public API signature. Their roles are as follows:

• BEFOREREPORT — The standard Oracle Reports "Before Report" trigger. Used to initialize package state, resolve session and organization context, and prepare data-model queries before report rows are fetched.
• AFTERREPORT — The complementary "After Report" trigger, executing after all report rows are printed, typically for cleanup or summary finalization.
• REPORT_NAMEFORMULA — A formula column that supplies the report title/name, often resolved dynamically for the XML Publisher layout header.
• AFTERPFORM — The "After Parameter Form" trigger, which validates and possibly augments user-entered report parameters once the parameter form is submitted.
• C_STATUS_SUMMARY_LABELFORMULA — A formula column that computes the display label for the status summary section of the report output.
• C_DATA_NOT_FOUNDFORMULA — A formula column returning a message or flag when no data matches the report criteria, controlling the "no data found" text in the output.
• RP_COMPANY_NAME_P — A report-level placeholder/parameter populated with the company (legal entity) name for the report header.
• RP_REPORT_NAME_P — A placeholder holding the formatted report name shown in the output.
• RP_DATA_FOUND_P — A placeholder indicating whether qualifying data rows exist, referenced by layout logic.
• RPD_REPORT_SUMMARY_P — A placeholder populated with the summary text displayed at the end of the report.

Together these routines form the standard Oracle Reports package interface: three report triggers, two formula columns, and four report placeholders, plus the report-name formula.

Tables Accessed

The documented dependency list shows the package references FND_CONCURRENT_REQUESTS (through APPS synonyms), along with FND_CONCURRENT_PROGRAMS_VL and FND_GLOBAL. FND_CONCURRENT_REQUESTS is read to determine the current concurrent request context — request ID, program details, and argument values — so the report can associate its output with the correct submission and, where applicable, apply security or logging. FND_GLOBAL supplies session identifiers such as user ID and responsibility. The report's principal business data comes from Receivables and AR_SETUP objects referenced in the package, but the only table explicitly documented in the ETRM excerpt is FND_CONCURRENT_REQUESTS. The package does not write to these tables; access is read-only context retrieval.

Usage Notes

AR_ARXASR_XMLP_PKG is not intended for direct invocation by custom code. It is executed indirectly by the Oracle Reports runtime when the associated ARXASR concurrent program is submitted from the Receivables navigation menu or the Submit Requests form. The report triggers (BEFOREREPORT, AFTERPFORM, AFTERREPORT) fire automatically at defined execution phases, while the formula columns and placeholders populate fields in the XML Publisher layout.

Because the package is owned by APPS and carries no public API classification, developers should treat it as an internal implementation object. Customizations should not call these procedures directly; instead, any extension should be implemented through report parameters, a custom XML layout, or a separate custom package. The object is VALID in both 12.1.1 and 12.2.2, though 12.2.x introduces the Online Patching (adop) file system, meaning the compiled body resides in the run edition of the APPL_TOP database. Standard Oracle support and patching procedures apply.