Search Results c_customer_where
Overview
ONT_OEXOHOHS_XMLP_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Order Management order holds report (OEXOHOHS). The suffix "XMLP_PKG" identifies it as the server-side program unit generated to accompany an Oracle XML Publisher (BI Publisher) concurrent program, providing the data model logic and formula functions that the report template invokes at runtime. In EBS 12.1.1 and 12.2.2 the package is classified as API classification OTHER, indicating that it is not a public, supported integration API but rather an internal report-support artifact. Its responsibilities center on resolving report parameters—operating unit, customer name ranges, hold name ranges, item ranges, and flexfield display options—into the WHERE-clause fragments and formatted output values required by the order holds report. The package reads order hold information and item cross-reference and customer item data to present holds applied to sales orders alongside descriptive item and customer context.
Key Procedures and Functions
The package exposes fourteen documented units. SOB_NAMEFORMULA returns a formatted set of books or operating unit name for display. BEFOREREPORT and AFTERREPORT are the standard XML Publisher report-level entry points executed before and after report generation, used respectively to initialize state and to clean up or finalize output. AFTERPFORM performs post-parameter processing once the concurrent program parameters have been accepted. ITEM_DISPLAY_MEANINGFORMULA derives the display meaning used for the item identifier. C_CUSTOMER_WHERE and C_HOLD_WHERE return dynamically constructed WHERE-clause fragments that constrain the report query by customer and by hold respectively, based on the user-supplied low and high ranges. C_LINE_OR_ORDERFORMULA resolves whether a hold applies at the line or order level for a given order hold identifier. C_SHOW_AMOUNTFORMULA determines whether a monetary amount should be displayed for a header, conditioned on the line-or-order determination. ITEM_DSPFORMULA resolves the appropriate item display value from the item identifier type, master organization, inventory item, ordered item, and organization context. C_MASTER_ORGFORMULA returns the master organization value. C_AMOUNTFORMULA, the function corresponding to the user's search term, accepts an amount and returns a numeric value, applying rounding based on the MIX_PRECISION parameter to normalize monetary amounts for report display. C_FORMATTED_FLEX_VALUE_P and RP_ITEM_FLEX_ALL_SEG_P are accessor functions returning the package-level flexfield value variables.
Tables Accessed
The package references six tables through APPS synonyms. OE_ORDER_HOLDS is the primary transactional source, supplying the order hold records that the report lists and the hold identifiers consumed by C_LINE_OR_ORDERFORMULA. MTL_CUSTOMER_ITEMS and MTL_CUSTOMER_ITEM_XREFS provide customer-specific item numbering and cross-reference relationships used when resolving item display values. MTL_CROSS_REFERENCES and MTL_CROSS_REFERENCE_TYPES supply the cross-reference type definitions and values that ITEM_DSPFORMULA uses to translate an item identifier into its display meaning. DUAL is used for simple single-row evaluations, typically within the formula functions and default parameter resolution.
Usage Notes
ONT_OEXOHOHS_XMLP_PKG is invoked indirectly rather than called directly by custom code. It is executed when the associated Order Management order holds XML Publisher concurrent program is submitted, at which point BEFOREREPORT, AFTERPFORM, the WHERE-clause functions, and the various formula functions are called by the report data model and template. The ETRM metadata records zero packages referencing this package, confirming it sits at the outer edge of the dependency graph and is not reused by other PL/SQL units. Because the package is classified OTHER and its header identifies it as a non-shipped report support unit, it should be treated as internal and subject to change with patching; customizations that depend on its behavior are best implemented through the underlying report definition or through supported Order Management APIs rather than by direct invocation of these functions.