Results for “per_people_v”

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

Overview

PER_PEOPLE_V is a seeded, valid database view owned by the APPS schema in the Oracle E-Business Suite, belonging to the PER (Human Resources) product family. It is documented in ETRM as being "used to support user interface." Rather than representing a single flat application table, the view consolidates person-level attributes and translates them into a form suitable for Oracle Forms-based HRMS windows, self-service pages, and concurrent/reporting integrations. In EBS 12.1.1 and 12.2.2, PER_PEOPLE_V frequently appears in Flexfields and value-set definitions, LOV (List of Values) queries, and ad hoc reporting because it exposes employee, applicant, and contingent worker records through a single logical interface.

The view is not the base table for person data; it is a presentation layer. All DML against people should be routed through the PER_PEOPLE_F table and the HR_API package, never directly against this view. As a read-oriented object, it reflects the current effective-dated row filtered appropriately for UI display.

Underlying Base Objects

The view text selects primarily from PER_PEOPLE_F (referenced as the synonym PER), joined conceptually to the business group, person type, and periods of service/placement structures. ETRM lists the following documented base objects for the 12.2.2 metadata:

• PER_PEOPLE_F – the effective-dated core person table supplying most selected columns.
• PER_PERSON_TYPES and PER_PERSON_TYPES_TL – person type definitions and their translated names.
• PER_PERIODS_OF_SERVICE and PER_PERIODS_OF_PLACEMENT – assignment of a person to an organization and placement in a business group.
• HR_LOOKUPS, FND_LANGUAGES_VL, FND_TERRITORIES_VL – code translations for lookup values and language/territory display.
• HR_GENERAL, HR_API, HR_PERSON_NAME, HR_PERSON_TYPE_USAGE_INFO, HR_SECURITY – PL/SQL packages supplying derived values, name formatting, and security predicates.
• FND_SESSIONS and BEN_BENFTS_GRP – session context and benefits group references.

Notably, the WORK_TELEPHONE column is derived by calling HR_GENERAL.GET_WORK_PHONE(PER.PERSON_ID) rather than being stored on the base table, and other name/date values are similarly returned via HR_PERSON_NAME and related APIs.

Key Columns

The view exposes a broad set of person attributes. The most commonly referenced include:

• PERSON_ID – the primary surrogate key identifying the person.
• BUSINESS_GROUP_ID – the HR business group that owns the record.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE – the effective-dating columns inherited from PER_PEOPLE_F; the UI typically surfaces the row effective as of the current date.
• EMPLOYEE_NUMBER and APPLICANT_NUMBER – externally visible identifiers.
• FIRST_NAME, LAST_NAME, MIDDLE_NAMES, FULL_NAME, ORDER_NAME, KNOWN_AS, PREVIOUS_LAST_NAME, SUFFIX, TITLE – name attribute components.
• CURRENT_EMPLOYEE_FLAG, CURRENT_APPLICANT_FLAG, CURRENT_EMP_OR_APL_FLAG – status indicators distinguishing employees from applicants.
• PERSON_TYPE_ID – foreign key to PER_PERSON_TYPES.
• START_DATE, DATE_OF_BIRTH, DATE_OF_DEATH, SEX, MARITAL_STATUS, NATIONALITY, EMAIL_ADDRESS, REGISTERED_DISABLED_FLAG.
• WORK_TELEPHONE – derived work phone number.
• ATTRIBUTE1 through ATTRIBUTE30 and PER_INFORMATION1 through PER_INFORMATION13 – descriptive flexfield and person information flexfield segments.
• Standard WHO columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, plus PROGRAM_APPLICATION_ID, PROGRAM_ID, REQUEST_ID, PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

Typical uses include LOV definitions, headcount-style reports, data extraction for interfaces, and validation queries in PL/SQL procedures. A basic retrieval of active employees in a business group:

SELECT person_id, employee_number, full_name,
       email_address, work_telephone
FROM   apps.per_people_v
WHERE  business_group_id = :p_business_group_id
AND    current_employee_flag = 'Y';

Filtering by person type and name fragment for a search page:

SELECT person_id, employee_number, full_name
FROM   apps.per_people_v
WHERE  upper(full_name) LIKE upper(:p_name) || '%';

Because of HR_SECURITY predicates embedded through the supporting packages, results are expected to respect the secure access model. Direct DML against PER_PEOPLE_V is not supported; insertions, updates, and terminations must flow through HR_API and the underlying base tables to preserve datetrack integrity and audit columns.