Last updated on JULY 25, 2017
Applies to:Oracle Time and Labor - Version 188.8.131.52 and later
Information in this document applies to any platform.
This problem has only occurred since applying <Patch 9062727> HRMS Family Pack K Rollup 5. Until then an average of 50,000 records per week were passed from OTM to OTLR and then to payroll via BEE Validate and Transfer. Now its nearly a million per 5 week month.
There is a Monthly Payrun with timecards entered for 1 week at a time and passed to BEE, Validated and Transferred at the end of the same week. There are 2000 timecards entered each week for the same people.
Using "Transfer Time from OTL to BEE" with "Changes since" set to the Date of the last weeks run . During May in week 1, 50,000+ rows were transferred to BEE, Week 2, 100,000+, Week 3 150,000+, Week 4 200,000+, Week 5 280,000. But, the number of timecards, and their complexity has not increased.
The extra 100,000 plus BEE entries each week are from previous weeks(already processed) in the same month. They have not been changed during the week that is being processed and were never produced prior to applying HRMS Family Pack K Rollup 5.
This change is causing hundreds of thousands of duplicate records to be set up in Payroll, and GL that should not be created at all . This is causing such problems as system unusable due to over running batch jobs, Discoverer reports failing, Displaying Payroll elements online fail to scroll.
Changing the profile value or passing the Start Date and End Date parameter values should not resolve the issue as the parameter values / profile will control the way "Transfer Time from OTL to BEE" (Stage 1) is run. But the problem lies in Transfer to BEE(Retro) process:
1. Timesheets are transferred from OTL to Payroll on a Weekly basis and
2. Payments are made on a monthly basis as using a Monthly Payroll. (Please note that OTLR is controlled by the Payroll Period).
As the timecards are transferred on a weekly basis, when OTL Weekly Run is submitted for Week 2, Week 3 and Week 4 of the Calendar month, the previous unchanged timecards in the Calendar month are treated as Retro timecards by OTLR engine and is creating 2 entries (negative and positive) for each timecard entry.
This (Two entries per unchanged entry) is happening after the patch HRMS Family Pack K Rollup 5 is applied.
Since OTLR is mainly driven by Employee's Payroll period, timecards for the first week of the month is treated as Normal timecard and Timecards for subsequent weeks of the month are treated as Retro Timecards by the Standard OTLR Engine.
If a timecard has not been changed, then processing Retro Timecards should not create additional BEE rows.
The issue can be reproduced at will with the following steps:
1. Configure system such that OTL Self Service & OTLR are used. (timecards entered in self service are transferred to OTLR and then to Payroll).
2. Timecard Period is weekly and Employee Payroll Period is Calendar Month.
3. Enter Employee timecards for Week 1 of the month. Transfer Timecards to OTLR (Process : Transfer Time from OTL to BEE). Send timecards from OTLR to Payroll (OTLR -> BEE -> Element Entries) (Processes : Validate for BEE, Transfer to BEE, Process BEE).
4. Wait for one day.
5. Do not change timecards for Week 1. Enter timecards for Week 2.
6. Transfer Timecards to OTLR. (Process : Transfer Time from OTL to BEE). Transfer timecards from OTLR to Payroll (Processes: Validate for BEE, Transfer to BEE, Validate for BEE(Retro), Transfer to BEE(Retro), Proces BEE).
7. Observe the Element Entries. Each employee will have Negative and Positive entries for each timecard entry of 1st Week.
<Patch 9062727> HRMS Family Pack K Rollup 5 applied
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms