Results for “per_information30”

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

Overview

PER_PEOPLE_X is a date-effective (datetrack) view owned by the APPS schema in Oracle E-Business Suite, delivered with the PER – Human Resources product. It exposes person records across the full spectrum of person types managed by Oracle HRMS, including employees, applicants, contacts, and other party classifications. Its defining characteristic is that it presents the complete temporal history of each person row: each logical person may appear multiple times, once per valid effective date range, rather than as a single consolidated record. Consequently, PER_PEOPLE_X is not a simple flattened person directory but a time-aware projection of the underlying date-tracked person data model.

The view is a standard reporting and integration artifact. Because it carries effective start and end dates alongside business group context, it is used by concurrent programs, BI Publisher reports, OAF pages, interfaces, and third-party integrations that must respect date-effective person attributes. The presence of the global_person_id search term in this context reflects the common need to join person records to the global (cross-business-group) person identifier maintained elsewhere in the HRMS data model. Note that GLOBAL_PERSON_ID is not among the columns listed in the documented view text; where a global person identifier is required, it must be sourced from the related global person tables and joined on PERSON_ID, or obtained through the HR_GENERAL package.

Underlying Base Objects

According to ETRM metadata for 12.2.2, PER_PEOPLE_X is defined over the following referenced base objects:

• PER_PEOPLE_F (VIEW) – the primary date-effective person entity supplying the core person columns and datetrack dates.
• HR_GENERAL (PACKAGE) – provides general HRMS utility functions used for derived or secured attribute resolution.
• HR_PERSON_NAME (PACKAGE) – resolves formatted and structured name information such as FULL_NAME, KNOWN_AS, and title handling.
• HR_SECURITY (PACKAGE) – enforces security profile restrictions, ensuring only persons visible to the querying responsibility are returned.

Because HR_SECURITY participates in the definition, query performance and result sets are directly affected by the security profile assigned to the session. The view therefore acts as a secured, name-resolved, date-effective projection of PER_PEOPLE_F rather than a raw table passthrough.

Key Columns

• PERSON_ID – primary identifier for the person; the principal join key to other HRMS objects.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE – the datetrack range defining the validity of each row.
• BUSINESS_GROUP_ID – the business group under which the person record is defined.
• PERSON_TYPE_ID – classification of the person (employee, applicant, contact, etc.).
• EMPLOYEE_NUMBER / APPLICANT_NUMBER – business-facing identifiers, populated by person type.
• CURRENT_EMPLOYEE_FLAG, CURRENT_APPLICANT_FLAG, CURRENT_EMP_OR_APL_FLAG – status flags indicating current classification.
• FULL_NAME, LAST_NAME, FIRST_NAME, KNOWN_AS, SUFFIX, TITLE, PREVIOUS_LAST_NAME – name attributes resolved via HR_PERSON_NAME.
• START_DATE, DATE_OF_BIRTH, SEX, MARITAL_STATUS, NATIONALITY, NATIONAL_IDENTIFIER – core personal attributes.
• EMAIL_ADDRESS, WORK_TELEPHONE – contact attributes.
• ATTRIBUTE1–30 and PER_INFORMATION1–30 – descriptive flexfield and developer extensibility columns.
• OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, CREATED_BY – concurrency and audit columns.

Common Use Cases and Queries

Typical scenarios include point-in-time headcount reporting, applicant and employee reconciliation, name and contact extracts, and integrations that must supply the person record valid on a given date.

Retrieve the current effective row for every person:

• SELECT person_id, employee_number, full_name, effective_start_date, effective_end_date FROM apps.per_people_x WHERE TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date;

Retrieve a person's history:

• SELECT person_id, full_name, effective_start_date, effective_end_date FROM apps.per_people_x WHERE person_id = :person_id ORDER BY effective_start_date;

Join to a global person identifier maintained outside this view:

• SELECT p.person_id, p.full_name, g.global_person_id FROM apps.per_people_x p, apps.per_global_person g WHERE p.person_id = g.person_id AND TRUNC(SYSDATE) BETWEEN p.effective_start_date AND p.effective_end_date;

Because rows are date-effective, queries must always constrain the effective dates to avoid returning historical versions of the same person.