Search Results validate_abs_update

Overview

APPS.PER_GB_ABSENCE_RULES is a PL/SQL package in Oracle E-Business Suite that encapsulates the United Kingdom (GB) localisation business rules governing absence and sickness recording. Its primary responsibility is to enforce statutory and configuration-driven validation across absence attendance records before those records are committed to the database, and to perform the date-related recalculation logic required when sickness entries are amended.

The package header carries the revision stamp pegbabsr.pkh 120.5.12010000.1, dated 28 July 2008, which identifies it as a 12.1-era object carried forward into the 12.2.2 code line. In ETRM it is classified with an API classification of OTHER, indicating that it is an internal rule-engine package rather than a formally published public API. It is referenced by three other packages, confirming its role as a shared validation and derivation service consumed by higher-level absence processing routines.

Because the package exists specifically for the GB legislation group, it supplements the generic Oracle HRMS absence framework with checks that only apply to UK payroll and statutory sick pay (SSP) contexts, such as validating that absence dates and times fall within permissible boundaries before they are written to the absence tables.

Key Procedures and Functions

The package exposes four documented procedures:

• SICKNESS_DATE_UPDATE — Accepts an absence attendance identifier and performs the date-processing logic associated with a sickness record. This is the procedure most directly implicated by the search term sickness_date_update. It is invoked when an existing sickness absence record requires its dates to be re-evaluated, for example following an amendment to the underlying entry.
• VALIDATE_ABS_CREATE — Validates the parameters supplied when a new absence record is created. It checks the business group, person, absence start and end dates, absence start and end times, and the absence attendance type being assigned. The time parameters carry a comment referencing Bug 6708992, indicating a fix delivered around time-based absence validation.
• VALIDATE_ABS_UPDATE — Validates an amendment to an existing absence record, covering the revised start and end dates, the revised start and end times, and the absence attendance identifier of the record being changed.
• VALIDATE_ABS_DELETE — Validates whether an identified absence attendance record may be deleted, providing the rule gate that precedes removal of an absence entry.

Together these four procedures form a complete create, update, and delete validation surface for absence attendance data.

Tables Accessed

The package operates against two documented base tables through APPS synonyms:

• PER_ABSENCE_ATTENDANCES — Holds the individual absence and sickness records. The package reads and updates this table, most notably through SICKNESS_DATE_UPDATE, which recalculates date information for a given attendance identifier, and through the update and delete validations.
• PER_ABSENCE_ATTENDANCE_TYPES — Defines the configured absence categories available to the business group. The create validation consults this table to confirm that the supplied absence attendance type is valid and consistent with the person, dates, and times being recorded.

Usage Notes

PER_GB_ABSENCE_RULES is not normally called directly by end users. It is invoked in three principal ways:

• From the Absence and Sickness entry forms. When a user creates, modifies, or deletes an absence record in the GB localised HRMS forms, the form triggers the corresponding validation procedure to enforce absence rules before the change is committed.
• From calling packages. Because three other packages reference this one, the validation and date-update routines are executed indirectly by higher-level absence processing logic, including any batch or concurrent processing that maintains absence records.
• From custom code and extensions. Developers writing custom absence interfaces, conversions, or extensions for GB legislation groups can call these procedures to reuse the standard validation behaviour rather than reimplementing statutory date rules.

Because the procedures are validation-oriented, callers should expect them to raise errors on rule violations rather than return status codes, and should invoke them within the same transaction as the DML they are validating.