Search Results g_batch_mode

Overview

OE_BLANKET_PVT is a private PL/SQL package in the Oracle E-Business Suite Order Management (OM) module, owned by the APPS schema and classified as PVT (private) in the ETRM documentation. Its principal role is to implement the internal processing logic that backs the public blanked sales agreement (blanket order) APIs within Order Management. In Oracle EBS, a blanket sales agreement is a long-term commitment between a customer and a supplier that establishes agreed prices, items, and terms over a defined period; sales orders are subsequently released against that blanket. OE_BLANKET_PVT encapsulates the validation, defaulting, and persistence logic required to create and maintain the blanket header, its lines, and the associated processing orchestration.

The package is designed with a private scope, meaning it is not intended for direct invocation by external customers. It is exposed to the application layer through the public wrapper package OE_BLANKET_PUB, and is referenced by two other packages as documented in the ETRM metadata. The private designation allows Oracle to change internal signatures and logic without impacting the public API contract. A package-level global, G_BATCH_MODE, controls behavior when blanket records are processed in batch rather than interactively.

Key Procedures and Functions

The ETRM metadata documents three procedures, all consistent with a layered processing model:

• Header — Validates and processes the blanket agreement header record. It takes a control record, a validation level, and both a current and a prior (old) header record, returning a status indicator. The old header record supports change detection and audit comparison.
• Lines — Validates and processes the collection of blanket agreement lines. It accepts a control record, a validation level, and in/out line tables (current and prior versions), returning a status. This handles the line-level attributes such as item, price, and quantity commitments.
• Process_Blanket — The orchestrating entry point of the package. It coordinates the end-to-end creation or update of a blanket agreement by driving the header and line processing. Its parameters support Multi-Org Access Control (MOAC) through p_org_id and p_operating_unit, an API version number, a validation level, standard API return status/message outputs, and input/output header and line records plus a control record. The header and line inputs default to the G_MISS_* sentinel values defined in OE_BLANKET_PUB, enabling partial updates where unchanged attributes are left unspecified.

Tables Accessed

The ETRM metadata documents one table accessed via an APPS synonym: PLITBLM. This is the Order Management interface/processing table associated with blanket agreement line and price list information. Access to this table supports the persistence and validation of blanket line attributes during the Process_Blanket execution path. No other base tables are listed in the documented metadata; additional writes to core Order Management tables occur indirectly through the public API and the standard concurrent processing framework.

Usage Notes

OE_BLANKET_PVT is not intended for direct customer invocation. It is typically reached through OE_BLANKET_PUB, which the Order Management forms and any conforming custom code call. When developers need to programmatically create or update blanket sales agreements, they should call the public API rather than this private package. The package supports MOAC, so callers must supply the correct operating unit context. For bulk generation or release scenarios, the batch-mode global influences execution behavior, and the standard concurrent program infrastructure may invoke the public API repeatedly, each invocation routing through Process_Blanket. Because the package is classified private, its internal signatures may change between releases; customizations should always bind to the public API layer.