Search Results pay_iterative_rules_s

Overview

PAY_ITR_INS is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Oracle Payroll family of iterative rules objects, which support the definition and maintenance of iterative rule logic used during payroll processing. Iterative rules (ITR) govern how the payroll engine repeatedly evaluates certain calculations, such as retroactive adjustments, proration, or recalculation loops, until a defined condition or termination criterion is satisfied. The package is classified as an "OTHER" API rather than a public, customer-facing payroll API.

Functionally, PAY_ITR_INS acts as the insert-side companion to the iterative rules datastore. It provides the low-level routines that create new rows in the iterative rules tables, handling the associated validation, message handling, and row-key bookkeeping required when a new iterative rule definition is added. The package is tightly co-dependent with its sibling packages PAY_ITR_BUS, PAY_ITR_RKI, PAY_ITR_SHD, and the PAY_ITERATIVE_RULES_F/S tables. The ETRM metadata records that PAY_ITR_INS is not referenced by any other database object, but it is documented as referenced by three other packages, indicating a supporting role within that internal package family.

Key Procedures and Functions

The documented package exposes two procedures/functions:

• INSERT_DML — the core DML insert routine. Its name follows Oracle's convention for a procedure that performs the direct insert of a row into the iterative rules tables. This is the workhorse routine invoked by higher-level APIs when a new iterative rule must be persisted, and it is responsible for populating the table columns and raising the appropriate errors through FND_MESSAGE and HR_API if the insert cannot be completed.
• INS — the entry-point insert procedure. INS typically wraps INSERT_DML, applying the standard Payroll/Datetrack conventions: validating inputs, deriving row identifiers and WHO columns via FND_GLOBAL, setting the effective dates and business-group context, and then delegating to INSERT_DML for the physical insert.

No parameter lists are documented, and none are inferred here. The dependency list indicates that INS and INSERT_DML rely on HR_API, HR_UTILITY, DT_API, FND_GLOBAL, and FND_MESSAGE, which confirms that these procedures participate in the standard HRMS Datetrack and error-handling framework.

Tables Accessed

The package inserts into two documented tables, accessed through APPS synonyms:

• PAY_ITERATIVE_RULES_F — the base (non-Datetracked) iterative rules table. INSERT_DML writes the core definition of a new iterative rule into this table, including its identifying and functional attributes.
• PAY_ITERATIVE_RULES_S — the Datetrack shadow table. This table holds the effective-dated, versioned copy of each rule and is maintained in parallel with the _F table by the insert logic, enabling the payroll engine to retrieve the rule definition valid for a given date or process run.

Both tables are read and written in coordination with PAY_ITR_BUS, PAY_ITR_RKI, and PAY_ITR_SHD, which together form the iterative rules business layer, row-identifier handler, and shadow handler respectively. The presence of DT_API and DUAL in the dependency list confirms Datetrack-managed insertion and identity queries.

Usage Notes

PAY_ITR_INS is an internal, non-public package. It is not documented as referenced by any other database object, so direct invocation from custom code is not recommended and is not supported. In practice it is called by the iterative rules maintenance layer (PAY_ITR_BUS and related handlers) whenever an iterative rule definition is created through the Oracle Payroll setup forms or through Oracle-provided concurrent processes that generate or copy iterative rules.

Consultants working with payroll retroactive and iterative rule configuration with the keyword search "pay_iterative_rules_s" should be aware that PAY_ITERATIVE_RULES_S is the effective-dated shadow table, not a table intended for direct user DML. All inserts should be routed through the supported API or form, which in turn reaches PAY_ITR_INS. Custom development should target documented public payroll APIs rather than this package. In Oracle EBS 12.1.1 and 12.2.2 the object status is VALID, and its schema and dependency structure are identical across both releases. Because it is a low-level insert package, any structural customisation risks breaking Datetrack integrity between PAY_ITERATIVE_RULES_F and PAY_ITERATIVE_RULES_S.