Search Results p_sort_by

Overview

APPS.WIP_WIPDJORQ_XMLP_PKG is the server-side PL/SQL package body that backs the Oracle Work in Process concurrent program "Discrete Job Detail" (short name WIPDJORQ). Under Oracle EBS 12.1.1 and 12.2.2 the package follows the standard XML Publisher/BI Publisher report architecture used in the Oracle Applications technology stack: a report-specific package encapsulates the SQL parameter logic, lexical fragment builders, and group-level formula computations that the report definition references. This particular package is classified as OTHER in the ETRM repository, indicating it is not a public API but an internal report-support package, owned by APPS and not referenced by any other package.

The package serves the business requirement of producing a printable and exportable listing of discrete jobs for a given organization, together with their material requirements, component availability, and net requirements. It does so by translating the user's concurrent program parameters into SQL fragments that the underlying query substitutes lexically, and by computing derived quantities and break values through XML Publisher formula columns.

Key Procedures and Functions

The documented structure comprises thirty procedures and functions. The principal ones are:

• BEFOREREPORT — The report initialization entry point. It sets P_CONC_REQUEST_ID from FND_GLOBAL.CONC_REQUEST_ID and contains the standard FND SRWINIT and FND FLEXSQL user-exit hooks for the MSTK flexfield (retained as comments in the shipped source).
• AFTERREPORT — The report cleanup entry point, containing the complementary FND SRWEXIT user-exit hook.
• LIMIT_JOBS — Builds the lexical WHERE clause fragment restricting the job number range, handling open-ended from/to permutations of P_FROM_JOB and P_TO_JOB.
• LIMIT_DATES — Builds the date range restriction on WRO.date_required, using open intervals so that the to-date is treated as inclusive.
• DEPARTMENT_LIMITER, LIMIT_PLANNERS, LIMIT_BUYER — Additional lexical builders that restrict the query by department, planner, and buyer respectively.
• Formula functions — C_NETTABLE_CONSTRAINTFORMULA, C_TOTAL_QTY_FORMULAFORMULA, C_QTY_SHORT_QOHFORMULA, C_BREAK_JOBFORMULA, C_BREAK_DATE_REQUIREDFORMULA, C_BREAK_DEPARTMENTFORMULA, C_LIMIT_COMPONENTSFORMULA, C_BREAK_COMP_DISPFORMULA, NET_QTY_DETAILFORMULA, AVAIL_QTYFORMULA, C_COMPONENT_SORTFORMULA, ZEROFORMULA, and C_BREAK_ASSY_DISPFORMULA. These are XML Publisher formula columns executed at the group level to derive availability, net quantity, sorting keys, and control-break values.

Tables Accessed

No base tables are documented against this package in the ETRM repository; the data access is performed by the embedded report query in the corresponding XML report definition rather than by explicit SQL inside the package body. The lexical fragments emitted by the package reference the WIP entity and job tables through their APPS synonyms, notably the work in process entity view used for WIP_ENTITY_NAME and the material requirements table used for date_required. The flexfield user exit references the INV application for the MSTK (stock) key flexfield, supplying the assembly display value into parameter :P_ASSY.

Usage Notes

The package is invoked exclusively through the Discrete Job Detail concurrent program or its corresponding XML Publisher report run from the Requests form; because it is catalogued as OTHER and is referenced by zero other packages, Oracle does not support calling it from custom code. Its behavior is driven entirely by the concurrent program parameter set. The parameter p_sort_by, which the search string references, is not a documented member of this package — sort sequencing for the report is supplied by the C_COMPONENT_SORTFORMULA and C_BREAK_* formula functions instead, so administrators seeking to influence report ordering should review those formula columns and the report's own parameter definitions rather than package-level members.

Standard customization guidance applies: the shipped package is a locked Oracle object and should not be modified directly. Parameter-driven personalization, the XML report data template, and any downstream extensions should be implemented through supported XML Publisher layouts or a custom copy of the package under a customer schema prefix.