Search Results oe_order_headers_s




Overview
Explore in AI Chat

Overview

OE_BLANKET_PUB is the public API package body in the Oracle Order Management (OM) module of Oracle E-Business Suite, residing in the APPS schema. Its purpose is to provide a supported, encapsulated interface for processing blanket sales agreements and the releases generated against them. Blanket agreements function as long-term purchasing instruments within Order Management: a customer agrees to a quantity or value of goods at negotiated terms, and individual orders are created as releases that draw down against the agreement. OE_BLANKET_PUB exists so that this behavior can be driven programmatically rather than exclusively through the Order Management forms, giving implementers a controlled entry point that enforces the same validation, defaulting, and processing logic applied in the standard application flows.

The package body is documented as VALID. It is a dependent object rather than a referenced one: the ETRM metadata records that OE_BLANKET_PUB is not referenced by any other database object, which confirms its role as a top-level consumer of lower-level OM infrastructure rather than a shared utility.

Key Procedures and Functions

The documented API surface of OE_BLANKET_PUB consists of a single public procedure:

  • PROCESS_BLANKET — the sole published entry point. In line with Oracle's PUB/PRIVATE package convention, this procedure acts as the orchestrating call for blanket agreement processing, delegating detailed work to the private implementation package OE_BLANKET_PVT. As with all documented EBS public APIs, callers are expected to supply standard API parameters such as a return status and message list, though the exact signature is defined by the package specification and should be confirmed against the deployed source.

All remaining logic is held in the private counterpart and is not part of the supported interface.

Tables Accessed

The ETRM metadata records four tables referenced through APPS synonyms:

  • OE_ORDER_HEADERS_S — the base table storing order and agreement header information. This is the object the user searched for, and it is central to the package's operation: blanket agreements are represented as header records that the processing logic reads and writes.
  • OE_ORDER_LINES_S — stores the associated order lines, including the line-level quantities, items, and pricing that constitute the agreement and its releases.
  • DUAL — the standard single-row utility table, used for scalar evaluation and date or sequence lookups.
  • PLITBLM — the PL/SQL integer table type used internally for bulk processing and multi-value handling.

Dependency metadata shows the package also calls OE_ORDER_PUB, OE_HEADER_UTIL, OE_LINE_UTIL, OE_MSG_PUB, OE_GLOBALS, OE_SYS_PARAMETERS, and the FND_API and MO_GLOBAL utilities, indicating that insert and update activity against the underlying tables is largely routed through these shared order-processing routines rather than performed directly.

Usage Notes

OE_BLANKET_PUB is typically invoked when blanket agreement functionality must be exercised outside the standard Order Management forms — for example from custom concurrent programs, interface or conversion routines that load agreements in bulk, or workflow-driven processes. Because the package is classified as a public API and is documented in the ETRM repository, it is the sanctioned mechanism for this purpose; custom code should call PROCESS_BLANKET rather than replicating its logic or modifying OE_ORDER_HEADERS_S and OE_ORDER_LINES_S directly. Direct DML against the order tables bypasses validation and can corrupt agreement balances.

Callers should follow the standard EBS API contract: initialize the FND_API global variables, provide a message list to capture errors, and check the returned status before proceeding with subsequent steps. Because OE_BLANKET_PUB is not referenced by any other database object, its behavior is scoped to order management processing and carries no dependencies from unrelated modules. Both Oracle EBS 12.1.1 and 12.2.2 environments rely on the same API classification and dependency profile, so code written against this package remains portable across those releases.