Search Results p_hold_name

Overview

OE_HOLDS is a public PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It exposes the Order Management hold management API, HOLDS_API, which is the single entry point used by Oracle Order Management and external callers to apply, release, and otherwise manage holds on sales order entities. The package is classified as OTHER in the ETRM repository, meaning it is not a standard interface or concurrent-program API in the conventional sense; rather, it is a low-level utility wrapper that other Order Management components and custom extensions invoke to manipulate hold records directly.

The package is declared with AUTHID CURRENT_USER, so executing privileges and schema resolution are determined by the calling user rather than by the APPS owner. Callers must therefore hold the necessary privileges on the underlying Order Management tables and must invoke the package in a context where APPS synonyms resolve correctly, typically from within an APPS-privileged session or a custom schema granted execute on OE_HOLDS.

Key Procedures and Functions

The ETRM metadata documents one callable member: HOLDS_API. It is a function returning a NUMBER, which conventionally signals success or failure and returns diagnostic text through an OUT parameter. Its documented parameter surface includes:

• V_ACTION — the operation to perform (for example apply or release), driving the branch logic inside the function.
• V_HOLD_ID — identifier of the hold definition being applied or removed.
• V_ENTITY_CODE and V_ENTITY_ID — the entity type and primary key of the object the hold is attached to (header, line, or other order entity).
• V_REASON_CODE — the reason code recorded against the hold instance. This is the parameter most frequently searched for as v_reason_code.
• V_COMMENT — free-text comment stored with the hold instance.
• V_MSG_TEXT — OUT parameter returning the API message, including error text when the return value indicates failure.
• V_LINE_ID and V_HEADER_ID — optional context identifiers for line-level and header-level hold operations.
• P_HOLD_NAME, P_ORDER_NUMBER, P_ORDER_TYPE — optional descriptive context used during processing and messaging.
• P_APPLICATION_ID, P_RESPONSIBILITY_ID, P_CUSTOMER_ID, P_SITE_USE_ID — optional organizational and party context passed to the API.

The function encapsulates validation, hold application or release logic, and message construction, returning a status number to the caller rather than raising unhandled exceptions.

Tables Accessed

The ETRM excerpt does not enumerate the underlying tables accessed by OE_HOLDS, and no APPS synonyms are documented for this package. Functionally, the API operates against the Order Management hold tables — the hold definitions table (OE_HOLD_DEFINITIONS) and the hold instance table (OE_ORDER_HOLDS) — together with the order headers and lines tables (OE_ORDER_HEADERS_ALL and OE_ORDER_LINES_ALL) needed to resolve the entity identified by V_ENTITY_CODE and V_ENTITY_ID. Because table access is not documented in the provided metadata, integrators should confirm actual dependencies through the package body source or the database dependency views before relying on any specific table list.

Usage Notes

OE_HOLDS is typically invoked indirectly. Standard Order Management forms, order import, and workflow activities call the hold API to apply and release holds during order entry, booking, and fulfillment. Custom code most commonly calls it when implementing automated hold placement or release — for example, applying a credit or configuration hold from an external process, or releasing holds in bulk. When writing such code, pass a valid V_REASON_CODE and V_HOLD_ID, capture the numeric return value, and inspect V_MSG_TEXT on failure. The metadata records that this package is referenced by zero other packages, confirming that it sits at the edge of the dependency graph and is intended to be called rather than to call sibling APIs. Because the header comment dates to release 11.5.x and the API classification is OTHER, the interface should be treated as stable but lightly governed; regression-test any custom usage after applying Order Management patches.