Search Results applied_by

Overview

The APPS.OE_HOLDS_HISTORY_V view is a reporting and integration object within the Oracle Order Management (ONT) module. Its role is to consolidate the complete lifecycle of order holds into a single queryable structure, exposing both the placement and the release of holds against order headers and lines. Because the underlying transactional objects — holds applied to orders, hold source definitions, and hold releases — are stored across several normalized tables, this view assembles them and resolves descriptive attributes such as user names and lookup meanings. The view is marked VALID in the ETRM metadata for EBS 12.1.1 and 12.2.2, making it a supported reference point for custom reports, inbound/outbound interfaces, and operational dashboards that require hold history without joining the base tables manually.

Underlying Base Objects

The documented base objects referenced by the view are OE_ORDER_HOLDS_ALL, OE_HOLD_SOURCES, OE_HOLD_RELEASES, OE_HOLD_DEFINITIONS, FND_USER, FND_LOOKUP_VALUES, and the PL/SQL packages OE_HOLDS_PVT and FND_GLOBAL. All are accessed through APPS synonyms, with the exception of the two packages. OE_ORDER_HOLDS_ALL supplies the applied-hold rows and is the anchor table. OE_HOLD_SOURCES provides the hold source record, which links to OE_HOLD_DEFINITIONS for the hold name. OE_HOLD_RELEASES is joined with an outer join operator (+), so holds that have not yet been released are still returned with null release attributes. FND_USER resolves creator and updater identifiers to user names, while FND_LOOKUP_VALUES supplies the meaning of hold entity codes for both the primary and secondary entity columns. OE_HOLDS_PVT is called directly through its ENTITY_ID_VALUE and USER_NAME functions to translate entity identifiers and user IDs at query time. FND_GLOBAL is referenced via USERENV and LOOKUP_SECURITY_GROUP to apply language and security-group filtering on the lookups.

Key Columns

The view exposes identifiers such as HEADER_ID, LINE_ID, HOLD_SOURCE_ID, HOLD_ID, HOLD_ENTITY_ID, and HOLD_RELEASE_ID, along with audit columns CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN inherited from the hold source record. HELD_BY is derived from FU.USER_NAME. Hold semantics are carried by HOLD_ENTITY_CODE and its lookup MEANING, the computed HOLD_ENTITY_ID_VALUE, HOLD_UNTIL_DATE, RELEASED_FLAG, and HOLD_COMMENT. A secondary hold entity pair (HOLD_ENTITY_CODE2, HOLD_ENTITY_ID2, and its meaning and computed value) supports holds scoped to two entities. Release data is provided by RELEASED_DATE, RELEASED_BY, RELEASE_REASON_CODE, and RELEASE_COMMENT. Notably, APPLIED_DATE is not a stored column in the base hold table; the view aliases OH.CREATION_DATE as APPLIED_DATE, which is the column users typically search for when tracking when a hold was placed. APPLIED_BY is similarly computed through OE_HOLDS_PVT.USER_NAME(OH.CREATED_BY).

Common Use Cases and Queries

Typical uses include auditing hold activity by order or line, reporting outstanding versus released holds, and feeding downstream systems with hold history. A basic query to retrieve applied hold history for a header is:

• SELECT header_id, line_id, name, applied_date, applied_by, released_date, released_by FROM oe_holds_history_v WHERE header_id = :p_header_id ORDER BY applied_date DESC;
• SELECT name, hold_comment, hold_until_date FROM oe_holds_history_v WHERE released_flag = 'N';
• SELECT header_id, applied_by, COUNT(*) FROM oe_holds_history_v WHERE applied_date >= :p_start_date GROUP BY header_id, applied_by;

Because APPLIED_DATE is an alias for the hold row creation date, filtering on it is valid and supported. Queries should filter by ORG_ID where multi-organization security is enforced, and should account for the outer join to OE_HOLD_RELEASES, which yields null release columns for holds still in effect.