Search Results lot_serials

Overview

APPS.OE_ORDER_PVT is the private implementation package for Oracle Order Management's order-processing engine in Oracle E-Business Suite 12.1.1 and 12.2.2. It is the internal counterpart to the public OE_ORDER_PUB API, which is the sanctioned entry point for external callers creating, modifying, and processing sales orders programmatically. OE_ORDER_PVT carries out the entity-specific persistence work — validating and writing header, line, sales-credit, payment, and lot/serial data — that the public API orchestrates but does not itself perform. The package is declared AUTHID CURRENT_USER and is classified as a PVT API in the ETRM repository, signaling that Oracle does not guarantee its signature across releases and that customers should not call it directly.

The package encapsulates the transactional semantics of the order-processing workflow: applying user-supplied changes to an in-memory record set, comparing against the prior ("old") image of that data, validating the delta, and committing the result. It also owns orchestration duties such as workflow notification and record locking.

Key Procedures and Functions

• VALID_UPGRADED_ORDER — Function returning a Boolean that indicates whether a given order (identified by header ID) is a valid upgraded order. Used to distinguish orders migrated from earlier releases from those created natively, since the two may follow different processing paths.
• PROCESS_ORDER — The general entry point that drives processing across all entities of an order. Most other entity procedures exist as narrower alternatives to this one for performance reasons.
• HEADER, HEADER_SCREDITS, HEADER_PAYMENTS — Entity-specific procedures that process header-level data, header-level sales credits, and header-level payment information respectively, each working against the corresponding public record or table type and an "old" image used for change detection.
• LINES, LINE_SCREDITS, LINE_PAYMENTS, LOT_SERIALS — The line-level counterparts, processing order lines, line sales credits, line payments, and lot/serial number assignments attached to lines.
• PROCESS_REQUESTS_AND_NOTIFY — Runs post-processing actions and issues the notifications associated with order processing. Documentation explicitly notes it should generally be called after invoking individual entity procedures.
• LOCK_ORDER — Acquires locks on order records, establishing the concurrency control needed before a read-modify-write cycle on the order tables.
• CANCEL_ORDER — Cancels an existing order.
• SET_RECURSION_MODE — Controls reentrancy behavior, allowing callers to indicate whether processing should recurse into dependent entities.
• GET_ORDER — Retrieves the current stored image of an order so that callers can populate the input record structures before applying changes. This is the procedure most often sought when developers search for "get_order".

Tables Accessed

The package reads and writes the core Order Management base tables through APPS synonyms: OE_ORDER_HEADERS / OE_ORDER_HEADERS_ALL for header records, OE_ORDER_LINES / OE_ORDER_LINES_ALL for line records, and OE_SALES_CREDIT_TYPES for sales-credit classification, supporting the header- and line-level sales-credit procedures. MTL_SYSTEM_ITEMS and its key-flexfield view MTL_SYSTEM_ITEMS_KFV supply item validation and item information, while BOM_EXPLOSIONS supports configured or bill-of-material-related processing. PLITBLM is a PL/SQL index-by table helper used for bulk binding of ID lists. Together these tables underpin the create-and-update path for sales orders and their dependent entities.

Usage Notes

OE_ORDER_PVT is invoked indirectly: standard Order Management forms (such as the Sales Orders window) and concurrent programs call OE_ORDER_PUB, which delegates to this package. Custom code and integrations should follow the same pattern and call OE_ORDER_PUB rather than OE_ORDER_PVT, because the PVT layer's signatures are not part of Oracle's supported interface and may change between 12.1.1 and 12.2.2. The package is referenced by 82 other packages, indicating how deeply it is embedded in order-processing flows. When calling entity-level procedures directly, callers should expect to invoke PROCESS_REQUESTS_AND_NOTIFY afterward, and should use LOCK_ORDER and GET_ORDER to obtain a consistent, locked image of the order before applying modifications.