Search Results pay_itr_upd




Overview
Explore in AI Chat

Overview

PAY_ITR_UPD is a PL/SQL package body owned by the APPS schema that forms part of the Oracle Payroll "Iterative Rules" (ITR) API stack. The Iterative Rules framework governs the iterative processing behavior of payroll runs — specifically the rules that determine how the payroll engine re-processes assignments, recalculates balances, and converges on correct results during a payroll run. The PAY_ITR_* package family (PAY_ITR_BUS, PAY_ITR_INS, PAY_ITR_UPD, PAY_ITR_DEL, PAY_ITR_RKU, PAY_ITR_SHD) follows the standard Oracle EBS table-handler pattern, where a single business entity is exposed through dedicated insert, update, delete, row-lock (RKU), and shadow (SHD) packages, with a business (BUS) layer providing validation and orchestration.

Within this pattern, PAY_ITR_UPD is the dedicated update handler. Its role is to apply modifications to existing iterative rule definitions while enforcing the validation, WHO-column auditing, and date-tracked change rules required by the HR/Payroll data model. The package is documented in ETRM with an API classification of OTHER and contains the single documented procedure UPD.

Key Procedures and Functions

  • UPD — The sole documented procedure in the package body. It implements the update operation against an existing iterative rule record. Based on the surrounding dependency chain, UPD is expected to invoke HR_API / HR_UTILITY routines for standard date-tracked and WHO-column handling, delegate row-level business validation to PAY_ITR_BUS, and coordinate with PAY_ITR_RKU (row lock) and PAY_ITR_SHD (shadow record) logic to preserve the audit trail. Precise parameter signatures are not published in the ETRM excerpt and are not reproduced here.

Tables Accessed

The documented dependent table is PAY_ITERATIVE_RULES_F, referenced through an APPS synonym. This is the core table holding iterative rule definitions, using the _F suffix that denotes the standard Oracle HRMS date-tracked (effective-dated) table pattern. PAY_ITR_UPD reads and writes this table as the target of its update operation. As an update handler for a date-tracked entity, the package is also expected to interact with the corresponding _TL (translation) table for any descriptive columns that are maintained in multiple languages, and to preserve effective-date integrity when changes are applied to existing rule versions.

Usage Notes

PAY_ITR_UPD is not intended for direct invocation by end users or custom code. It is an internal implementation package within the PAY_ITR_* family and is referenced by one other database object — most plausibly PAY_ITR_BUS, which acts as the public business facade for iterative rule maintenance. Callers requiring iterative rule changes should therefore route through PAY_ITR_BUS, which is responsible for validating business rules before delegating the physical update to PAY_ITR_UPD.UPD.

In practice, iterative rules are maintained through the standard Oracle Payroll setup forms and, in some configurations, through concurrent programs or Oracle-provided APIs shipped as part of the payroll configuration toolset. Custom integration code that manipulates PAY_ITERATIVE_RULES_F directly bypasses the validation, row-lock, and date-track auditing performed by the ITR API stack and risks corrupting the effective-dated history of payroll iterative rules. Standard Oracle EBS design guidance is to use supported APIs rather than direct DML. This applies equally in EBS 12.1.1 and 12.2.2, as the underlying Payroll data model and the PAY_ITR_* API architecture remain consistent across both releases.