Search Results oe_validate_header




Overview
Explore in AI Chat

Overview

OE_VALIDATE_HEADER is a server-side PL/SQL package in the APPS schema that encapsulates header-level validation logic for Oracle Order Management. It operates as an internal validation engine invoked by the public Order Management APIs (notably OE_ORDER_PUB) and by concurrent bulk-processing programs to enforce business rules before an order header is committed. The package validates attributes required when booking an order, detects duplicate customer purchase order numbers, and orchestrates entity-level validation and defaulting. Its API classification in the ETRM metadata for 12.2.2 is listed as OTHER, confirming it is a supporting utility rather than a formally published interface. The package body depends on FND_API, STANDARD, and OE_ORDER_PUB, and it is referenced by OE_ORDER_PVT, OE_ORDER_BOOK_UTIL, OE_BULK_PROCESS_HEADER, OE_BULK_PROCESS_LINE, OE_VALIDATE_LINE, and OE_VALIDATE_HEADER itself, indicating that header and line validation coordinate with one another during order processing. This dependency pattern is consistent across Oracle EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The ETRM documentation identifies five procedures and functions within this package:

  • CHECK_BOOK_REQD_ATTRIBUTES — Evaluates whether the required attributes for booking an order header have been populated. It is the principal gatekeeper invoked when an order transitions into booked status.
  • IS_DUPLICATE_PO_NUMBER — Determines whether the customer purchase order number supplied on the header duplicates an existing value for the same customer, supporting duplicate-PO validation rules controlled by Order Management profile options.
  • ENTITY — Provides the entity-level validation entry point used by the surrounding validation framework, driving validation for the header entity as a whole.
  • ATTRIBUTES — Drives attribute-level validation and defaulting behavior for header fields processed through the validation framework.
  • ENTITY_DELETE — Handles validation logic associated with deletion of a header entity, ensuring dependent data and referential checks are respected.

No parameter lists are documented in the ETRM metadata; the descriptions above reflect the documented procedure names and their evident purpose within the Order Management validation architecture.

Tables Accessed

The package accesses several core Order Management and Trading Community (HZ) tables through APPS synonyms. Within Order Management it references OE_ORDER_HEADERS and OE_ORDER_LINES (including OE_ORDER_LINES_ALL) for order data, OE_BLANKET_HEADERS and OE_BLANKET_HEADERS_EXT for blanket sales agreement context, and OE_PAYMENTS for payment validation. Customer data is resolved through HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNTS_ALL, HZ_CUST_ACCOUNT_ROLES, HZ_CUST_ACCT_RELATE, HZ_CUST_ACCT_RELATE_ALL, HZ_CUST_ACCT_SITES, HZ_CUST_ACCT_SITES_ALL, HZ_CUST_SITE_USES_ALL, and HZ_PARTY_SITES. These HZ reads support validation of the sold-to, ship-to, bill-to, and related account relationships, as well as duplicate-PO checks scoped to a customer account. The combination of order and customer tables allows header validation to confirm that the customer context and order attributes are mutually consistent before booking.

Usage Notes

OE_VALIDATE_HEADER is not intended for direct invocation by end users. It is called by higher-level Order Management components: OE_ORDER_PUB in the public API stack, OE_ORDER_PVT and OE_ORDER_BOOK_UTIL during booking, and the bulk-processing concurrent programs OE_BULK_PROCESS_HEADER and OE_BULK_PROCESS_LINE when importing orders via the Order Import interface. Orders entered through the Order Management sales order form and orders submitted through Order Import or exposed web services ultimately route header validation through this package. Custom code should generally call the published OE_ORDER_PUB APIs rather than reusing this package directly, since its procedures assume the caller has already established API context, entity structures, and message-list handling. Because the package is referenced by both header and line validation modules, changes to its logic can affect booking, order import, and returns processing simultaneously; implementers should therefore treat it as a restricted internal object during upgrades and patching. The same dependency footprint is observed in both Oracle EBS 12.1.1 and 12.2.2, so remediation and regression testing guidance applies equally to both releases.