Search Results cp_para_p

Overview

APPS.XTR_XTRAUSRM_XMLP_PKG is a report logic package body within the Oracle E-Business Suite ETRM (Enterprise Tracking and Reporting Management) module, executed in the XML Publisher / Oracle Reports integration layer. Its source header identifies it as XTRAUSRMB.pls, last updated with version 120.1 (2007/12/28) by npannamp and marked noship, indicating a non-shipped, module-owned artifact rather than a globally distributed seed file. The package serves the "Xtra User Audit Report" (XTRAUSRM), a report that surfaces user change history, specifically the audit records captured against user definitions and related setup events. Its central responsibility is orchestrating multilingual report output: it resolves translated column and heading descriptions dynamically, initializes the concurrent request context, executes the report's Before Report trigger logic, and supplies a substitutions parameter value for display in the report layout. The package is classified in ETRM as OTHER, reflecting its role as supporting report infrastructure rather than a callable business API, and is owned by APPS.

Key Procedures and Functions

The documented program units comprise five entries, consisting of three report trigger functions and a parameter handling pair.

• CF_SET_PARAFORMULA — a formula-column function that queries DUAL to derive and return a truncated value (SUBSTR of USER, length 10) into the package global CP_PARA. This supplies the user identifier shown in the report's parameter block or header.
• BEFOREREPORT — executes prior to report data retrieval. It assigns the concurrent request identifier through FND_GLOBAL.CONC_REQUEST_ID and populates the numerous Z1/Z2 report label variables (for example Z1AUDIT_REQUESTS_FROM, Z1PARAMETERS, Z2EVENT_TYPE, Z2NEW_VALUE, Z2UPDATED_BY) by iterating the GET_LANGUAGE_DESC cursor over XTR_SYS_LANGUAGES_VL. This binds each item name to its translated LANG_NAME for the active module (defaulting to 'XTRAUSRM' when P_REPORT_NOS is null), enabling localized column headers and row prompts.
• AFTERPFORM — the After Parameter Form trigger, used to adjust or validate report parameters before the query executes; consistent with packages in this family, it supports parameter-dependent setup for the audit report.
• AFTERREPORT — the After Report trigger, traditionally used to close or clean up resources opened during report execution; the SRWINIT/SRWEXIT user exits appear commented in the source, so this function performs residual post-execution handling.
• CP_PARA_P — a parameter accessor function returning the value of the CP_PARA package global, exposing the value computed in CF_SET_PARAFORMULA for use in the report layout or format triggers.

Tables Accessed

The documented data access is minimal: the package selects from DUAL within CF_SET_PARAFORMULA to derive the current user identifier without touching application data. Beyond the documented metadata, BEFOREREPORT reads XTR_SYS_LANGUAGES_VL, the ETRM language-description view, filtered by MODULE_NAME. This view provides the translated item names that map to report labels, making it the substantive data source behind the package's localization behavior. No insert, update, or delete operations are documented; the package is strictly a read-only report driver.

Usage Notes

The package is not invoked directly by application forms or by other packages; the metadata records zero referencing packages. It is instead bound to the XTRAUSRM report definition and invoked through the Oracle Reports / XML Publisher runtime as the concurrent program executes, with the report engine firing BEFOREREPORT, AFTERPFORM, AFTERREPORT, and the formula-column CP_PARA_P in sequence. Because CP_PARA is populated from USER to a ten-character substring, the report reflects the database session user at submission time—typically the concurrent manager or the submitting user's database context—so administrators relying on this value should confirm the expected session identity in their environment. Deployment assumes XTR_SYS_LANGUAGES_VL contains item rows keyed to the report's module name; if P_REPORT_NOS is passed as null, the package defaults to 'XTRAUSRM', and any missing item names would leave the corresponding Z1/Z2 labels unset. The noship header implies the object may not exist in all environments and is maintained by the owning module team, so customizations should avoid direct dependencies and instead target the report template or ETRM configuration.