Results for “per_people”

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

Overview

PER_PEOPLE is a date-effective (key flexfield-enabled) view owned by the APPS schema within the PER – Human Resources product family of Oracle E-Business Suite 12.1.1 and 12.2.2. Unlike a conventional relational view that maps directly to a single underlying table, PER_PEOPLE is a "date-effective" view: it presents person records already filtered to the currently effective row for each person, applying the business group's date-tracked logic so that reports and integrations receive a single, clean snapshot of every person rather than a full history of dated versions. The view exposes employee and applicant master data—names, numbers, dates of birth, national identifiers, contact details, marital status, sex, and descriptive flexfield segments—and is the primary integration point through which external systems, OBIEE/XML Publisher reports, and custom concurrent programs read person information. Because it resolves the effective dating and security filtering on behalf of the caller, PER_PEOPLE is generally the preferred access path over the underlying PER_ALL_PEOPLE_F table for read-only reporting.

Underlying Base Objects

According to the documented ETRM 12.2.2 metadata, PER_PEOPLE is defined over the following referenced base objects: PER_PEOPLE_F (VIEW), FND_SESSIONS (SYNONYM), and the HR_GENERAL, HR_PERSON_NAME, HR_PERSON_TYPE_USAGE_INFO, and HR_SECURITY packages. The core data originates from PER_PEOPLE_F, the date-tracked ("_F") datetrack view of the person entity. Rather than selecting rows directly, PER_PEOPLE invokes PL/SQL functions from HR_GENERAL to resolve the effective date (typically from FND_SESSIONS, which holds session context such as the effective date and business group), HR_PERSON_NAME to assemble the person's name components, HR_PERSON_TYPE_USAGE_INFO to determine current person type (employee, applicant, etc.), and HR_SECURITY to apply row-level security so that a user only sees persons they are authorized to access. This layered design is why the view is described as date-effective and is central to how Oracle HRMS enforces both temporal and security semantics.

Key Columns

The view exposes a broad set of columns, grouped as follows:

• Identity & keys: PERSON_ID, BUSINESS_GROUP_ID, PERSON_TYPE_ID, APPLICANT_NUMBER, EMPLOYEE_NUMBER, and the surrogate OBJECT_VERSION_NUMBER.
• Effective dating: EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, and START_DATE, reflecting the datetrack context.
• Name & personal attributes: LAST_NAME, FIRST_NAME, MIDDLE_NAMES, FULL_NAME, ORDER_NAME, KNOWN_AS, PREVIOUS_LAST_NAME, SUFFIX, TITLE, SEX, DATE_OF_BIRTH, MARITAL_STATUS, NATIONALITY, NATIONAL_IDENTIFIER, and REGISTERED_DISABLED_FLAG.
• Status flags: CURRENT_APPLICANT_FLAG, CURRENT_EMPLOYEE_FLAG, and CURRENT_EMP_OR_APL_FLAG, which indicate the person's current classification.
• Contact & work details: EMAIL_ADDRESS, WORK_TELEPHONE, WORK_SCHEDULE, FTE_CAPACITY, CORRESPONDENCE_LANGUAGE, and VENDOR_ID.
• Descriptive flexfields: PER_INFORMATION_CATEGORY and PER_INFORMATION1 through PER_INFORMATION30, plus the standard ATTRIBUTE_CATEGORY and ATTRIBUTE1–30.
• Audit columns: REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE.

Common Use Cases and Queries

PER_PEOPLE is frequently used for employee/applicant extracts, headcount reporting, and lookups that must return one current row per person. A typical query filters on the business group and current-employee flag:

• Active employee listing: SELECT person_id, employee_number, full_name, email_address FROM apps.per_people WHERE business_group_id = :p_bg_id AND current_employee_flag = 'Y';
• Applicant lookup by number: SELECT person_id, applicant_number, full_name FROM apps.per_people WHERE applicant_number = :p_num;
• Point-in-time report: SELECT person_id, full_name, effective_start_date FROM apps.per_people WHERE sysdate BETWEEN effective_start_date AND effective_end_date;
• Flexfield extract: SELECT person_id, full_name, per_information_category, per_information1 FROM apps.per_people WHERE current_employee_flag = 'Y';

Because security and effective dating are resolved internally, these queries inherit the session's HR security profile and effective date automatically, reducing the need to join PER_ALL_PEOPLE_F or apply manual datetrack predicates.