Search Results per_person_type_usages_f




Overview
Explore in AI Chat

Overview

PER_PERSON_TYPE_USAGES_F is a date-tracked (non-interfaced "F" suffix) table in the PER — Human Resources product family of Oracle E-Business Suite, owned by the HR schema. Its documented purpose, per ETRM 12.2.2 metadata, is to identify the types a person may be. In practice, this table stores the association between a person and one or more person types (for example, Employee, Applicant, Contingent Worker, or any user-defined person type configured for the enterprise), with effective-dating that permits the assignment to change over time without losing history.

Because the table carries effective start and end dates alongside the PERSON_ID and PERSON_TYPE_ID references, it functions as a temporal record of person-type membership rather than a simple lookup. In Data Vault terms, the heuristic classification mined from the FK structure is standalone, meaning the object participates in relatively few foreign-key dependencies of its own. A reasonable modeling suggestion, given the effective-dated nature of the data, is to treat it as a satellite-like structure attached to the person/party hub, though the mined classification does not formally assert this. The table contains 46 documented columns, of which the majority are descriptive flexfield (ATTRIBUTE1 through ATTRIBUTE30), WHO-audit, and concurrent-program bookkeeping columns.

Key Information Stored

The most significant columns documented for this table are:

Two unique indexes are documented: the primary key PER_PERSON_TYPE_USAGES_F_PK and PER_PERSON_TYPE_USAGES_F_UK1 on (PERSON_ID, PERSON_TYPE_ID, EFFECTIVE_START_DATE). The second index is the meaningful business-key candidate, since it guarantees that a given person cannot hold the same person type twice beginning on the same effective date, while still allowing that person type to be re-assigned across different date ranges.

Common Use Cases and Queries

Typical uses include determining the current person type of an employee or applicant, validating eligibility rules driven by person type, and producing historical headcount or applicant-tracking reports that require as-of-date logic. A common query pattern resolves the current row by comparing the system date against the effective range:

SELECT ptu.person_id, ptu.person_type_id
FROM per_person_type_usages_f ptu
WHERE TRUNC(SYSDATE) BETWEEN ptu.effective_start_date AND ptu.effective_end_date;

A point-in-time variant substitutes a report date parameter for SYSDATE. Joining to the person type definition table allows the numeric PERSON_TYPE_ID to be reported as a human-readable type name, and joining to PER_ALL_PEOPLE_F links the usage back to the person. Reporting teams frequently filter on EFFECTIVE_END_DATE = '31-DEC-4712' to isolate the active row. Because queries must be date-aware, tools that ignore the effective range can return duplicate rows for a single person.

Related Objects

The following objects are most significant in relation to this table:

  • PER_ALL_PEOPLE_F — the master person record, joined on PERSON_ID.
  • PER_PERSON_TYPES (and its translated forms) — defines the person type referenced by PERSON_TYPE_ID.
  • PER_PERSON_TYPE_USAGES_F_PK and PER_PERSON_TYPE_USAGES_F_UK1 — the primary key and unique business-key indexes enforcing integrity on PERSON_TYPE_USAGE_ID and (PERSON_ID, PERSON_TYPE_ID, EFFECTIVE_START_DATE) respectively.
  • PER_PERSON_TYPE_USAGES — the associated non-dated view or interface object commonly used for read-only access.
  • HR_PERSON_TYPE_USAGE_API or equivalent PL/SQL API — the supported programmatic entry point for creating and maintaining person-type usage records with date validation.
  • PER_PERSON_TYPE_USAGE_ID dependent detail tables within the PER schema — child records that reference the usage by its surrogate key.

Because the mined classification is standalone, the joins above are largely driven by PERSON_ID and PERSON_TYPE_ID rather than by an extensive FK web.