Results for “held_by_user_name”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AP_HOLDS_OVERVIEW_V is a reporting view owned by the APPS schema in Oracle E-Business Suite Payables. It presents a consolidated, denormalized picture of invoice holds by joining the AP_HOLDS transaction table to hold-code definitions, invoice headers, user accounts, and purchasing line locations. The view is documented in ETRM as Release 10SC only, and its metadata remains catalogued in 12.1.1 and 12.2.2 even though the object is a legacy reporting construct. Its central purpose is to translate coded hold values into human-readable descriptions, so that reports and integrations can display who placed a hold, what type of hold it is, and which invoice or purchase-order line it affects without requiring the caller to perform multiple lookup joins.

The presence of the HELD_BY column explains why this view surfaces in searches for "held_by." HELD_BY stores the FND_USER.USER_ID of the user who applied the hold, and the view enriches it with the corresponding USER_NAME through an outer join to FND_USER.

Underlying Base Objects

ETRM documentation for 12.2.2 lists the referenced base objects as AP_HOLDS, AP_HOLD_CODES, AP_INVOICES_ALL, AP_LOOKUP_CODES, FND_GLOBAL, FND_USER, and PO_LINE_LOCATIONS_ALL. The view text confirms these relationships:

• AP_HOLDS (aliased AH) is the driving table, supplying the hold row identifier, descriptive flexfield attributes, HELD_BY, HOLD_DATE, HOLD_LOOKUP_CODE, HOLD_REASON, INVOICE_ID, RELEASE_LOOKUP_CODE, RELEASE_REASON, STATUS_FLAG, RESPONSIBILITY_ID, and ORG_ID.
• AP_HOLD_CODES (AHC) is joined on HOLD_LOOKUP_CODE and supplies the HOLD_TYPE used to resolve the hold type description.
• AP_LOOKUP_CODES (ALC1 and ALC2) is joined twice: ALC1 resolves the 'HOLD CODE' lookup to produce HOLD_NAME, and ALC2 resolves the 'HOLD TYPE' lookup to produce HOLD_TYPE.
• AP_INVOICES_ALL (AI) is joined on INVOICE_ID to expose INVOICE_NUM.
• FND_USER (FU) is outer-joined on AH.HELD_BY = FU.USER_ID to derive HELD_BY_USER_NAME.
• PO_LINE_LOCATIONS_ALL (PLL) is outer-joined on LINE_LOCATION_ID and contributes PO_HEADER_ID, PO_LINE_ID, and QUANTITY.
• FND_GLOBAL is catalogued as a referenced object, consistent with the ORG_ID and RESPONSIBILITY_ID context populated by the AP_HOLDS base table.

A defining filter, AH.RELEASE_REASON IS NULL, restricts output to holds that have not been released, so the view represents currently active holds.

Key Columns

• ROW_ID — the ROWID of the underlying AP_HOLDS row, used as a unique identifier.
• HELD_BY — the user ID of the person who placed the hold; the source of the "held_by" search.
• HELD_BY_USER_NAME — the FND_USER.USER_NAME resolved from HELD_BY via outer join.
• HOLD_LOOKUP_CODE / HOLD_NAME — the hold code and its displayed description.
• HOLD_TYPE — the displayed hold type derived from AP_HOLD_CODES and the 'HOLD TYPE' lookup.
• HOLD_DATE, HOLD_REASON — when and why the hold was applied.
• INVOICE_ID, INVOICE_NUM — the held invoice.
• STATUS_FLAG — the hold status indicator.
• PO_HEADER_ID, PO_LINE_ID, QUANTITY — purchase-order context where the hold is line-location based.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — descriptive flexfield context and segments carried from AP_HOLDS.

Common Use Cases and Queries

The view is typically consumed by custom reports, extracts, and integration interfaces that need readable hold information. A frequent pattern is to filter or group by the user who placed holds:

• Listing all active holds with the placing user and invoice.
• Aggregating hold counts by HELD_BY_USER_NAME or HOLD_TYPE for workload analysis.
• Joining to AP_INVOICES_ALL for supplier and amount context.

Sample query:

SELECT held_by, held_by_user_name, invoice_num, hold_name, hold_type, hold_date, hold_reason FROM apps.ap_holds_overview_v WHERE held_by = :user_id ORDER BY hold_date DESC;

Because the view pre-filters released holds, consumers should query AP_HOLDS directly when release history is required.