Old timesheets or Previously submitted timesheets get resubmitted.
And in some scenario, Replication is triggered again creating duplication of records in target system.
EMPLOYEE CENTRAL - TIME SHEET
EMPLOYEE CENTRAL - TIME OFF
Reproducing the Issue
- There are old timesheets in the system prior to 2011 release that finished with status 'ERROR'
- These timesheets are automatically recalculated after the release
- The timesheet are stamped as "changed by v4admin"
- Where applicable these timesheets get replicated automatically to the target system such as Payroll (causing duplication of records)
This is a side effect of feature 'retry counter' for object Time Management Recalculation Event.
Before Release b2011, many customers complained about too many pending recalculation events not being picked up by the recalculation job.
The reason was that - too many recalculation events that finished with status 'ERROR' were picked up by the next recalculation job run again and again.
This caused a huge number of pending recalculations piling up.
After release b2011, the feature 'retry counter' became effective - see handbook:
With this feature, each recalculation event gets a 3 attempts for being recalculated.
If a recalculation fails more than 3 times, it is not picked up by the recalculation job anymore.
WHY ARE RECALCULATION FAILING
The reason for failing recalculations are usually configuration issues which need to be resolved by the customer admins.
The errors are posted into the job logs (csv files downloadable in Execution Manager Dashboard) as well as Time Management Alerts (see Admin Alerts UI or Time Admin Workbench).
The retry counter feature helped to dramatically reduce the impact of 'bad recalculation events' on the recalculation jobs health / run-time and support the stability and functional correctness of the recalculation feature overall.
However, the side effect is that:
Recalculation events which where 'shadowed' by the 'failing events' before release b2011, are now picked up by the recalculation job and processed successfully.
Before the upgrade, only a very limited number of very old recalculation events could be picked up by the recalculation job.
Now that the recalculation job is 'fixed' the system is now able to process recalculation events on-time and thus ensuring data integrity for the customer.
The so called 'earliest recalculation date' should be used regularly by the customer, to define the earliest date from which recalculations should be executed.
This date should be adjusted at least once a year (see handbook).
In summary the customer needs to fix the issues posted during recalculation like Time Management Alerts promptly in order to ensure data integrity for its employees.
If the issue occurs 3 times, then the recalculation will not happen anymore for this employee and the data / timesheet is most likely not correct.
Therefore If 'bad recalculation events' still exist in the system, they are just not processed anymore.
The customer must check their system to identify the configuration issues which prevented a successful recalculation and what that means for the data (also payroll data!) of the impacted employees.
Timesheet recalculation. Approved Time Sheet Resubmitted, changed by v4admin , KBA , LOD-SF-EC-TMS-DAT , Data - Import, API, External, Deletion, Audit , LOD-SF-EC-TIM-REC , Recalculation , Product Enhancement