Search Results oe_header_status_pub




Overview
Explore in AI Chat

Overview

OE_HEADER_STATUS_PUB is a public PL/SQL package in the APPS schema that exposes the workflow header status logic used by Oracle Order Management. Its role is to determine, at runtime, the current workflow status of a sales order header as represented by Oracle Workflow item activity states. Rather than reading a static order status column alone, the package resolves status conditions such as booked, closed, and cancelled against the underlying workflow process that drives the order's lifecycle. This makes it a supporting public utility for integrations, Oracle Application Object Library extensions, and internal Order Management components that need an authoritative answer to the question "in what workflow state is this order header?"

The package carries a PUB designation, meaning it is classified as a public API within the ETRM documentation model. As such it is considered a supported surface for external callers, in contrast to private or internal packages that Oracle may change without notice. In Oracle EBS 12.1.1 and 12.2.2 the package remains VALID, and its dependency footprint confirms that it is still referenced by active Order Management and Order Capture code paths in both releases.

Key Procedures and Functions

The ETRM metadata documents six procedures and functions in total. Three are named explicitly:

  • GET_BOOKED_STATUS — resolves whether a given order header is in a booked state by consulting the workflow status of the associated order header process. This is the status typically driven by the header-level booking activity in the Order Management workflow.
  • GET_CLOSED_STATUS — determines whether the order header workflow has reached a closed state, indicating that the order header process has completed its normal terminal activity.
  • GET_CANCELLED_STATUS — determines whether the order header has been cancelled within the workflow, corresponding to the cancellation path rather than the closing path. This distinction matters because cancelled and closed orders are not equivalent for downstream reporting and processing.

No parameter lists or return signatures are reproduced here; the documented facts are limited to procedure names and their stated purpose. All three follow the same design pattern: they accept an order header identifier, evaluate the relevant workflow activity and status records, and return a status indicator to the caller.

Tables Accessed

The documented tables, reached through APPS synonyms, are:

  • OE_ORDER_HEADERS_ALL — the primary sales order header table. The package uses the header record to identify the order and to correlate it with the workflow instance that governs its lifecycle.
  • WF_ITEM_ACTIVITY_STATUSES — the Oracle Workflow table holding the status of each activity within a running workflow item. This is the source of the booked, closed, and cancelled determinations, since workflow activity results, not header columns, encode those states.
  • WF_PROCESS_ACTIVITIES — the workflow process definition table, used to associate activities with their parent process so that the correct header-level status activities are evaluated.

The package is therefore read-only with respect to these tables; it derives status rather than maintaining it.

Usage Notes

OE_HEADER_STATUS_PUB is referenced by three other packages in the documented dependency set: ASO_ORDER_INT, ASO_ORDER_STATUS_PVT, and OE_WF_UPGRADE_UTIL. ASO_ORDER_INT and ASO_ORDER_STATUS_PVT are part of the Oracle Order Capture (ASO) integration and status layers, which rely on the header status evaluation when importing or reporting on orders. OE_WF_UPGRADE_UTIL uses it during workflow upgrade and maintenance processing.

Typical invocation points include Order Management forms and internal workflow function activities that must render or branch on header status, concurrent programs that report order state, and custom PL/SQL integrations that require a reliable booked/closed/cancelled determination without querying workflow tables directly. Because it is a public package, custom code may call it, but callers should expect only a status result and should not depend on undocumented internal procedures. Oracle may modify behavior between releases, so any custom integration should be regression-tested when applying 12.2.x patches or upgrades.