Search Results c_from_catformula

Overview

INV_INVTRSHS_XMLP_PKG is an Oracle E-Business Suite PL/SQL package owned by APPS that supports the Inventory Transaction Historical Summary report, a concurrent program in Oracle Inventory. The package is generated in the standard Oracle Reports XML Publisher (XMLP) pattern, in which a report definition delegates its parameter validation and data retrieval logic to a companion database package. The suffix _XMLP_PKG identifies it as the program unit that backs a report executed through the XML Publisher engine rather than a purely client-side Oracle Reports runtime.

The package declares the report's concurrent program parameters, typified by P_CONC_REQUEST_ID, P_ORG_ID, P_CATEGORY_FROM, P_ITEM_FROM, P_ITEM_PLANNER, and P_ONHAND_ONLY_YN, and exposes entry points that the report calls before and after execution. It is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, which is standard for these generated report packages in EBS 12.1.1 and 12.2.2.

The user search term c_from_catformula corresponds directly to the function C_FROM_CATFORMULA declared at line 33 of the package specification. It is a report formula function that the report layout invokes to derive the "from" category display value used in the report output.

Key Procedures and Functions

The documented package metadata lists twenty procedures and functions. Several are report-lifecycle hooks. BEFOREREPORT and AFTERREPORT bracket the execution of the report, with BEFOREREPORT typically performing setup and AFTERREPORT performing cleanup. BEFOREPFORM and AFTERPFORM bracket the parameter form phase, allowing the package to prepare or finalize parameter values before and after the user's parameter form is processed.

A large group of functions are report formulas that compute display and filter values. C_FROM_CATFORMULA, the function identified by the search, resolves the category "from" value. C_CAT_WHEREFORMULA constructs the category restriction used in the query. C_ORDER_BYFORMULA assembles the report's ORDER BY clause. The pad functions C_HDR_ITEM_PADFORMULA, C_POS_ITEM_PADFORMULA, and C_CAT_PADFORMULA format and pad header, positional, and category values for aligned display.

Additional formula functions supply descriptive text and filter logic: C_GROUP_OPTION_NAMEFORMULA and C_CAT_SET_NAMEFORMULA return labels for the grouping option and category set; C_ONHAND_WHEREFORMULA and C_ITEMPLANNER_WHEREFORMULA build WHERE fragments for on-hand and planner filtering; C_ONHAND_ONLY_YNFORMULA and C_SEND_NOTIFICATIONS_YNFORMULA resolve yes/no parameter flags; C_NET_QTY_HDRFORMULA and C_NET_QTY_POSFORMULA compute net quantity figures for the header and positional sections; and C_NOTIFICATIONFORMULA determines notification content. The package also exposes a SEND procedure, used to dispatch notifications when the notification option is enabled. No parameter lists are invented here; the documented specification shows that the pad formulas accept a single VARCHAR2 argument and the remaining formulas take no arguments.

Tables Accessed

The package references two documented base tables through APPS synonyms. MTL_CATEGORY_SETS is accessed to resolve category set information, which drives the category set name, the category flexfield structure, and the category filtering used by C_FROM_CATFORMULA and C_CAT_WHEREFORMULA. MTL_SECONDARY_INVENTORIES is accessed to support on-hand sourcing and secondary inventory filtering used by the on-hand related formulas. These references are read-oriented and support report parameter resolution and query construction.

Usage Notes

INV_INVTRSHS_XMLP_PKG is invoked indirectly whenever the Inventory Transaction Historical Summary report is run. The concurrent program submits the report, the XML Publisher runtime calls BEFOREREPORT and the parameter form hooks, and the report layout calls the individual formula functions to obtain filter clauses and formatted display values. Because the package is AUTHID CURRENT_USER and is not referenced by any other documented package, it should be treated as report-specific implementation rather than a reusable API. Customizations should avoid modifying the generated package directly, since Oracle regenerates these program units with patch application; extensions are better implemented through report template changes or custom concurrent program copies.