Search Results pay_itr_bus




Overview

PAY_ITR_BUS is an Oracle EBS Human Capital Management (payroll) package owned by the APPS schema. In Oracle Payroll the initials "ITR" denote Iterative Rules — the user-defined rules that determine how the payroll run repeats the calculation of an element, or a group of elements, until a defined condition is satisfied. PAY_ITR_BUS provides the business-logic layer for maintaining the iterative-rule definitions that support this recalculation behaviour. It is classified in ETRM as an "OTHER" API, i.e. it is a supporting business-service (BUS) package that is called by other layered packages rather than a formally published, externally supported API such as the PAY_*_API family.

The package exists to shield its callers from the physical organisation of the underlying iterative-rule tables and to centralise the validation logic that governs inserts, updates and deletes. Its structure follows the standard Oracle Payroll BUS/shell pattern: a set of public validation entry points invoked by the DML wrappers (PAY_ITR_INS, PAY_ITR_UPD, PAY_ITR_DEL, PAY_ITR_BUS itself recursing into the same body), supported by the shared service package PAY_ITR_SHD, and by the compulsory SYS.STANDARD package referenced by every PL/SQL unit.

Key Procedures and Functions

The ETRM listing registers five documented procedures and functions:

  • SET_SECURITY_GROUP_ID — Establishes the security group context for the current database session, in line with the Oracle HRMS security model (Business Group / Security Group). This must be called before the business validation logic executes so that rows are validated within the correct legislative and security context.
  • RETURN_LEGISLATION_CODE — Returns the legislation code associated with the session (or with the iterative-rule record being processed). Legislation determines which validation rules apply, since iterative-rule behaviour is legislation-specific.
  • INSERT_VALIDATE — Performs pre-insert validation of a new iterative-rule definition, ensuring that mandatory attributes are populated and that the record is consistent with existing payroll definitions before the physical insert is committed.
  • UPDATE_VALIDATE — Performs the equivalent validation for modifications to an existing iterative-rule definition, protecting referential and business-rule integrity when an existing rule is changed.
  • DELETE_VALIDATE — Validates that an existing iterative-rule definition may safely be removed, preventing deletion of records that are still referenced or that would leave dependent payroll processing in an inconsistent state.

Parameter lists are not published in the ETRM extract and are therefore intentionally omitted.

Tables Accessed

The package operates against the following tables through APPS synonyms:

  • PAY_ITERATIVE_RULES_F — the primary object of interest; holds the iterative-rule definitions that the validation routines check.
  • PAY_ELEMENT_TYPES_F — the element definitions to which iterative rules are attached, consulted to confirm element eligibility and legislation.
  • PAY_INPUT_VALUES_F — input values belonging to elements, used to validate the input values referenced by a rule.
  • FF_FDI_USAGES_F — FastFormula database-item usages, used to confirm that the formulas referenced by the rule exist and are correctly wired to their inputs.
  • ALL_TABLES — the data dictionary view, typically consulted for existence or metadata checks during validation.

Usage Notes

PAY_ITR_BUS is not intended for direct invocation by end users or by customer extensions. It is driven by the payroll maintenance forms and by the DML wrapper packages PAY_ITR_INS, PAY_ITR_UPD, PAY_ITR_DEL and PAY_ITR_BUS itself, which are the objects referenced in ETRM as its dependents. Because the package shares its logic with the shadow package PAY_ITR_SHD, customisations should follow the supported path of extending the shadow package rather than modifying PAY_ITR_BUS directly, since patches to Oracle Payroll will overwrite the standard body. The behaviour is identical in EBS 12.1.1 and 12.2.2, and no formal API documentation or parameter specification is published for the package.