Search Results default_code_combination_id




Overview
Explore in AI Chat

Overview

The APPS.ICX_PO_APPROVER_VAL_V view is an Oracle E-Business Suite database object residing in the APPS schema. It is classified as a VIEW with a status of VALID, and its FND Design Data reference is ICX.ICX_PO_APPROVER_VAL_V. Within Oracle EBS 12.1.1 and 12.2.2, this view serves as a validation and lookup source for Purchasing approver selection and related self-service workflows, exposing employee identity, contact, location, and accounting flexfield context in a single flattened row per approver.

The object carries an explicit Oracle Internal Use Only warning, indicating that Oracle Corporation does not support direct access to applications data through this view except from standard Oracle Applications programs. Consequently, the view is intended primarily for internal use by Oracle EBS application code, particularly within the ICX (Oracle iProcurement / self-service) module. Organizations may query it for reporting, but should recognize that it is not a formally supported public interface and that its definition may change across releases or patches. The view is not referenced by any other database object, confirming its role as a terminal validation source rather than an intermediate dependency.

Underlying Base Objects

The ETRM documentation records that ICX_PO_APPROVER_VAL_V is defined over the following objects:

  • HR_EMPLOYEES_CURRENT_V (VIEW) — supplies current employee assignment and organizational data.
  • HR_LOCATIONS (VIEW) — provides location identifiers and location codes.
  • FND_PROFILE (PACKAGE) — used for profile option lookups, likely to derive business group and security context.
  • HR_GENERAL (PACKAGE) — provides HR utility functions such as business group resolution.
  • HR_PERSON_NAME (PACKAGE) — formats and returns the employee's full name.
  • HR_SECURITY (PACKAGE) — enforces HR security, restricting returned rows based on the user's security profile.

This composition means the view is fundamentally an HR-derived employee directory scoped by HR security, augmented with profile-based business group context. It does not reference purchasing tables directly; instead it validates approvers by supplying the employee attributes the Purchasing module requires when building approver lists or routing documents.

Key Columns

The view exposes ten documented columns:

  • FULL_NAME (VARCHAR2, 240) — the formatted employee name from HR_PERSON_NAME.
  • EMAIL_ADDRESS (VARCHAR2, 240) — the employee's electronic mail address, used for notification.
  • EMPLOYEE_NUM (VARCHAR2, 30) — the HR employee number.
  • EMPLOYEE_ID (NUMBER, 10) — the unique HR employee identifier.
  • DEFAULT_CODE_COMBINATION_ID (NUMBER, 15) — the default accounting flexfield combination associated with the employee, relevant to charge account defaults on purchasing documents.
  • LOCATION_ID (NUMBER, 15) — the HR location identifier.
  • LOCATION_CODE (VARCHAR2, 60) — the human-readable location code.
  • ORGANIZATION_ID (NUMBER, 15) — the organization identifier for the approver's assignment.
  • BUSINESS_GROUP_ID (NUMBER, 15) — the business group that owns the employee record.
  • EXPENSE_CHECK_ADDRESS_FLAG (VARCHAR2, 30) — a flag indicating whether the location address is used for expense check delivery.

Common Use Cases and Queries

Typical use cases include validating that a proposed approver exists and is visible under HR security, retrieving an approver's default code combination for charge account defaulting, and populating notification email addresses. A representative query is:

  • SELECT full_name, email_address, employee_num, default_code_combination_id FROM apps.icx_po_approver_val_v WHERE employee_id = :p_employee_id;
  • SELECT employee_id, full_name, organization_id FROM apps.icx_po_approver_val_v WHERE business_group_id = :p_bg_id ORDER BY full_name;
  • SELECT full_name, location_code, expense_check_address_flag FROM apps.icx_po_approver_val_v WHERE location_id = :p_location_id;

Because the view is built on HR security, results are automatically filtered by the querying user's security profile, which must be considered when using it in custom reports or integration extracts.