Search Results minority_group_lookup




Overview
Explore in AI Chat

Overview

APPS.OKX_EMPLOYEES_V is a reporting and integration view in Oracle E-Business Suite (EBS) Release 12.1.1 and 12.2.2 that exposes employee and person records from Oracle HRMS in a flattened, denormalized shape. It is owned by the APPS schema and is defined over the PER_ALL_PEOPLE_F date-tracked table. The view is designed to present a worker name, employee number, effective dates, and a derived status code in a format suited to downstream consumers such as Oracle Contracts, supplier or customer master integrations, and reporting tools that expect a simplified employee listing.

The view follows a common EBS pattern in which a base HRMS table is projected into a "key flex"-style interface with synthetic identifier columns (ID1, ID2), a NAME, a DESCRIPTION, and a set of descriptive attributes. Because it references PER_ALL_PEOPLE_F directly without filtering by person type, it includes all person records—employees, applicants, contingent workers, and other person types—rather than true employees only.

Underlying Base Objects

The documented base object for this view is PER_ALL_PEOPLE_F (referenced through a synonym). PER_ALL_PEOPLE_F is the date-tracked version of the HRMS person table, meaning each person may have multiple rows delimited by EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. The view projects these rows directly, so it inherits the multi-row-per-person behavior of the base table. No joins to PER_PERSON_TYPES, PER_ASSIGNMENTS_F, or lookup tables are present in the view definition, which is why several descriptive columns are returned as NULL rather than resolved values.

Key Columns

  • ID1 — Maps to PERSON_ID, the surrogate primary key of the person.
  • ID2 — A concatenation of EFFECTIVE_START_DATE and EFFECTIVE_END_DATE separated by "#", used as the composite date-tracked identifier.
  • NAME — Maps to FULL_NAME, the formatted person name.
  • DESCRIPTION — Always NULL; no source column is mapped.
  • EMPLOYEE_NUMBER — The HRMS employee number assigned to the person.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — Map to the effective start and end dates of the person record.
  • STATUS — Derived using nested DECODE/SIGN logic against SYSDATE; returns 'A' for active or 'I' for inactive based on whether the current date falls within the effective date range.
  • BUSINESS_GROUP_ID, PERSON_TYPE_ID — Foreign keys identifying the business group and person type.
  • LAST_NAME, FIRST_NAME — Individual name components.
  • START_DATE, EMAIL_ADDRESS, INTERNAL_LOCATION — Direct projections from the base table.
  • SMALL_BUSINESS_FLAG, WOMEN_OWNED_FLAG, MINORITY_GROUP_LOOKUP — All hard-coded to NULL in the view text. These columns exist only to satisfy a fixed column contract; no minority group, women-owned, or small business data is actually returned.

Common Use Cases and Queries

The most frequent use of OKX_EMPLOYEES_V is to supply a person or employee picker list within integrations and concurrent programs that expect the OKX-style column contract (ID1, ID2, NAME, STATUS). A typical query filters to currently active records:

  • SELECT id1, name, employee_number FROM apps.okx_employees_v WHERE status = 'A';
  • SELECT id1, id2, name, start_date_active, end_date_active FROM apps.okx_employees_v WHERE person_type_id = :p_type;
  • SELECT id1, employee_number, email_address, internal_location FROM apps.okx_employees_v WHERE employee_number = :p_number;

Because a person may have multiple effective-dated rows, queries intended to return one row per person should filter on SYSDATE between the effective dates or aggregate on ID1. Note that since MINORITY_GROUP_LOOKUP is hard-coded to NULL, any search or report expecting minority group classification from this view will return no value; the column exists for interface compatibility only, and the actual minority group attribute resides on the assignment or person type rather than on PER_ALL_PEOPLE_F.