Results for “per_contracts_d”

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

Overview

The view APPS.PER_CONTRACTS_D belongs to the Oracle Human Resources (PER) product family and is documented in ETRM as a DateTrack history view with status VALID. Its stated purpose is to expose the date-effective history of contract records maintained against the base table PER_CONTRACTS_F. In Oracle EBS, DateTrack-enabled entities maintain a non-historized "current" table (the _F table) alongside date-effective history in a _F/_D pattern. The _D view surfaces the history so that prior effective-dated versions of a contract can be reported on, not just the currently active row.

This object was retrieved in the context of a search on the term contract_type, and the view's definition reflects that interest directly: one of its lookup joins resolves PCF1.TYPE against the HR_LOOKUPS lookup type CONTRACT_TYPE. Reports and extracts that need the human-readable contract type — rather than the stored lookup code — can select the decoded meaning column exposed by this view without writing the lookup join themselves.

Underlying Base Objects

Per the documented ETRM metadata, the view references four objects: PER_CONTRACTS_F (SYNONYM), FND_USER (SYNONYM), HR_LOOKUPS (VIEW), and HR_API (PACKAGE). The view text confirms the first three as join sources; the HR_API package is the standard DateTrack API layer associated with PER date-tracked entities.

The principal source is PER_CONTRACTS_F, aliased PCF1 in the view text, which supplies the contract identifier, the effective start and end dates, reference, type, status, duration, parties, and extension attributes. FND_USER is outer-joined on USR.USER_ID (+) = PCF1.LAST_UPDATED_BY to resolve the updating application user to a user name. HR_LOOKUPS is joined seven times (aliases HR1 through HR7), each join constrained by LOOKUP_TYPE and LOOKUP_CODE to translate a stored code into its meaning.

Key Columns

• CONTRACT_ID — Surrogate identifier linking each historical version back to the contract in PER_CONTRACTS_F.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — The DateTrack effective dates that define the validity window of each history row.
• REFERENCE — Contract reference entered by the user.
• TYPE — The decoded contract type meaning, resolved from lookup type CONTRACT_TYPE; this is the column relevant to a contract_type search.
• STATUS / STATUS_REASON — Decoded from lookup types CONTRACT_STATUS and CONTRACT_STATUS_REASON.
• DURATION / DURATION_UNITS — Contract duration and its decoded qualifying-units meaning (QUALIFYING_UNITS).
• CONTRACTUAL_JOB_TITLE — Job title recorded on the contract.
• PARTIES — Parties associated with the contract.
• START_REASON / END_REASON — Decoded from CONTRACT_START_REASON and CONTRACT_END_REASON.
• NUMBER_OF_EXTENSIONS, EXTENSION_REASON, EXTENSION_PERIOD, EXTENSION_PERIOD_UNITS — Extension-related attributes, with units decoded from QUALIFYING_UNITS.
• LAST_UPDATE_DATE / LAST_UPDATED_BY — Audit columns; the updater resolves to a user name via FND_USER.

Common Use Cases and Queries

Because the view performs the lookup decoding internally, it is well suited to reporting on contracts by type, status, or reason without repeating lookup joins. A typical query filtering on contract type is:

• SELECT contract_id, reference, type, status, effective_start_date, effective_end_date FROM apps.per_contracts_d WHERE type = '&contract_type';

To inspect the full effective-dated history of a single contract:

• SELECT contract_id, effective_start_date, effective_end_date, type, status, last_update_date FROM apps.per_contracts_d WHERE contract_id = :contract_id ORDER BY effective_start_date;

For audit or extension tracking, the extension columns and the resolved user name are commonly selected:

• SELECT reference, number_of_extensions, extension_period, extension_period_units, last_updated_by FROM apps.per_contracts_d WHERE effective_end_date >= SYSDATE;

Note that all lookup joins in the view are outer joins, so a history row survives even when a lookup code has no active meaning. The ETRM-published column list omits the decoded meaning and user-name columns exposed by the view text; consumers should verify available columns directly in the target environment.