Search Results get_unprocessed_retro_asg




Overview
Explore in AI Chat

Overview

PAY_RETRO_STATUS_INTERNAL is an internal PL/SQL package in the Oracle E-Business Suite Payroll (PAY) module that manages the lifecycle and state transitions of retroactive payroll processing records. Retroactive processing recalculates an assignment's historical element entries when a backdated change occurs — for example, a salary adjustment, a revised element link, or a correction to a prior period's input values. This package provides the programmatic plumbing that tracks which retro assignments exist, whether they have been processed, and how they should be reprocessed.

The package is classified as OTHER under the APPS schema and is explicitly marked "Internal Development Use Only" for its documented functions. It is not a public, supported API. Its primary business purpose is to allow the payroll engine and related concurrent processes to identify unprocessed retro assignments, create superseding ("super") retro assignments when reprocessing is required, and maintain or remove retro entries and components that no longer apply. All operating units and legislative contexts that rely on Oracle Payroll retro functionality depend on this internal state management, which underpins the correctness of retroactive pay calculations.

Key Procedures and Functions

The package exposes eight documented procedures and functions:

  • GET_UNPROCESSED_RETRO_ASG — A function that returns the unprocessed retro assignment identifier for a given assignment, or null when none exists. It is the primary query entry point for determining whether an assignment has pending retro work.
  • CREATE_SUPER_RETRO_ASG — Creates an unprocessed retro assignment that supersedes an existing unprocessed retro assignment, accepting a reprocess date and start date among its parameters. This drives re-evaluation of retro calculations from the supplied effective point.
  • UPDATE_RETRO_ASG — Maintains attributes of an existing retro assignment record, typically updating status, dates, or approval information as processing advances.
  • DELETE_RETRO_ASG — Removes a retro assignment record, used when the retro work is cancelled or otherwise obviated.
  • DELETE_RETRO_ASG_CASCADE — Performs a cascading delete, removing the retro assignment together with its dependent retro components and entries.
  • MAINTAIN_RETRO_ENTRY — Manages individual retro entries, the line-level records describing what must be recalculated or reversed.
  • DELETE_RETRO_ENTRY — Removes a specific retro entry that is no longer required.
  • UPDATE_REPROCESS_DATE — The object surfaced by the search term "update_reprocess_date." It adjusts the reprocess date associated with retro records, controlling the effective date from which the payroll engine re-runs retro processing. Because the reprocess date governs which periods are re-evaluated, this procedure directly affects the scope and outcome of a retro run.

Each of these routines is designed to be called by internal payroll processing logic rather than by end users directly.

Tables Accessed

The package operates across the core retro and assignment data model. It reads and writes PAY_RETRO_ASSIGNMENTS, the header table holding unprocessed and processed retro assignment state, and PAY_RETRO_COMPONENTS and PAY_RETRO_COMPONENT_USAGES, which describe the element components affected by retro processing. Retro entry detail resides in PAY_RETRO_ENTRIES, while the underlying payroll element data is held in PAY_ELEMENT_ENTRIES_F and the links that determine eligibility are in PAY_ELEMENT_LINKS_F; element naming comes from PAY_ELEMENT_TYPES_F_TL.

Assignment and service context is drawn from PER_ALL_ASSIGNMENTS_F and PER_PERIODS_OF_SERVICE, which anchor retro records to the correct employee assignment and period of service. Together these tables allow the package to determine which assignments qualify, what must be recalculated, and how records should be created, updated, or purged.

Usage Notes

PAY_RETRO_STATUS_INTERNAL is invoked indirectly through the standard Payroll processes and their supporting forms and concurrent programs. Retroactive processing concurrent requests, element entry maintenance, and the assignment-level retro inquiry screens call into this package to establish and maintain retro state. Two other packages reference it, indicating it sits within a small cluster of internal retro-handling code.

Because the package is labeled for internal development use only and its signatures are governed by the shipped header (pyrtsbsi.pkh), customers and implementers should not call its procedures directly; doing so risks corrupting retro assignment state and is unsupported. Customizations that require retro behavior should use supported public APIs and payroll processes. Both Oracle EBS 12.1.1 and 12.2.2 ship this package with equivalent internal semantics, and any change to the reprocess date, in particular, should be performed only through the supported payroll flows that invoke UPDATE_REPROCESS_DATE on the user's behalf.