GPAUS: STP Preparation Process Not Disaggregating Retro From Previous Calendar Groups (Doc ID 2850564.1)

Last updated on JULY 21, 2023

Applies to:

Symptoms

The disaggregated retro amounts are no longer reported. Also, the Lump E data loses the Lump Sum E Financial Year.


Steps to Reproduce the issue
---------------------------------

1. Create retro entries for the current calendar group so that retro can be forwarded for various items such as Overtime/Bonus/Allowance/Salary
* RETRO PY - expect these amounts to be disaggregated to the STP Sub Category of the base Overtime/Bonus/Allowance/Salary etc.
* RETRO12MTH < $1200 - expect these amounts to be disaggregated to the STP Sub Category of the base Overtime/Bonus/Allowance/Salary etc.
* RETRO12MTH > $1200 - expect these amounts to be reported as LUMP E, and have the Lump E financial year for the base Overtime/Bonus/Allowance/Salary etc.

2. Run GP Calculation Process, then the STP Preparation process. Current calendar group results for STP seem appropriate,
    Menu-->Global Payroll & Absence Mgmt-->Absence and Payroll Processing-->Calculate Absence and Payroll
    Menu-->Global Payroll & Absence Mgmt-->Authority Correspondence-->STP Payroll Event Prep AUS

   Rollover to the next calendar groups Finalize the calendar group then Identify/Calculate the next calendar group

3. Run STP Preparation process, Menu-->Global Payroll & Absence Mgmt-->Authority Correspondence-->STP Payroll Event Prep AUS

4. Review STP data created and reconcile to the accumulators, and adjust for the disaggregated retro

5. The disaggregated retro from the previous pay is no longer reported, also the Lump E amounts are different and does not have the Lump E financial year

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.