Batch Update Of Element Assignment End Date not updated correctly
(Doc ID 1451165.1)
Last updated on NOVEMBER 23, 2019
Applies to:PeopleSoft Enterprise HCM Global Payroll Core - Version 9.1 and later
Information in this document applies to any platform.
Batch Update of Element Assignment End Date Processing Issue
STEPS TO REPLICATE
1. Using the delivered Deduction Element LOANDED, have updated the existing Post Process formula against this element (LIM FM LOANDED) by adding in additional logic to ‘turn on’ the SET ED END DATE system element in the period where the deduction has been fully recovered. This is in accordance with the PeopleBooks extract.
2. Post Process Formula Update:
3. Added this Element to Element Assignment for some payee’s:
4. 2 employees APS005 & APS006 assigned LOANDED Deductions which are to end in the period. That is, the Amount Value equals the Goal Limit
7. Pay was Calculated and deductions taken. System element set to ‘1’.
8. Element Assignment - The End Date has been correctly updated with the Slice End Date and the associated Calendar Group ID added for both employees following the pay Calculate.
9. Summary of Employees and Element Assignment for this Calendar Group ID:
10. EMPLID Element Assignment Status
11. APS004 no LOANDED deduction – no EA
12. APS005 LOANDED deduction assigned/recovered in period. Batch updated End Date and Pay Run
13. APS006 LOANDED deduction assigned/recovered in period. Batch updated End Date and Pay Run
14. APS007 no LOANDED deduction – no EA
15. Now that the End Date and Calendar Group ID have been updated for employees APS005 and APS006 following a pay Calculate, the following tests show that these values are deleted from GP_PYE_OVRD during subsequent Pay and Absence ‘Calculate’ runs even though these employees are not being included in these runs as have no iterative triggers.
16. These values are not reinstated/updated again unless a Recalculate All is run for all employees or via a Group List.
17. Test 1
18. Iterative triggers created for APS004 and APS006 by entering data into Positive Input (PI)
19. Run Calculate option and check LOANDED in EA against APS005 to confirm End Date and Pay Run values still exist. Prior to Pay Calculate EA was as follows:
20. Iterative Triggers:
21. Run Calculate option:
23. After the pay Calculate which processed iterative triggers for APS004 and APS006 only, the LOANDED EA for APS005 was as follows. The End Date and Payroll Run values were deleted.
24. The LOANDED EA for APS006 has had the End Date and Payroll Run updated as had an iterative trigger and therefore processed in the Calculate run.
25. To reinstate the end date/payroll run values, APS005 had to be run in a Group List
26. Test 2
27. Iterative triggers created for APS004 and APS007 by entering data into Positive Input (PI)
28. Run Calculate option and check LOANDED in EA against APS005 and APS006 to confirm End Date and Pay Run values still exist.
29. Prior to Pay Calculate EA as follows for all 4 employees:
30. Iterative triggers prior to Pay Calc:
31. Calculate is run:
33. After the pay Calculate which processed iterative triggers for APS004 and APS007 only, the LOANDED assignments for APS005 and APS006 had the End Date and Payroll Run values deleted.
34. To reinstate the end date/payroll run values, APS005 and APS006 had to be run in a Group List
35. Test 3
36. Iterative triggers created for APS004 (PI entered) and APS007. For APS007 a LOANDED was assigned via EA which is to end in the period (i.e. Amount = Goal Limit).
EXPECTED BEHAVIOR Vs ACTUAL BEHAVIOR
It is incorrect for these values to be deleted for any employee not included in a Calculate process and therefore requiring a Recalculate All to be run to have them reinstated to ensure data is correct, prior to a pay Finalize.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document