My Oracle Support Banner

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.

Symptoms

 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

5.    APS006
6.    APS005

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:

22.    Results:

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:
32.    Results:

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.

NOTE: In the examples above, user details / customer name / address / email / telephone number represent a fictitious sample (based up made up data used in the Product name test environment).  Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

 

Changes

 

Cause

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
Symptoms
Changes
Cause
Solution
References


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