Search Results displayed_hold_code

Overview

AP_HOLD_CODES_V is a Payables (AP) view owned by the APPS schema. It presents a denormalized, reporting-friendly projection of the hold codes defined for the Oracle Payables application, joining the hold code definition to its associated lookup descriptions. The view exposes a single row per hold code, combining the hold code identifier, hold type, and the display text resolved from the AP lookup tables, along with the operational control flags that govern how each hold behaves. Note that the source documentation labels this object as "(Release 10SC Only)", indicating that the view originated in early Payables releases; however, the object remains VALID in the 12.1.1 and 12.2.2 environments, where it continues to be used by forms, concurrent programs, and custom reporting.

In EBS reporting and integration, the view serves as a read-only reference for hold configuration. Rather than querying the base hold code table and manually resolving lookup meanings, developers and report writers can select from AP_HOLD_CODES_V to obtain user-facing hold code and hold type descriptions in a single pass. This is particularly relevant to the searched column, USER_UPDATEABLE_FLAG, which is exposed directly by the view.

Underlying Base Objects

The documented metadata identifies three referenced base objects:

• AP_HOLD_CODES (SYNONYM) — the primary source of hold code rows, supplying the hold lookup code, hold type, control flags, and audit columns.
• AP_LOOKUP_CODES (VIEW) — joined twice, aliased L1 and L2, to resolve the displayed hold code name (LOOKUP_TYPE = 'HOLD CODE') and the displayed hold type name (LOOKUP_TYPE = 'HOLD TYPE').
• FND_GLOBAL (PACKAGE) — the standard EBS global context package referenced by the view definition for session and responsibility context.

The view text defines an inner-join relationship: AP_HOLD_CODES is joined to AP_LOOKUP_CODES on HOLD_LOOKUP_CODE = LOOKUP_CODE (restricted to lookup type 'HOLD CODE') and again on HOLD_TYPE = LOOKUP_CODE (restricted to lookup type 'HOLD TYPE'). Because these are inner joins, hold codes lacking a matching lookup entry are excluded from the result set.

Key Columns

• ROW_ID — the row identifier derived from the base table ROWID.
• HOLD_LOOKUP_CODE / DISPLAYED_HOLD_CODE — the internal hold code and its user-facing description.
• HOLD_TYPE / DISPLAYED_HOLD_TYPE — the internal hold type classification and its translated display value.
• USER_UPDATEABLE_FLAG — indicates whether the hold may be updated by a user. This is the searched column and is central to controlling whether a hold can be manually modified.
• USER_RELEASEABLE_FLAG — indicates whether a user may release the hold.
• POSTABLE_FLAG — controls whether invoices subject to the hold remain postable.
• INACTIVE_DATE — the date on which the hold code was deactivated.
• HOLD_INSTRUCTION — free-text instruction presented to users.
• WAIT_BEFORE_NOTIFY_DAYS / REMINDER_DAYS — notification timing controls (note the column is aliased REMAINDER_DAYS in the view text).
• INITIATE_WORKFLOW_FLAG — governs workflow initiation for the hold.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical scenarios include validating hold configuration during setup, building custom hold inquiry forms, and reporting on which holds permit user updates or releases.

Listing active user-updateable hold codes:

• SELECT HOLD_LOOKUP_CODE, DISPLAYED_HOLD_CODE, HOLD_TYPE, DISPLAYED_HOLD_TYPE FROM APPS.AP_HOLD_CODES_V WHERE USER_UPDATEABLE_FLAG = 'Y' AND INACTIVE_DATE IS NULL;

Retrieving release and posting behavior for a specific hold:

• SELECT HOLD_LOOKUP_CODE, USER_RELEASEABLE_FLAG, POSTABLE_FLAG, HOLD_INSTRUCTION FROM APPS.AP_HOLD_CODES_V WHERE HOLD_LOOKUP_CODE = :hold_code;

Reporting all hold types with workflow initiation enabled:

• SELECT DISPLAYED_HOLD_TYPE, HOLD_LOOKUP_CODE, INITIATE_WORKFLOW_FLAG FROM APPS.AP_HOLD_CODES_V WHERE INITIATE_WORKFLOW_FLAG = 'Y';

Where applications require translated or responsibility-specific display text, joins to FND lookups should respect the FND_GLOBAL context exposed by the view's base objects.