Results for “per_people_f”

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

Overview

PER_PEOPLE_F is one of the most heavily referenced objects in the Oracle E-Business Suite Human Resources (PER) schema and appears throughout EBS 12.1.1 and 12.2.2 as the canonical source of person, employee, and applicant records. Technically it is a secure view owned by the APPS schema and defined over the corresponding _ALL base table. The _F suffix denotes a date-tracked (datetracked) entity: every row carries an EFFECTIVE_START_DATE and EFFECTIVE_END_DATE, so a single person may appear in multiple rows across time. The view’s principal purpose is to enforce row-level security, restricting the visible person records according to the security profile of the querying user, while presenting the same logical columns as the underlying table.

Because HR security is implemented at the database layer, PER_PEOPLE_F is the object of choice for custom reports, concurrent programs, BI Publisher data models, interfaces, and integrations that need person data without bypassing the security model. Report developers query the view rather than PER_ALL_PEOPLE_F to ensure that users only see people within their authorized business group and security scope.

Underlying Base Objects

The ETRM metadata records that the view is defined over the synonym PER_ALL_PEOPLE_F, which in turn resolves to the actual base table. The view text also invokes three PL/SQL packages: HR_GENERAL, which supplies the derived WORK_TELEPHONE column through HR_GENERAL.GET_WORK_PHONE; HR_PERSON_NAME, used for name-related logic; and HR_SECURITY, which supplies the security predicate that qualifies which rows are returned. The _ALL table is the unrestricted, multi-business-group physical table; PER_PEOPLE_F is the secured projection of it. This layered design means that data volume, datetracking semantics, and most column definitions are inherited directly from the base table, while access control is added by the view definition.

Key Columns

• PERSON_ID — Primary key of the person record; the join key to assignments, contacts, and almost every other HR entity.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — Datetrack columns defining the validity period of the row.
• BUSINESS_GROUP_ID — Identifies the enterprise/business group to which the person belongs.
• EMPLOYEE_NUMBER and APPLICANT_NUMBER — Externally meaningful identifiers for employees and applicants.
• LAST_NAME, FIRST_NAME, MIDDLE_NAMES, FULL_NAME, KNOWN_AS, ORDER_NAME — Name attributes; FULL_NAME is the concatenated display form.
• CURRENT_EMPLOYEE_FLAG, CURRENT_APPLICANT_FLAG, CURRENT_EMP_OR_APL_FLAG — Status flags indicating whether the person is currently an employee, applicant, or either.
• PERSON_TYPE_ID — Foreign key to the person type (Employee, Applicant, Contingent Worker, and so on).
• DATE_OF_BIRTH, SEX, MARITAL_STATUS, NATIONALITY, NATIONAL_IDENTIFIER — Personal/demographic attributes.
• EMAIL_ADDRESS, WORK_TELEPHONE, EXPENSE_CHECK_SEND_TO_ADDRESS — Communication and payment-related attributes.
• ATTRIBUTE1–ATTRIBUTE30 and PER_INFORMATION1–PER_INFORMATION30 — Descriptive flexfield and extra-information segments.
• Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) and REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID for concurrent program auditing.

Common Use Cases and Queries

A frequent requirement is to list currently active employees with their key identifiers. Because the view is datetracked, the predicate on SYSDATE is essential:

SELECT person_id, employee_number, full_name, email_address
FROM   apps.per_people_f
WHERE  current_employee_flag = 'Y'
AND    TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date
AND    business_group_id = :p_business_group_id;

Applicant reporting follows the same pattern using CURRENT_APPLICANT_FLAG = 'Y'. Person-level joins to PER_ALL_ASSIGNMENTS_F link the person to position, organization, job, and pay records; joining on PERSON_ID with matching datetrack predicates keeps history consistent. Integration and interface programs typically extract rows from PER_PEOPLE_F for downstream feeds, relying on the view’s security to constrain the dataset to the operating business group. When a full, unrestricted extract is genuinely required, the underlying _ALL table is used instead, but this should be limited to privileged batch processes. Across all scenarios, developers should remember to filter on the datetrack columns, honor the security behavior, and avoid assuming that PERSON_ID alone returns a single row.