Results for “per_periods_of_service_pkg_v2”

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

Overview

APPS.PER_PERIODS_OF_SERVICE_PKG_V2 is a server-side PL/SQL package body in the Oracle E-Business Suite Applications schema (APPS), classified under the Oracle Human Resources (PER) product family. Its business purpose is to encapsulate the rules that govern periods of service for an employee or contingent worker — the contiguous date ranges that describe an individual's employment history, assignments, and resulting service calculations.

The package is an internal (non-public) package, meaning it is not delivered as a formal public API with a documented interface contract. Instead, it provides reusable business logic consumed by other HR packages, forms, and concurrent processes that must determine an employee's current period of service, validate hire dates, and enforce rules concerning open and closed periods of service. The metadata classifies the API family as "OTHER," consistent with its role as an internal utility rather than a published interface.

The object resides in both Oracle EBS 12.1.1 and 12.2.2 and is reported with a status of VALID. It is referenced by four other database objects but does not itself reference or depend on any downstream custom object beyond the standard APPS schema objects listed in its dependency tree.

Key Procedures and Functions

The documented package exposes six procedures and functions:

• GET_MAX_LAST_PROCESS_DATE — Returns the maximum "last process date" associated with an employee's period-of-service records, used to determine the most recent processing point for service-related calculations.
• GET_VALID_HIRE_DATES — Retrieves the valid hire dates (original and adjusted) applicable to an employee, supporting date-effective HR transactions and hire-date validation.
• ISBACKTOBACKCONTRACT — Evaluates whether an employee's successive periods of service constitute a back-to-back contract arrangement, typically used to apply continuous service or contract-continuity rules.
• GET_CURRENT_PDS_START_DATE — Returns the start date of the employee's current period of service.
• GET_CURRENT_OPEN_PDS_ID — Returns the identifier of the currently open period-of-service row for the employee.
• IS_MAX_PDS_NOT_CLOSED — Determines whether the most recent period of service remains open rather than closed, a common prerequisite for updating or terminating service records.

These routines collectively provide read-oriented validation and date-derivation logic that callers use before performing date-effective updates to employee periods of service.

Tables Accessed

The package references the following APPS tables through their synonyms:

• PER_ALL_PEOPLE_F — Date-tracked person records; supplies the individual identity and effective-dated person data.
• PER_ALL_ASSIGNMENTS_F — Date-tracked assignment records; supplies assignment context for service and hire-date derivation.
• PER_ASSIGNMENT_STATUS_TYPES — Assignment status definitions used to interpret assignment state when evaluating service rules.
• PER_PERIODS_OF_SERVICE — The primary transactional table holding period-of-service rows; the package reads and validates against these records.
• PER_PERSON_TYPES — Person type definitions used to distinguish employee, applicant, and contingent worker classifications.

Additional dependencies include the HR_GENERAL, HR_UTILITY, PER_PEOPLE3_PKG, FND_MESSAGE, and STANDARD packages, indicating use of HR utility routines and standard message handling.

Usage Notes

Because this is an internal package rather than a public API, it is typically invoked indirectly. Forms in the Oracle HRMS person and assignment windows, concurrent programs that process periods of service, and other PL/SQL packages (four documented referencing objects) call these routines to validate hire dates and resolve current period-of-service context. Custom code should avoid calling PER_PERIODS_OF_SERVICE_PKG_V2 directly where a supported public API exists, since the package signature may change without notice. When direct invocation is unavoidable, callers must supply valid effective dates and handle the FND_MESSAGE errors raised through the standard HR error stack.