Search Results default_code_combination_id




Overview
Explore in AI Chat

Overview

ICX_PO_APPROVER_VAL_V is a database view owned by the APPS schema in Oracle E-Business Suite, documented under the ICX (Oracle iProcurement) product family. Its stated purpose in the ETRM repository is to serve as an Approver LOV View — the data source behind the List of Values (LOV) that allows a user to select an approver during iProcurement and purchasing document flows. The view exposes a compact, denormalized projection of employee and location attributes so that the LOV can present a human-readable approver name alongside the surrogate key needed by downstream approval and routing logic. It is marked VALID in ETRM for both 12.1.1 and 12.2.2, and no structural differences are recorded between those releases.

Underlying Base Objects

The view text defines a simple outer join between two HR views: HR_EMPLOYEES_CURRENT_V (aliased HRE) and HR_LOCATIONS (aliased HRL), joined on HRE.LOCATION_ID = HRL.LOCATION_ID(+). The (+) outer-join syntax confirms that employees without a matching location row are still returned, with null location attributes. ETRM also records the following referenced base objects, which are reached indirectly through the HR views: FND_PROFILE (PACKAGE), HR_GENERAL (PACKAGE), HR_PERSON_NAME (PACKAGE), and HR_SECURITY (PACKAGE). These are significant because HR_EMPLOYEES_CURRENT_V is a secured, date-effective view — HR_SECURITY applies the current security profile, HR_GENERAL and HR_PERSON_NAME supply date-effective and name-formatting logic, and FND_PROFILE reads site-level HR and ICX profile options. Consequently, ICX_PO_APPROVER_VAL_V returns only employees visible to the querying user's HR security profile, and only their currently effective record.

Key Columns

Common Use Cases and Queries

The principal use is populating an approver LOV in iProcurement requisition and purchase-order approval paths, and in custom OAF or Forms personalizations that need an approver picker consistent with the seeded behavior. It is also frequently joined to approval-history or workflow tables where an employee ID must be resolved to a display name.

Basic approver lookup by name:

SELECT employee_id, full_name, email_address, location_code
FROM apps.icx_po_approver_val_v
WHERE full_name LIKE :p_name || '%'
ORDER BY full_name;

Resolving an approver ID stored on a routing record:

SELECT a.employee_id, a.full_name, a.email_address
FROM apps.icx_po_approver_val_v a
WHERE a.employee_id = :p_employee_id;

Listing approvers within a business group or location, useful for validation extracts:

SELECT employee_id, full_name, organization_id, business_group_id
FROM apps.icx_po_approver_val_v
WHERE business_group_id = :p_bg_id
AND location_code = :p_location_code;

Because results are filtered by HR security and date-effectiveness, report queries executed under a restricted responsibility may return fewer rows than expected; this behavior originates in HR_EMPLOYEES_CURRENT_V and should be accounted for in reconciliation and integration testing.