Search Results load_header

Overview

OE_BLANKET_UTIL is an internal utility package within the Oracle Order Management (OM) module of Oracle E-Business Suite, owned by the APPS schema and classified as a UTIL-type API. Its principal business function is to centralize the low-level processing logic that supports blanket sales agreements — the long-term customer purchasing commitments that allow release orders to be placed against pre-negotiated items, prices, and quantities. The package encapsulates the mechanics of validating, inserting, updating, deleting, locking, and querying blanket header and line records, and it supplies shared helper routines used by the blanket agreement forms, security routines, pricing logic, and workflow integration. Because it is a utility layer rather than a public business API, it is designed primarily to be consumed by other OM packages and form-level PL/SQL rather than called directly by external integrations. Its dependency on FND_API indicates that it observes the standard EBS API error-handling and message conventions, while its reliance on OE_BLANKET_PUB and the OE_AK_BLANKET_HEADERS_V and OE_AK_BLANKET_LINES_V views ties it to the blanket agreement public interface and to the multi-org secured views. With 44 documented procedures and functions, it forms a substantial portion of the internal machinery behind blanket sales agreements in both 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented routines fall into several functional groups. Data manipulation routines include INSERT_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW, which perform the physical DML and row-level locking against blanket header and line records. Query routines — QUERY_HEADER, QUERY_LINES, QUERY_BLANKET, and QUERY_ROW — retrieve blanket data for display or downstream processing. Validation routines include VALIDATE_ATTRIBUTES, VALIDATE_ENTITY, VALIDATE_LINE_NUMBER, and VALIDATE_ITEM_UNIQUENESS; these enforce attribute-level correctness, entity integrity, line numbering rules, and the requirement that an item not be duplicated inappropriately within a blanket. DEFAULT_ATTRIBUTES and LOAD_HEADER populate or initialize record structures, while PROCESS_OBJECT serves as an orchestrating entry point that applies a set of changes to a blanket object.

On the pricing side, CREATE_PRICE_LIST, ADD_PRICE_LIST_LINE, CLEAR_PRICE_LIST_LINE, and IS_BLANKET_PRICE_LIST handle the creation and maintenance of the price list associated with a blanket agreement and determine whether a given price list is blanket-related. GET_ORDER_NUMBER supplies the next or associated order number used when a blanket is converted or released.

Tables Accessed

The package reads and writes the core blanket tables OE_BLANKET_HEADERS, OE_BLANKET_HEADERS_ALL, and OE_BLANKET_HEADERS_EXT, which hold header, multi-org, and extension (descriptive flexfield) data respectively. Customer information is drawn from the HZ tables HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, HZ_CUST_ACCT_RELATE_ALL, HZ_CUST_ACCT_SITES, HZ_CUST_SITE_USES, and HZ_CUST_SITE_USES_ALL to validate and default the sold-to, ship-to, and bill-to parties associated with an agreement. Item information is validated against MTL_SYSTEM_ITEMS and MTL_SYSTEM_ITEMS_B, with customer-specific and cross-reference data coming from MTL_CUSTOMER_ITEMS, MTL_CUSTOMER_ITEM_XREFS, MTL_CROSS_REFERENCES, and MTL_CROSS_REFERENCE_TYPES. OE_SYS_PARAMETERS is consulted for system-level OM defaults.

Usage Notes

OE_BLANKET_UTIL is referenced by nine other OM packages, most notably OE_BLANKET_PVT, OE_BLANKET_PRICING_UTIL, OE_BLANKET_WF_UTIL, OE_BLANKET_HEADER_SECURITY, OE_BLANKET_LINE_SECURITY, OE_BLANKET_FORM_CONTROL, OE_ORDER_GRP, OE_DELAYED_REQUESTS_PVT, and OE_VERSIONING_UTIL. This dependency profile confirms that the package is invoked indirectly through the Blanket Sales Agreement form, through workflow-driven processing, through security and versioning logic, and through the public blanket API. Customizations should avoid modifying the package directly, as it is a standard seeded object; extension development should instead use the documented public APIs such as OE_BLANKET_PUB. Because behavior can differ subtly between 12.1.1 and 12.2.2 patch levels, implementations should verify the object's current status and dependencies in the target instance before relying on any specific routine.