Search Results assignment_action

Overview

APPS.PAY_PAYRG_PKG is a PL/SQL package body in the Oracle E-Business Suite Payroll module whose stated purpose, per its header, is to "define the cursors needed to run Payroll Register Multi-Threaded." It is not an application programming interface in the conventional sense; the ETRM classification for this object is OTHER, confirming that it supports Oracle's internal processing rather than a published extension contract. Within the Oracle Payroll architecture, the Payroll Register is the report that consolidates assignment-level payroll results into a register format for a payroll run. Because a single payroll run can span thousands of assignments, the package supplies the cursors and supporting logic that let the Payroll Register concurrent program be partitioned into parallel worker processes, each handling a subset of assignment actions.

The change list embedded in the source traces an evolution from its creation in March 1999 through a series of maintenance versions. Notable milestones include the addition of assignment set functionality, modification of cursors to use secure (Row Level Security) views, use of base tables in the sort code routine, adjustment of action creation logic for the multi-threaded "umbrella" process, and changes to the payroll run cursor so that actions created before the umbrella process are also processed and the action itself is generated dynamically.

Key Procedures and Functions

• RANGE_CURSOR — Defines the range of assignment action records that a given thread of the multi-threaded Payroll Register process will retrieve. It is the partitioning primitive that divides payroll data across concurrent workers.
• ACTION_CREATION — Creates the assignment action records required by the register processing, operating in conjunction with the umbrella process so that both pre-existing and dynamically created actions are handled.
• SORT_ACTION — Establishes the ordering applied to assignment actions prior to processing or reporting, drawing its sorting logic from base tables rather than dependent views.
• GET_PARAMETER — Retrieves a parameter value needed by the package's processing logic, providing a single point of access for configuration inputs to the cursors and action routines.
• SORT_OPTION — Determines or exposes the sort option governing how the Payroll Register output is sequenced.

All five are documented routines; no parameter lists are reproduced here because the ETRM metadata does not publish signatures.

Tables Accessed

The package references twelve objects through APPS synonyms. The core of its action handling rests on PAY_ASSIGNMENT_ACTIONS and PAY_ASSIGNMENT_ACTIONS_S, which store the assignment-level units of work for a payroll run and are the primary target of ACTION_CREATION and RANGE_CURSOR. PAY_PAYROLL_ACTIONS and PAY_PAYROLL_ACTIONS underpin run-level context, while PAY_ACTION_INTERLOCKS and PAY_RUN_TYPES_F supply run type and interlock information used when creating actions dynamically. PAY_PRE_PAYMENTS supports prepayment processing associated with the run. Assignment and person data come from PER_ALL_ASSIGNMENTS_F. Organization, location, and assignment set data are drawn from HR_ALL_ORGANIZATION_UNITS, HR_LOCATIONS_ALL, and HR_ASSIGNMENT_SET_AMENDMENTS, the latter reflecting the assignment set functionality added in version 115.1. PAY_US_RPT_TOTALS supplies United States report totals, and DUAL is used for single-row evaluations.

Usage Notes

PAY_PAYRG_PKG is invoked indirectly during execution of the Payroll Register concurrent program, where it supplies range partitioning and action creation for each thread. It is referenced by three other packages, indicating it participates in a wider internal call graph rather than being called directly by forms or custom code. The use of RLS-secured views and base tables reflects the standard Oracle Payroll security and performance posture in EBS 12.1.1 and 12.2.2. Because the package is classified OTHER and is not a supported API, customizations should not call its routines directly; implementers should treat it as internal infrastructure whose behavior may change between patch levels.