Search Results get_closed_status




Overview
Explore in AI Chat

Overview

APPS.OE_HEADER_STATUS_PUB is a public PL/SQL package body in the Oracle Order Management module of Oracle E-Business Suite. Its business purpose is to expose order header status information to other Oracle EBS components and to custom code in a controlled, reusable manner. Specifically, the package answers status questions about a sales order header — whether it is booked, closed, or cancelled — without requiring callers to query the underlying Order Management tables directly. Encapsulating this logic in a published (PUB-classified) API allows the Order Management development team to centralize status derivation rules, exception handling, and messaging conventions, while giving external integrators a stable interface. The package is documented at 12.1.1 and 12.2.2 and is referenced by three other packages, confirming that it functions as a shared utility within the Order Management code stack. A global constant G_PKG_NAME holds the package name and is used when logging unexpected errors through OE_MSG_PUB.

Key Procedures and Functions

The ETRM metadata documents six procedures or functions in total, with three named public entry points:

  • GET_BOOKED_STATUS — Returns an indication of whether a given sales order header has reached the booked state. Callers use this to gate downstream fulfillment or financial processing logic without inspecting header workflow state directly.
  • GET_CLOSED_STATUS — Returns an indication of whether the order header is closed. Closure reflects completion or final disposition of the order in the Order Management lifecycle.
  • GET_CANCELLED_STATUS — Returns whether the order has been cancelled. This is the procedure relevant to the search term "get_cancelled_status". It is implemented in two overloaded forms. The first accepts a header identifier and returns a single flag value of 'Y' for cancelled or 'N' otherwise; it reads CANCELLED_FLAG from OE_ORDER_HEADERS_ALL. The second overload adds an output date parameter that carries the timestamp of the workflow activity that produced the cancellation, returning a null date when the order is not cancelled. Internally the date-aware version invokes the simpler overload and then queries workflow activity data.

All three entry points follow the same design pattern: a lightweight lookup combined with centralized exception handling that logs unexpected errors via OE_MSG_PUB when the message level permits.

Tables Accessed

The package operates against three documented tables, all accessed through APPS synonyms:

  • OE_ORDER_HEADERS_ALL — The primary source of truth for header-level status. GET_CANCELLED_STATUS reads the CANCELLED_FLAG column for the supplied header. Status procedures for booked and closed conditions similarly derive their results from header attributes.
  • WF_ITEM_ACTIVITY_STATUSES — Consulted by the date-aware overload of GET_CANCELLED_STATUS to retrieve the end date of the relevant workflow activity, giving callers the point in time at which the cancellation occurred.
  • WF_PROCESS_ACTIVITIES — Used in conjunction with WF_ITEM_ACTIVITY_STATUSES to resolve workflow activity metadata needed to interpret the header's order-management workflow state.

The package is read-only with respect to these tables; it does not insert, update, or delete order or workflow data.

Usage Notes

Because OE_HEADER_STATUS_PUB is classified as a public API, it is intended for invocation from Oracle Order Management forms, concurrent programs, workflow functions, and custom PL/SQL code that needs an authoritative status answer. Typical use cases include custom concurrent programs that must exclude cancelled or closed orders from processing, personalizations that conditionally display or hide form regions based on order state, and integration code that polls order status before transmitting data to external systems. Callers should prefer these packaged procedures over direct SQL against OE_ORDER_HEADERS_ALL so that they automatically inherit Oracle's status derivation logic and error handling. When invoking the date-aware overload, callers should test the returned result flag before relying on the accompanying date, since the date is null for non-cancelled orders. Unexpected failures are logged through OE_MSG_PUB and surfaced according to the session's message level; custom callers should therefore check message levels or capture exceptions in their own handlers when using the no-copy output parameters.