Search Results p_orderby

Overview

APPS.PO_POXVDRVL_XMLP_PKG is a package body that supports the Oracle Purchasing vendor detail listing report, identified by the executable/report short name POXVDRVL. In Oracle EBS 12.1.1 and 12.2.2, XML Publisher (XMLP) reports follow the standard Oracle Reports to XML Publisher conversion pattern, in which a PL/SQL package supplies the report-level "placeholder" fields, before-report and after-report triggers, and lexical query components such as the ORDER BY clause. This package fulfills that supporting role for the vendor listing: it owns no business tables of its own, performs no DML, and instead derives display and sort values that the report layout and underlying query consume at runtime.

The package name carries the PO_POXVDRVL_XMLP_PKG convention, indicating it is the XMLP-specific companion package for the POXVDRVL report. Its header comment shows a last revision of 120.1 dated 2007, with the SRW user-exit calls (FND SRWINIT and FND SRWEXIT) commented out and replaced by null statements — a characteristic artifact of the XML Publisher migration, where the SRW initialization is no longer required.

Key Procedures and Functions

• ORDERBY_CLAUSEFORMULA — Returns a VARCHAR2 representing the database column expression to be used in the report's ORDER BY clause. It maps the user's selection in the P_orderby parameter to the corresponding schema-qualified column: 'VENDOR' returns pov.vendor_name, 'VENDOR SITE' returns pvs.vendor_site_code, and 'ZIP CODE' returns pvs.zip. If the parameter matches none of these values, or is null, the function returns pov.vendor_name as the default sort. This is the function most directly associated with the search term "p_orderby" and is the mechanism by which the report's lexical sort is made dynamic.
• BEFOREREPORT — Executes after report parameter entry and before the main query runs. Its documented purpose is to translate coded lookup values into their user-facing display strings. It declares three local variables of the po_lookup_codes.displayed_field type and uses them to populate the report placeholder parameters P_active_inactive_disp, P_vendor_type_displayed, and P_orderby_displayed, each selected from po_lookup_codes filtered by lookup_type ('ACTIVE_INACTIVE', 'VENDOR TYPE', and 'SRS ORDER BY' respectively). When an incoming parameter is null, the corresponding displayed placeholder is set to an empty string. The function returns TRUE.
• AFTERREPORT — Runs after the report output is produced. Its only documented action is a commented-out SRW.USER_EXIT('FND SRWEXIT') replaced by null; it returns TRUE.

Tables Accessed

The package performs read-only access to a single documented table, PO_LOOKUP_CODES, through the APPS synonym. The BEFOREREPORT function issues three SELECT statements against po_lookup_codes, each retrieving displayed_field for a given lookup_code within a specified lookup_type. This table is the Purchasing lookup-code repository used to translate internal codes into descriptive labels. The columns referenced are displayed_field, lookup_code, and lookup_type. No inserts, updates, or deletes are performed. The vendor and vendor site tables implied by the ORDERBY_CLAUSEFORMULA return values (aliased pov and pvs) are referenced only as query text returned to the report engine, not accessed directly by this package.

Usage Notes

PO_POXVDRVL_XMLP_PKG is not intended to be called directly by application users or custom code. It is invoked by the Oracle Reports/XML Publisher runtime when the POXVDRVL vendor detail report is executed, typically from the Purchasing responsibility menu or as a concurrent program submission. The report engine calls BEFOREREPORT prior to query execution to set placeholder values, calls ORDERBY_CLAUSEFORMULA to obtain the dynamic sort expression driven by the P_orderby parameter, and calls AFTERREPORT on completion. The ETRM metadata records zero packages referencing this object, confirming it sits at the top of the call chain for its own report and is not a shared library. Customizations should not modify this package directly; standard practice is to copy the report and its supporting package, then register the copy under a new name, because the package is regenerated by Oracle patches.