Search Results get_rr_source_type

Overview

PAY_RETRO_PKG is the core PL/SQL package within the Oracle E-Business Suite Payroll application that implements retroactive pay processing logic. Retroactive processing recalculates an employee's pay when a prior-period element entry, input value, or assignment change is entered or corrected, and then propagates the resulting difference forward into the current pay period. This package serves as the central engine that orchestrates the identification, reprocessing, and reconciliation of retroactive element entries within the payroll run cycle.

Within the APPS schema, PAY_RETRO_PKG is classified as an OTHER API rather than a public business API. It is a foundational internal package that other retro-related components depend upon. The ETRM dependency listing confirms that PAY_RETRO_PKG is referenced by PAY_RETRO_NOTIF_PKG, PAY_RETRO_STATUS_INTERNAL, PAY_RETRO_UTILS_PKG, PY_ROLLBACK_PKG, and itself, while it references the HR_API utility package. This dependency structure demonstrates that retro processing is a collaborative subsystem in which PAY_RETRO_PKG acts as the primary driver and the other packages provide notification, status tracking, rollback, and utility support.

Key Procedures and Functions

The package exposes 27 documented procedures and functions. The principal driver routines are RETRO_RUN_PROC, which initiates and orchestrates retroactive processing for the current payroll run, and RETRO_END_PROC, which finalizes the retro process and performs closing activities once recalculation is complete.

A second group of procedures handles the interpretation and processing of individual retro entries, including PROCESS_RETRO_ENTRY, PROCESS_RETRO_VALUE, PROCESS_VALUE, and MAINTAIN_RETRO_ENTRY. Supporting these are classification and identification functions such as IS_RETRO_ENTRY, IS_RETRO_RR, GET_RETRO_PROCESS_TYPE, GET_REPROCESS_TYPE, GET_RETRO_ELEMENT, GET_RETRO_COMPONENT_ID, GET_SOURCE_ELEMENT_TYPE, GET_RR_SOURCE_ID, and GET_RR_SOURCE_TYPE. These functions determine whether a given element entry or record is retroactive in nature and resolve the source identifiers required for reprocessing.

Overlap and assignment handling is performed by GET_EE_OVERLAP_DATE, LATEST_REPLACE_OVL_EE, LATEST_REPLACE_OVL_DEL_EE, and MERGE_RETRO_ASSIGNMENTS, which detect overlapping effective dates and consolidate assignment-level retro data. GENERATE_OBJ_GRP_ACTIONS creates object group actions required for downstream batch processing during a retro run.

Tables Accessed

PAY_RETRO_PKG interacts with a set of core payroll tables through APPS synonyms. Assignment and action management rely on PAY_ASSIGNMENT_ACTIONS, PAY_ASSIGNMENT_ACTIONS_S, and PAY_RETRO_ASSIGNMENTS, which tracks assignments flagged for retroactive recalculation. Element entry processing reads and writes PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_ENTRY_VALUES_F, and PAY_INPUT_VALUES_F, the tables that store the values being reprocessed.

Element configuration and classification rules are read from PAY_ELEMENT_TYPES_F, PAY_ELEMENT_TYPE_RULES, PAY_ELE_CLASSIFICATION_RULES, and PAY_ELEMENT_SPAN_USAGES. Run-level state is held in PAY_PAYROLL_ACTIONS and PAY_PAYROLL_ACTIONS_S, while processing audit information is recorded in PAY_ENTRY_PROCESS_DETAILS, PAY_RECORDED_REQUESTS, and PAY_OBJECT_GROUPS. Collectively, these tables support the full lifecycle of identifying retroactive changes and generating corrected entries.

Usage Notes

PAY_RETRO_PKG is not intended for direct invocation by end users or custom integrations. It is invoked by standard Payroll processes, most notably the Retro Pay process and Payroll Run concurrent programs, and by the Oracle Payroll forms that manage element entries and retroactive adjustments. Because the package writes to payroll entry and assignment action tables, it must be executed within the payroll processing framework to preserve data integrity and sequencing.

Customers and developers should treat PAY_RETRO_PKG as an internal implementation package, consistent with its OTHER API classification. Custom code should not call its procedures directly; instead, retroactive processing should be triggered through the supported concurrent programs and forms. Any dependency on the package should be limited to downstream Oracle packages such as PAY_RETRO_UTILS_PKG, which provide stable, sanctioned access to retro functionality.