Search Results icx_req_override_requestor_code

Overview

APPS.ICX_PO_REQUESTOR_VAL_V is an Oracle E-Business Suite validation view that resolves the set of users permitted to act as requestors on purchasing documents within the Internet Procurement (iProcurement) and Purchasing modules. Its name reflects its function: a validation (VAL) view scoped to Internet Commerce eXchange (ICX) purchasing requestor data. The view is not a simple denormalized join; it embeds a profile-driven filtering rule that evaluates the ICX_REQ_OVERRIDE_REQUESTOR_CODE system profile option to determine which rows are returned for each web user.

The profile option ICX_REQ_OVERRIDE_REQUESTOR_CODE controls whether a user may raise requisitions on behalf of employees other than themselves. Three values are recognized: NO restricts visibility so a user sees only their own employee record, ORG allows a user to act on behalf of any employee within the same organization, and ALL permits acting on behalf of any employee. Because this logic is encapsulated in the view definition, any concurrent program, Oracle Forms call, OA Framework page, or integration that queries ICX_PO_REQUESTOR_VAL_V automatically inherits the correct security posture without reimplementing the rule.

The object is owned by APPS and is referenced by ETRM metadata as a view within the 12.1.1 and 12.2.2 code lines.

Underlying Base Objects

The view is defined over the following documented base objects:

• HR_EMPLOYEES_CURRENT_V — the current-employee view, aliased twice (HRE for the requestor candidate row, HRE2 for the validated, logged-in user's employee record).
• HR_LOCATIONS — supplies location code and, where present, an inventory organization for the employee's location.
• FND_USER — the EBS application user account, joined to the employee record.
• ICX_USER_PROFILES — the iProcurement user-profile table, linked by WEB_USER_ID.
• FINANCIALS_SYSTEM_PARAMETERS — supplies the default inventory organization when the location does not provide one.
• FND_PROFILE (package) — invoked through FND_PROFILE.VALUE_WNPS to read the ICX_REQ_OVERRIDE_REQUESTOR_CODE setting at runtime.

The presence of HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY in the referenced-object list is attributable to the underlying HR_EMPLOYEES_CURRENT_V and HR_LOCATIONS views, which are secured by HR security profiles and rely on these packages for name and datetrack handling.

Key Columns

• USER_ID — the FND_USER identifier of the web user who can act as requestor.
• FULL_NAME, EMAIL_ADDRESS — display attributes resolved through HR person-name logic.
• EMPLOYEE_ID, EMPLOYEE_NUM — the employee identity used by Purchasing to attribute the requisition.
• DEFAULT_CODE_COMBINATION_ID — the employee's default charge account, used to default distribution accounting.
• LOCATION_ID, LOCATION_CODE — the employee's HR location and its short code.
• ORGANIZATION_ID, BUSINESS_GROUP_ID — the HR organization and business group; ORGANIZATION_ID is the pivot for the ORG-level override rule.
• EXPENSE_CHECK_ADDRESS_FLAG — controls whether the expense check address applies.
• LOCATION_ORGANIZATION_ID — NVL of the location's inventory organization and the Financials system parameter default, providing the receiving/inventory context for delivery defaults.

Common Use Cases and Queries

The primary use case is requestor validation and LOV population. The view is queried so that only legitimate requestor records appear in the requestor field, and so that the profile option governs scope. A typical lookup by employee name is:

• SELECT user_id, full_name, employee_id, organization_id FROM apps.icx_po_requestor_val_v WHERE UPPER(full_name) LIKE UPPER(:p_name)||'%';
• SELECT user_id, employee_id, location_organization_id FROM apps.icx_po_requestor_val_v WHERE employee_num = :p_emp_num;
• SELECT COUNT(*) FROM apps.icx_po_requestor_val_v WHERE user_id = FND_GLOBAL.USER_ID;

The third query is a diagnostic: it reveals whether the currently connected user can act as a requestor for themselves given the present ICX_REQ_OVERRIDE_REQUESTOR_CODE value. Because the profile is read with VALUE_WNPS, results change with the effective profile hierarchy (site, application, responsibility, user), so testing should account for the responsibility under which the session runs. Troubleshooting typical failures — an empty LOV, a missing employee number, or a default inventory organization not defaulting — generally traces to mismatched employee-to-user linkage (HRE2.EMPLOYEE_ID = FND_USER.EMPLOYEE_ID) or to an inappropriate profile value. Integration and reporting consumers should treat the view as read-only and avoid adding predicates that bypass the embedded security rule.