Search Results get_active_start_date




Overview
Explore in AI Chat

Overview

APPS.HR_CONTRACT_API is a public PL/SQL API licensed for use with Oracle Human Resources. It maintains employment contract information for employees, allowing contract records to be created, changed, and removed while preserving the date-tracked history that Oracle EBS applications depend upon. The package operates against the core HR person and assignment model and is registered in the ETRM repository with an API classification, indicating that it is a supported programmatic entry point rather than an internal utility. Its repository header dates from the 11i era (hrctcapi.pkh 120.1) and the object remains available in both Oracle EBS 12.1.1 and 12.2.2.

A contract record stores date information such as expiration and supports tracking of the status of physical documents produced when a contract is signed. There is no restriction on the number of contracts a person may hold at one time, so callers are responsible for applying business rules that limit overlapping or concurrent contracts. Because the package writes through the DATETRACK-enabled PER_CONTRACTS_F table, it correctly maintains effective start and end dates for each contract row.

Key Procedures and Functions

  • CREATE_CONTRACT — Creates a new contract for an employee. Prerequisites are an existing employee record and lookup values for the CONTRACT_STATUS and CONTRACT_TYPE lookup types. On success a contract exists for the employee; on failure no contract is created and an error is raised.
  • UPDATE_CONTRACT — Modifies an existing contract, applying the same validation model as creation and updating the date-tracked row.
  • DELETE_CONTRACT — Removes a contract record, subject to the package's validation rules.
  • LCK — Row-locking routine used internally to serialize concurrent maintenance of a contract row.
  • MAINTAIN_CONTRACTS — Higher-level maintenance routine that coordinates contract processing, typically as a wrapper over the create, update, and delete operations.
  • GET_PPS_START_DATE — Returns the start date of the related period of service (PPS) for the person or assignment in context. This is the counterpart to the user's search term's sibling routine.
  • GET_PPS_END_DATE — Returns the end date of the related period of service. This is the function most closely associated with the search term "get_pps_end_date"; it is used to derive contract expiry and continuation dates from the periods-of-service record rather than from the contract row itself.
  • GET_MEANING — Resolves a lookup code to its displayed meaning, allowing callers to translate stored CONTRACT_STATUS or CONTRACT_TYPE values for reporting and user interface display.
  • GET_ACTIVE_START_DATE — Returns the effective start date of the active contract version.
  • GET_ACTIVE_END_DATE — Returns the effective end date of the active contract version.

Tables Accessed

  • PER_CONTRACTS_F — The primary table maintained by the package; holds contract rows with effective dating, status, type, and document tracking attributes.
  • PER_ALL_ASSIGNMENTS_F — Provides the assignment context against which contracts are dated and validated.
  • PER_ALL_PEOPLE_F — Supplies the employee record that must exist before a contract can be created.
  • PER_PERIODS_OF_SERVICE — Source of the period-of-service start and end dates returned by GET_PPS_START_DATE and GET_PPS_END_DATE.

Usage Notes

The package is typically invoked from Oracle HRMS forms and from concurrent programs that process contract or period-of-service data in bulk, and it is referenced by 21 other packages within the ETRM repository. Custom code should call only the documented public procedures, pass lookup values that already exist for CONTRACT_STATUS and CONTRACT_TYPE, and honor the p_validate convention described in the API comments so that validation-only runs leave the database unchanged. Callers that need contract expiry dates should combine the GET_PPS_* and GET_ACTIVE_* functions rather than reading PER_CONTRACTS_F directly, since the functions apply the effective-date logic consistently across 12.1.1 and 12.2.2.