Search Results p_status_lo

Overview

APPS.INV_INVIRDST_XMLP_PKG is the packaged PL/SQL body that supports the Oracle Inventory item status report executed through the Oracle E-Business Suite XML Publisher (BI Publisher) reporting infrastructure. In Oracle EBS 12.1.1 and 12.2.2, reports of this class follow a standard pattern: a concurrent program is registered against an XML Publisher template, and a companion PL/SQL package supplies the report's data model logic, including parameter handling, before-report initialization, and after-report cleanup. The name prefix "INV" identifies the Inventory product, "INVIRDST" is the internal short name of the item status report, and the "XMLP_PKG" suffix confirms that the package is bound to the XML Publisher engine rather than the legacy Oracle Reports runtime.

The body carries a source header indicating a last modification date of 2008 and a "noship" designation, meaning the file is internal and not shipped as a standalone artifact. Its total footprint is small: three functions. The package exists purely to prepare the SQL WHERE fragment and session context that the XML Publisher data template requires at run time.

Key Procedures and Functions

• C_WHEREFORMULA — The central function of the package. It returns a VARCHAR2 that is appended to the report's SQL query to restrict rows by inventory item status code. Its logic is driven by the two concurrent program parameters P_STATUS_LO and P_STATUS_HI. When both are populated it emits a BETWEEN predicate on inventory_item_status_code; when only the low value is supplied it emits a greater-than-or-equal-to predicate; when only the high value is supplied it emits a less-than-or-equal-to predicate; when neither is supplied it returns a single space, effectively applying no status filter. This is the object most relevant to the search term "c_whereformula", as it is the only place in the package where the report's dynamic WHERE clause is constructed.
• BEFOREREPORT — The report initialization function. It assigns the current concurrent request identifier from FND_GLOBAL.CONC_REQUEST_ID into P_CONC_REQUEST_ID so that the report can be traced and so that any dependent logic can reference the request. The legacy Oracle Reports user exit call for FND SRWINIT is present only as a comment and is deliberately nulled, reflecting the migration of this report to the XML Publisher runtime.
• AFTERREPORT — The report finalization function. It mirrors BEFOREREPORT by retaining the commented-out FND SRWEXIT user exit and returning TRUE unconditionally, confirming that the XML Publisher engine handles session teardown for this report.

Tables Accessed

The ETRM metadata for this package lists no direct table references through APPS synonyms. This is consistent with the source: C_WHEREFORMULA performs no SQL of its own. It only formats a predicate string that the data template will embed into a query against the Inventory item status tables. The actual table access for this report therefore occurs in the XML Publisher data definition, not in the PL/SQL body. The only external dependency visible in the code is FND_GLOBAL.CONC_REQUEST_ID, a server-side function used to obtain the running concurrent request number.

Usage Notes

The package is not exposed as a public API and is not referenced by any other package, so it is not intended for direct invocation from forms, custom concurrent programs, or third-party code. It is bound to the item status report, which is submitted from the Inventory responsibility. When the report runs, the XML Publisher engine calls BEFOREREPORT to capture the request ID, evaluates C_WHEREFORMULA to build the status restriction clause from the user's P_STATUS_LO and P_STATUS_HI entries, executes the data template query, and then calls AFTERREPORT on completion.

Because the WHERE clause is assembled by string concatenation, any customization of this package should preserve the exact spacing and quoting conventions shown in the source, since the returned fragment is inserted directly into the template SQL. Customers extending or cloning the item status report should treat the function as an internal implementation detail of the report definition rather than a reusable utility.