Search Results oe_blanket_pub




Overview
Explore in AI Chat

Overview

OE_BLANKET_PUB is a public PL/SQL package owned by the APPS schema that supports the Oracle Order Management blanket sales agreement functionality in Oracle E-Business Suite 12.1.1 and 12.2.2. A blanket sales agreement is a long-term commitment between a customer and a supplier that defines negotiated items, prices, and terms over a specified period; individual orders are then released against the agreement rather than negotiated independently. The OE_BLANKET_PUB package provides the public application programmatic interface (API) layer through which blanket agreement data is processed by forms, concurrent programs, workflows, and custom extensions. It belongs to the OE_BLANKET family of packages and carries the PUB classification in the ETRM documentation, indicating that its procedures are intended for external invocation rather than internal implementation support. The package delegates the majority of its business logic to the private package OE_BLANKET_PVT, acting as a controlled entry point that insulates callers from underlying implementation changes. In the dependency hierarchy, OE_BLANKET_PUB references only SYS.STANDARD and is referenced by eleven other packages, confirming its role near the top of the blanket agreement call stack.

Key Procedures and Functions

The ETRM metadata documents a single public procedure for this package: PROCESS_BLANKET. This procedure encapsulates the processing of blanket sales agreement records submitted through the public interface. It is the designated entry point through which callers request validation and persistence activity against blanket agreement header and line data. Because the blanket agreement model includes header-level attributes such as customer, agreement number, effective dates, and status, as well as line-level attributes such as ordered items, pricing, and quantities, PROCESS_BLANKET coordinates activity across both levels rather than operating on an isolated row. No parameter list is published in the available metadata, and the procedure's signature should be confirmed from the deployed package specification in the target environment before any custom invocation is written. Implementers should treat PROCESS_BLANKET as the supported API surface and avoid calling the underlying private package OE_BLANKET_PVT directly, since its interface may change without notice between point releases or patches.

Tables Accessed

The package accesses four tables through APPS synonyms, as documented in the ETRM metadata. OE_ORDER_HEADERS_S is the Order Management order header base table, which stores the blanket agreement header record including customer, agreement context, dates, and status. OE_ORDER_LINES_S is the corresponding order line base table, storing the blanket agreement lines, the ordered items, pricing attributes, and quantities committed under the agreement. Both are the "_S" (base) tables, indicating that the package operates on the underlying columns rather than the translated or dated views. DUAL is used for standard single-row PL/SQL evaluation and control-flow constructs. PLITBLM is a standard Oracle EBS PL/SQL table type used for array-based processing, which indicates that PROCESS_BLANKET handles blanket agreement data in bulk sets rather than row by row, improving throughput when multiple agreements or lines are processed in a single call.

Usage Notes

OE_BLANKET_PUB is typically invoked by the Order Management blanket agreement forms and by the surrounding blanket agreement infrastructure. The dependency list confirms that OE_BLANKET_FORM_CONTROL, OE_BLANKET_HEADER_SECURITY, OE_BLANKET_LINE_SECURITY, OE_BLANKET_PRICING_UTIL, OE_BLANKET_UTIL, OE_BLANKET_WF, OE_BLANKET_WF_UTIL, OE_ORDER_GRP, OE_VERSIONING_UTIL, and OE_VERSION_BLANKET_COMP all reference this package, showing that form-level control, security checks, pricing utilities, workflow integration, and versioning components all route through the public API. Custom code that needs to create, validate, or process blanket agreements should call OE_BLANKET_PUB.PROCESS_BLANKET rather than performing direct DML against OE_ORDER_HEADERS_S or OE_ORDER_LINES_S, because the procedure enforces the validation, security, and workflow rules that the surrounding OE_BLANKET packages expect. Because the package is documented as VALID and is part of the shipped APPS schema, it should be treated as Oracle-owned and must not be modified. Any customization should wrap the public procedure and rely on its error-handling and commit semantics. Developers should also verify the exact parameter list in their EBS release, as signatures can differ between 12.1.1 and 12.2.2 and across patch levels.