Search Results wip_wipsuemp_xmlp_pkg




Overview

WIP_WIPSUEMP_XMLP_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the ETRM registry as an "OTHER" API type. It serves as the supporting database package for the WIPSUEMP (Work in Process Employee Utilization / Employee Labor Summary) XML Publisher concurrent program report. The package encapsulates the report's runtime logic, including parameter binding, group-level filters, and formatting routines that the Oracle Reports/XML Publisher engine calls during execution. It is a report-driver package rather than a public business API: its procedures are invoked by the reporting framework to construct SQL queries and control report output. In EBS 12.1.1 and 12.2.2, this package operates unchanged in structure, with the file header ("WIPSUEMPS.pls 120.1") indicating the last significant revision dates to 2008, prior to the 12.2 online patching model. As it references only FND_CURRENCIES via APPS synonyms, its footprint is a single shared lookup table. No other packages reference it, and it exposes no documented public interfaces, confirming its role as a private report implementation package.

Key Procedures and Functions

The package declares seven documented functions or procedures:

  • EMPLOYEE_TABLE — Returns a character value, typically a SQL fragment or WHERE-clause string, used to build the employee selection subquery for the report. It allows the report to accept a list of employees as a parameter.
  • LIMIT_EMPLOYEE — Returns a character value that constrains the report to the range of employees specified by the P_FROM_EMPLOYEE and P_TO_EMPLOYEE parameters. This function generates the predicate limiting the employee range, and it is the object most closely associated with the user's "limit_employee" search term.
  • LIMIT_DATES — Returns a character value that limits the report output to the date range defined by P_FROM_DATE and P_TO_DATE; it produces the corresponding date predicate.
  • BEFOREREPORT — Returns a Boolean and is invoked before the report executes. It performs initialization such as resolving the organization and currency context, and preparing parameter values.
  • AFTERREPORT — Returns a Boolean, invoked after report completion, typically for cleanup or resetting package state.
  • C_SUBTITLEFORMULA — Returns a VARCHAR2 and constructs the report subtitle, taking P_CURRENCY_CODE as an input to display the correct currency context in the heading.
  • AFTERPFORM — Returns a Boolean and executes after the parameter form (the "After Parameter Form" trigger), validating or transforming the entered parameters before the report query is built.

The package also declares global variables including P_ORGANIZATION_ID, P_PRECISION, P_CURR_CODE, P_DISPLAY_IN_DETAIL, P_CURRENT_ONLY, P_CONC_REQUEST_ID, and P_DEBUG.

Tables Accessed

The only documented table referenced through APPS synonyms is FND_CURRENCIES, the core Oracle Applications currency definition table. The package reads this table, most likely within C_SUBTITLEFORMULA or the before-report logic, to resolve the currency code and precision (P_PRECISION, P_CURR_CODE) used to correctly format monetary amounts displayed on the employee utilization report. No inserts, updates, or deletes are documented, consistent with the package's read-only report-driver purpose.

Usage Notes

This package is invoked exclusively in the context of the WIPSUEMP XML Publisher concurrent program. In Oracle EBS 12.1.1 and 12.2.2, the concurrent manager invokes the packaged report, and the XML Publisher template engine calls these functions at defined trigger points: AFTERPFORM after parameter entry, BEFOREREPORT before the data model query, and AFTERREPORT on completion. LIMIT_EMPLOYEE and LIMIT_DATES are group or data-model functions that inject filter predicates into the report query. Because the package is not referenced by any other package and exposes no documented public API, customizations should avoid direct invocation. Any modification requires following Oracle's report customization standards, and in a 12.2 multi-tenant, online-patching environment the package is patched as part of the WIP application code, so custom changes must be preserved as separate custom packages.