Search Results oe_dual_uom_hook

Overview

APPS.OE_DUAL_UOM_HOOK is a seedable customization hook package body shipped with Oracle Order Management in EBS 12.1.1 and 12.2.2. Its Header token (OEXDUHOB.pls 120.0.12020000.4) identifies it as a non-shipped (noship) PL/SQL unit whose entire purpose is to provide customers a supported extension point for dual unit of measure (dual UOM) processing on order lines. Dual UOM allows an order line to carry both a primary (ordering) UOM and a secondary (fulfillment) UOM, so that a single line can express quantities in two dimensions — for example, ordering by case while fulfilling and shipping by each.

Out of the box the package does nothing functional. Every function is deliberately stubbed to return NULL, which the caller interprets as "hook not in use." This design lets Oracle Order Management invoke the hook unconditionally while ensuring zero behavioral change until a customer inserts custom logic. The package is classified as OTHER in the API taxonomy and is referenced by two other packages in the Order Management codebase, which are the internal callers that query the hook during line processing.

Key Procedures and Functions

The package body exposes two documented functions:

• GET_FULFILLMENT_BASE — A private (PVT) API that returns the value of the fulfillment_base field for an order line. It receives an order line record typed as OE_Order_PUB.Line_Rec_Type and is expected to return only 'P', 'S', or NULL. NULL explicitly denotes that the hook is not in use. Any other return value is treated as invalid and raises an error. The stub logs entry and exit messages through oe_debug_pub when debug is enabled, executes the region marked "Start Custom Code" / "End Custom Code," and otherwise returns NULL. Its exception handler writes an unexpected-error message via oe_msg_pub and returns 'E' — a deliberately invalid value that signals the hook API itself has errored out.
• GET_PRICING_UOM — The companion hook function governing the UOM dimension used for pricing on a dual UOM line. Like GET_FULFILLMENT_BASE, it is a customization stub intended to be populated with customer-specific logic; the documented contract requires it to return only valid UOM indicator values (or NULL when the hook is not used), and it participates in the same debug and error-messaging conventions.

Because both functions are hooks rather than public APIs, Oracle does not document parameter lists beyond the line record passed to GET_FULFILLMENT_BASE. Implementers must not alter signatures.

Tables Accessed

The only documented table reference is OE_ORDER_LINES_ALL, accessed through its APPS synonym. The package declares its local variable l_fulfillment_base using the anchored type oe_order_lines_all.fulfillment_base%type, guaranteeing the variable matches the column's datatype and length if Oracle changes it. The stub itself performs no DML; the table reference exists to anchor the return value's type. Any custom code added by an implementer would typically read OE_ORDER_LINES_ALL (and related OM tables) to derive the fulfillment base or pricing UOM for the line being processed.

Usage Notes

OE_DUAL_UOM_HOOK is not invoked directly by end users or by typical custom code. It is called by internal Order Management packages during order line processing when dual UOM functionality is enabled. Customers who need to override how the fulfillment base or pricing UOM is determined — for example, deriving it from item attributes, customer profile, or order type — insert logic into the clearly marked custom code regions and then raise the version in the $Header line to a high value (for example, 120.1000) so later Oracle patches do not silently overwrite the customization. This version bump is mandatory for the customization to survive patching.

Debug output is conditional on oe_debug_pub.g_debug_level; setting the OM debug profile option produces trace messages for hook entry, exit, and exceptions. Errors are surfaced through oe_msg_pub at the unexpected-error level. In EBS 12.1.1 and 12.2.2 the file contents and contract are identical in substance, so a customization validated on 12.1.1 carries forward to 12.2.2 provided the version token is maintained.