OTL Rollback For Payroll PDF

ORACLE CORPORATION
OTL: Rollback Framework

for Payroll Retrieval
EBS OTL Development Team
15-Jun-12
[This document describes the options and usage of these options with common business scenarios for
Oracle Time and Labor Rollback Framework for Payroll retrieval.]
OTL Rollback Framework for Payroll Retrievals
Contributors
Name Position
Ashok Rajagopal Project Leader
Anima Prasad Group Manager
Change Record
Date Author Version Change Reference
15-Jun-12 Ashok Rajagopal 121.1 First Version
Oracle Time and Labor Development

Table of Contents
Table of Contents ...................................................................................................................................... 3
Introduction .............................................................................................................................................. 5
Pre Requisites............................................................................................................................................ 5
Stages in Payroll retrieval Non OTLR ...................................................................................................... 6
New/Fresh Timecards ........................................................................................................................... 6
Adjustments .......................................................................................................................................... 6
Stages in Payroll Retrieval OTLR............................................................................................................. 7
Fresh Timecards .................................................................................................................................... 7
Adjustments .......................................................................................................................................... 8
Rollback options prior to R12.1.5.............................................................................................................. 9
BEE Batch Process (Rollback) ................................................................................................................ 9
Rollback BEE .......................................................................................................................................... 9
Gaps in the existing flow ....................................................................................................................... 9
Why Rollback? ......................................................................................................................................... 10
Rollback Method ..................................................................................................................................... 10
Extent of Rollback ................................................................................................................................... 14
Validate Option ....................................................................................................................................... 15
Dependent Batches ................................................................................................................................. 15
OTLR and Non OTLR Timecards............................................................................................................... 16
Rollback Eligibility ................................................................................................................................... 16
Deleted Timecards .................................................................................................................................. 17
Timecards overwritten with Templates .................................................................................................. 17
Naming Conventions for Reversal Batches ............................................................................................. 18
Status of Reversal Batches ...................................................................................................................... 19
Status of Batches touched by Rollback Process ...................................................................................... 19
Replacement Batches for OTLR timecards.............................................................................................. 19
Errors in Rollback Programs .................................................................................................................... 21
Manual Changes in BEE Changes to Hours from OTL........................................................................... 22
Manual Changes in BEE New entries in OTLs batches in BEE ............................................................. 22
Manual Changes in OTLR Entry/Validation/Approval screen ................................................................. 22
Accommodating Latest Changes in OTL .................................................................................................. 22
BEE IV Upgrade ....................................................................................................................................... 23
OTL: Rollback Non OTLR Timecards ........................................................................................................ 24
Screenshot .......................................................................................................................................... 24
Description .......................................................................................................................................... 24
Parameters.......................................................................................................................................... 24
Common Error Messages ........................................................................................................................ 26
Understanding the Output File ........................................................................................................... 28
OTL: Rollback OTLR Timecards ................................................................................................................ 30
Screenshot .......................................................................................................................................... 30
Description .......................................................................................................................................... 30
Parameters.......................................................................................................................................... 31
Error Messages ................................................................................................................................... 32

Understanding the Output file............................................................................................................ 33

OTL: Rollback Batches from BEE ............................................................................................................. 34
Screenshot .......................................................................................................................................... 34
Description .......................................................................................................................................... 34
Parameters.......................................................................................................................................... 34
Error Messages ................................................................................................................................... 35
Understanding Output File ................................................................................................................. 36
OTL: Rollback Batches from BEE(Retro) .................................................................................................. 37
Screenshot .......................................................................................................................................... 37
Description .......................................................................................................................................... 37
Parameters.......................................................................................................................................... 37
Error Messages ................................................................................................................................... 38
Understanding Output File ................................................................................................................. 38
Rollback applied on Non OTLR timecard flow......................................................................................... 39
Timecard Lifecycle .............................................................................................................................. 39
Rollback Options ................................................................................................................................. 39
Rollback Applied to OTLR timecard flow................................................................................................. 40
Timecard LifecycleRollback Options ................................................................................................... 40
Rollback Options ................................................................................................................................. 41
Common Rollback Scenarios ................................................................................................................... 42
Scenario 1: Wrong Parameters .......................................................................................................... 42
Scenario 2: Missing Time ................................................................................................................... 44
Scenario 3: Usage Errors .................................................................................................................... 45
Scenario 4: OTLR Preference error ..................................................................................................... 46
Scenario 5: Wrong setting in HXT_TIME_VALIDATION for new period. ............................................. 46
Scenario 6: Wrong setting in HXT_TIME_VALIDATION for older period. ........................................... 47
Scenario 7: Input Value issue in Transfer to BEE(Retro) process........................................................ 48
Scenario 8: Missed Merge batches step in Validate for BEE(Retro). .................................................. 48
Scenario 9: Validation issues for a small group of employees............................................................ 49
Scenario 10: OTLR Preference setup issue ......................................................................................... 50
Scenario 11: Incorrect OTLR Setup - Fresh period. ............................................................................. 51
Scenario 12: Incorrect OTLR Setup retro period ................................................................................. 52

Introduction
This document describes in detail Oracle Time and Labor Rollback Framework for Payroll
application released in Oracle HRMS 12.1 RUP 5. This feature introduces four concurrent
programs with flexible options to cater to various business scenarios requiring a rollback of
time transferred from OTL to Payrolls BEE interface. The four programs are described in detail
in the subsequent sections.
Pre Requisites
Oracle Time and Labor (OTL) Implementation and User Guide, Release 12 [MOS Note
1070930.1]
Oracle Time and Labor Retrievals Troubleshooting Guide [ID 749174.1]
Working knowledge of OTL Payroll timecard lifecycle.

Stages in Payroll retrieval Non OTLR

New/Fresh Timecards
Transfer time from OTL to BEE

Process to transfer time data of employees from OTL to BEE. Timecards entered in OTL by Self
Service Users, Time Keepers, Line Managers, and Authorized Delegates or via API are picked up
by this process and moved over to BEE as batches. The batches created in BEE may contain the
time for one or more employees and across one or more timecards and payroll periods.
Batches are created as per the program parameters and in line with the profile option OTL:
Transfer Batch Size.
Batches created in BEE are created from Source Time Store and in status UnProcessed unless
otherwise mentioned.
Adjustments

The same process transfers new and adjusted timecards from OTL to BEE. However, the
adjustments are not transferred as is. When a timecard is adjusted in some way, the next
process picks up the timecard in the latest shape and creates a batch in BEE as the latest and
most valid entry. The earlier batch that was transferred in the first place is negated with a retro
batch created automatically.
Eg.
User creates timecard with 40 hrs for the week.
Xfer time from OTL to BEE creates a batch for 40 hrs for the week.
User adjusts the timecard to have 45 hrs for the week.
Xfer time from OTL to BEE creates two batches now. One for 45 hrs for the week, which
shows the latest data, and a retro batch for -40 hours to reverse the 40 hours processed
earlier.

BEE Batch Process

BEE Batch Process, which can be initiated from the BEE Batch Summary screen or directly as a
concurrent process picks up the batches mentioned and moves them over to Payroll Element
Entry. Time data created in Element Entry is further processed by Payroll application.
Batches transferred from BEE to Element Entry have the status Transfer.
Stages in Payroll Retrieval OTLR
Fresh Timecards

The same program used to transfer time to BEE from OTL is used to move time to OTLR, the
Rules Evaluation Engine for OTL. OTLR module takes in data entered by Self
Service/Timekeeper/API and applies the set time processing rules to arrive at processed time.
The processed time is transferred to BEE in the processes mentioned below.
Transfer time from OTL to BEE, when run for employee(s) set up to allow Rules Evaluation to
process time does not post the time directly to BEE. The time data is moved to OTLR module,
where it goes thru an Explosion process which logically manipulates time entered according to
rules set up for the employee(s). The data thus created and exploded in OTLR module is
viewable thru the Entry/Validation/Approval Screen. All timecards created in OTLR module is
marked with a batch which is used for further processing of the timecards. All timecards for the
same payroll and payroll period are usually added to the same batch. Profile option
HXT_BATCH_SIZE can be used to control the number of timecards over and above the condition
of Payroll and payroll period.
Validate for BEE

As the name suggests the process is a Validate job before getting data ready for BEE. Timecards
created in OTLR module needs to be validated for correctness before moving to BEE. The
process takes in batches of timecards and validates them against the setup to spot any errors,
manual or otherwise. Validations could be set up in different levels (warning, error or ignore)
by administrators. Unless a batch in OTLR is validated without errors ( with or without
warnings), it cannot be transferred to BEE.

Transfer to BEE
This process moves timecards in OTLR module to BEE as batches, much like Transfer time from
OTL to BEE for Non OTLR timecards. Batches are created with source as OTM and status
Unprocessed.
Adjustments
Adjustments to timecards already created or Retro timecards go to OTLR module in the same
route as normal timecards. However, the original batches in which timecards are created and
transferred to BEE are not modified for retro adjustments. The changes to timecards are
created as a fresh retro batch, which only include the adjustments. They are subsequently
processed to BEE with the following programs. The system creates one retro batch per
timecard.
Validate for BEE(Retro)

As the name suggests, this process picks up only retro batches and validates them for setup.
Only when Validated without errors can retro batches be transferred.
Transfer to BEE(Retro)
This process moves validated retro batches to BEE. Batches are created with source OTM are
created in Unprocessed status.
BEE Batch Process

BEE Batch Process, which can be initiated from the BEE Batch Summary screen or directly as a
concurrent process picks up the batches mentioned and moves them over to Payroll Element
Entry. Time data created in Element Entry is further processed by Payroll application.
Batches transferred from BEE to Element Entry have the status Transfer.

Rollback options prior to R12.1.5

BEE Batch Process (Rollback)
This program can be used to Rollback any batch from Element Entry back to BEE. Batches rolled
back thus come back to BEE in status Unprocessed and can be transferred again to Element
Entry with or without changes.
Rollback BEE
This program owned by Time and Labor can be used to Rollback OTLR (batch source: OTM) from
BEE back to OTLR module. Process only considers batches which are in BEE with status
UnProcessed and does not consider any retro batches. The process only works to rollback a
normal batch back to OTLR without any retro changes.
Gaps in the existing flow

The current process flow of time from OTL to Payroll Element Entries involves the BEE interface.
While some flexibility of adjusting time is possible because time moves from OTL to Element
Entry in Batches, some business cases require a more versatile option to rollback time/batches
of timecards from BEE. The following simple cases require a more flexible option to rollback
time.
A batch having Non OTLR timecards moved to Element entry can only be rolled back as
much as BEE thru the Application. If the rollback had to be done to pick up corrected
time or to fix some issue with the process, rerunning Xfer time from OTL to BEE does not
move the time again to BEE. The only way out here is to have the timecards updated
again and move time to BEE again as two batches ( Changed batch, retro batch for
earlier batch) and then process only the Changed batch. This clearly is not the
expectation from a complete rollback option.
An OTLR timecard having one or more retro changes thru retro batches cannot be rolled
back thru the application at all because Rollback BEE process does not rollback retro
batches or batches having further retro changes
An OTLR timecard can never be rolled back to OTL from OTLR module. This poses a big
problem if the rollback is required because of wrong setup in OTLR rules evaluation.
A few hundred timecards included in one single batch requiring a rollback would mean
all of the timecards being touched again, which makes it difficult for self service users.
Setups blocking update of a timecard once approved have a deadlock if for some reason
the timecards have an issue in BEE and need to be rolled back.

Why Rollback?
Conventionally transfer of time from Time entry systems to payroll involve moving a large
number of timecards entered periodically at predefined dates usually around end of payroll
periods. In transfer process from OTL to Payroll there are more than one programs to be run
for the corresponding applications and there are more than one interfaces. A
manual/programmatic/data error could happen in any of the multiple steps and could require a
business reason to reverse whatever was done and start all over. There could be multiple
scenarios which actually cause the error in data in Payroll, and could be multiple different
stages of rollback
Rollback Method
The business reason to rollback requires time data which is currently in Payroll/BEE to be
removed from Payroll/BEE and a method to get the data correctly back into Payroll later, after
the errors are fixed. Ideally an efficient rollback requires wrong data that is posted on the
Payroll tables to be cleared off so that right data can be transferred consequently. However,
there might be business cases where data cannot be removed completely from Payroll tables
because some or all of it are already processed and would not allow modification. A common
scenario of this kind is where there are a group of employees processed in one batch, and one
or a few employees data has to be rolled back. This may or may not be because of user errors
but the objective is to keep the correct data untouched and modify only the wrong data. With
the diverse requirements in consideration, the Rollback Framework allows two types of rollback
methods. Both the methods are available for OTLR and Non OTLR employees.
Rollback by deleting batch lines: OTLs processes (OTLR and Non OTLR) are equipped to
populate data into BEE as batches from sources Time store and OTM. These batches are
moved to Element Entry for payroll processing by BEE Batch Process. As mentioned
before, BEE Batch Process has a rollback option, which can be run to pull back the
batches into BEE. OTL Rollback Framework now allows to delete the lines in part or as a
whole of the batch ( as per business requirement). This kind of rollback completely
removes the entries made by OTL timecards in BEE and equips the administrator to run
the Transfer processes again to a new batch. This is the most complete and most
desirable method of rollback and is recommended by OTL application.
Rollback by creating Reversal batches: This approach has to be taken only if the business
case demands it. There are instances where the batch is processed from BEE to Element
Entry and cannot be rolled back to BEE using BEE Batch Process (Rollback). To name a
few, the reasons could be that Payroll processes have all been run and cannot be
10

reprocessed, or that there could be hundreds of employees in the batch and rollback
may be need only for a few of them, or that the time consumed for rolling back all of the
employees data and reprocessing them might not be desirable. For all the above
reasons, the already created batch cannot be touched. So, the application allows
creation of a reversal batch for the selected lines to negate the time already sent for the
employees with the problems. The link between the original batch and the timecard is
broken and the timecard can be retrieved again in a fresh batch. The following example
may be used to understand the method.
Timecard entered like below.
1-Jan 2-Jan 3-Jan 4-Jan 5-Jan 6-Jan 7-Jan

Regular 8 8 8 8 8
This is transferred to BEE in batch JANFirstWeek. When queried up in BEE, the batch lines for
the employee are like below.
Date Name Element Hours

1-Jan Person1 Regular 8
Lets say the timecard is updated like below, with Mondays hours changed to 9 hours.
1-Jan 2-Jan 3-Jan 4-Jan 5-Jan 6-Jan 7-Jan

Regular 9 8 8 8 8
This change is transferred to BEE in batch JANFirstWeek-Change.
11

Two batches will be created in BEE, like below.
JANFirstWeek-Change_Retro_xxxx_1

1-Jan Person1 Regular -8
JANFirstWeek-Change_XXX_1

When queried in BEE/Element entry for this employee for the week, irrespective of the batches,
the following records are present.
Date Name Element Hours Batch

1-Jan Person1 Regular 8 JanFirstWeek
1-Jan Person1 Regular -8 JanFirstWeekChange_Retro
1-Jan Person1 Regular 9 JanFirstWeekChange
This is a total of 41 hours for the week.
Lets say at this point user would like to rollback all details for this timecard.
There are 3 batches in question here, and all of them are in process Transferred. The lines
cannot be deleted because they are in Element Entry. Here we would use the negative entry
batch method to rollback the entries in BEE.
12

Three batches would be created as follows.
Reversal-JANFirstWeek (Reversal batch for JANFirstWeek)

Reversal-JANFirstWeekChange_RETRO_xxxx_1 (Reversal batch for JANFirstWeekChange_Retro)

Reversal-JANFirstWeekChange

When queried in BEE/Element Entry for the given week, irrespective of batches, the following
data is returned.
Date Name Element Hours Batch

1-Jan Person1 Regular -8 JanFirstWeekChange_Retro
1-Jan Person1 Regular 9 JanFirstWeekChange
1-Jan Person1 Regular -8 Reversal-JanFirstWeek
1-Jan Person1 Regular 8 Reversal-JanFirstWeekChange_Retro
1-Jan Person1 Regular -9 Reversal-JanFirstWeekChange
13

Now total hours for the week, and each day of the week for the person in BEE/Element Entry is
0.
Effectively, this is a logical rollback of all hours that has gone into Payroll.
Extent of Rollback
A typical timecard can be retrieved multiple times to Payroll based on the number of
adjustments the employee makes to the timecard. For instance the timecard entered for the
first week of January may be retrieved to Payroll at the end of the week. On the following
week, if the employee modifies the timecard, it may be retrieved on the following week too, in
a different batch. At this point there are in all 3 batches that the employees time is in BEE and
Element Entry. A rollback might be required because of a data problem ( in this case all the
batches may have a problem) or a process issue in Xfer time from OTL to BEE( in this case the
second run of the concurrent program may be the only faulty step). So, at any point of time,
the administrator who is running the rollback option needs to evaluate the business reason to
arrive at a decision on whether to rollback everything that is present in Payroll for that
employee and timecard period, or to rollback specifically the last run that happened. The
option to choose either mode is provided with all the concurrent programs in the OTL rollback
Framework. However, an option is provided only to rollback either all details for the timecard,
or the latest transferred entries. Any option in between the above are not allowed.
Eg.
Employee enters time for 40 hours for first week of Jan.
Time transferred to BEE in batch JanWeek1-1.
Employee modifies time to 45 hours for the same week.
Time transferred to BEE in batch JanWeek1-2 and JanWeek1-2_RETRO.
Employee again modifies time to 50 hours for the same week.
At this point, if a rollback is required, the application provides an option to Rollback all
the batches(JanWeek1-1, JanWeek1-2, JanWeek1-2_RETRO,JanWeek1-3, JanWeek1-
3_RETRO). The timecard can now be retrieved as a fresh new batch.
14

The second option available is to rollback the last run, which means JanWeek1-3 and
JanWeek1-3_RETRO can be rolled back.
There is no option available to rollback and intermittent batch in this case JanWeek1-2
and JanWeek1-2_RETRO cannot be rolled back standalone.
Once the last run is rolled back, users cannot invoke the process again to rollback
another set. After a last run rollback or a specific detail rollback, only rollback of all
details are permitted.
Validate Option
All programs in the OTL Rollback Framework are equipped with an option to run in Validate
only mode. When run in Validate only mode, the program completes the whole Rollback
process but does not commit the database session. A complete process log and output of
results are available in Validate Only mode. This option gives the users the flexibility to validate
the results of the process before actually carrying out the rollback activity.
Dependent Batches
While transferring timecards which are already transferred once, the system creates a retro
batch automatically for negating the previously transferred batch.
Eg.
Employee enters time for 40 hours for first week of Jan.
Time transferred to BEE in batch JanWeek1-1.
Employee modifies time to 45 hours for the same week.
At this point, JanWeek1-2 and JanWeek1-2_RETRO are dependent on each other because
without each other the time in BEE is imbalanced. It is imperative that user cannot be given an
option to rollback one without the other. The presence of dependent batches may not always
be known to the user, and may rollback a single batch without the dependent batch. To avoid
such a situation, the programs are built in with validation to take care of the dependent batches
when one is present.
15

OTLR and Non OTLR Timecards

Transfer time from OTL to BEE process does the dual job of transferring time from OTL to BEE
for Non OTLR timecards and transferring time from OTL to OTLR for OTLR timecards. The
process internally handles fetching the setup for Rules Evaluation preference and moving the
timecards to the appropriate destinations. However, the batches are created separately even
though they are created by one process. They also have different batch source OTM and
Time Store for OTLR and Non OTLR respectively.
The rollback Framework however deals the OTLR and Non OTLR timecards separately because
of the following reasons.
OTLR timecards have a tight integration with Payroll and Payroll periods, irrespective of
timecard periods. Eg. A user may have weekly timecard period in OTL, and may submit
approve and retrieve timecards weekly to OTLR. However, if the payroll is monthly, all
that calendar months time would go into the same timecard. In other words, the
timecards as viewed and processed in OTLR share the payroll periods, irrespective of the
timecard period in OTL. Since the timecard in OTLR is dependent only on payroll period,
and since timecards cannot be rolled back partially, the OTLR timecards have all to be
spotted by payroll periods rather than OTL timecard periods. It is unnecessary for Non
OTLR timecards to be prompted for Payroll period.
OTLR timecards batches are created with batch source OTM, where as Non OTLR
timecards batches are created with batch source Time Store. For all practical purposes,
batches are well defined and can be handled separately. Time Store batches having
multiple payrolls and payroll periods data can be handled together if the rollback
handles Non OTLR employees separately.
As a result of this segregation, Non OTLR employees and OTLR employees need to be handled
separately in the Rollback procedure. The most important impact for this behavior is that for a
single request of Transfer time from OTL to BEE to be completely rolled back, OTL: Rollback Non
OTLR timecards and OTL: Rollback OTLR timecards need to be run separately.
Rollback Eligibility
Can all timecards be rolled back ?
The application collects and stores relevant information during Timecard Submission, Approval
and Retrieval for Rollback framework to efficiently execute. As a result, only timecards created
after the Rollback framework is installed can be rolled back. The process has built in validation
to stop any timecard that was created before the Rollback Framework got installed to be
rejected.
16

Deleted Timecards
Can deleted timecards be rolled back ?
A timecard may be deleted after it is retrieved to BEE based on the preferences setup. Such a
timecard cannot be rolled back to OTL. Rolling back requires data to be made available for
retrieval again, but since the timecard itself is deleted already the application is at a deadlock to
execute the rollback. Hence this action is not permitted. Example below.
Timecard entered for 40 hours.
Timecard transferred to BEE in Batch1.
Timecard deleted from OTL.
At this point, if OTL: Rollback Non OTLR timecards is executed, this deleted timecard
would not be available for rollback.
Timecards overwritten with Templates

A template overwrite is equivalent to deleting a timecard and entering a new one. In such
scenarios, only the last version of the timecard can be Rolled back.
Eg.
Timecard created for 40 hours.
Timecard transferred to BEE in Batch1.
Timecard is edited in OTL and overwritten with a template for 45 hours.
Timecard is transferred again to BEE in Batch2.
At this point, running OTL: Rollback Non OTLR timecards lets the Admin rollback only Batch2.
Selecting Rollback All details for Rollback Mode would rollback only the latest version of the
timecard.
17

Naming Conventions for Reversal Batches

Reversal batches are created for Rollback process if the user opts for that method and the
batches to be reversed are in status Transfer in BEE. Lines pertaining to the spotted timecards
cannot be deleted from such batches, and a reversal batch needs to be created to negate the
entries. Reversal batches follow the naming convention REV_XXXX_YYYY where XXXX is the
batch_id of the batch being reversed and YYYY being the concurrent request id for the Rollback
process.
Eg.
Timecard created for 40 hours for 10 employees, Emp1 to Emp10.
All timecards transferred to BEE in batch Batch_A, having batch_id 1234.
Batch_A transferred to Element Entry, and currently has status Transfer in BEE.
At this point, Admin initiates OTL: Rollback Non OTLR timecards for Employee, Emp1
and Emp2 with concurrent request id 301.
o Rollback Mode: Rollback Specific Details
o Transferred Batch Action: Create Reversal Batch
After the process completes successfully, a new batch REV_1234_301 is created in

Unprocessed status, having negative entries to reverse the time in batch Batch_A for
Emp1 and Emp2.
Admin again initiates OTL: Rollback Non OTLR timecards for Employee, Emp7 and Emp8
with concurrent request id 302.
Rollback Mode: Rollback Specific Details
Transferred Batch Action: Create Reversal Batch
After the process completes successfully, a new batch REV_1234_302 is created in

Unprocessed status, having negative entries to reverse the time in batch Batch_A for
Emp7 and Emp8.
As mentioned in the above example, new reversal batches are created each time the Rollback
process needs to create reversal entries, irrespective of already existing reversal batches. If
18

multiple employees time are rolled back in multiple concurrent requests, each concurrent
request creates a new reversal batch.
To find out the reversal batches for a given batch, BEE may be queried with a wild card for
batch names starting with REV_XXXX_%, where XXXX is the batch id.
Status of Reversal Batches

New reversal batches created by the process are all going to be in status Unprocessed. It is
users responsibility to move the batches to element entry.
Status of Batches touched by Rollback Process

OTM or Time Store batches that are touched by Rollback Process (lines from these batches may
be deleted by Rollback programs) are not updated by the programs even though they are
empty. For a given timecard, when requested for a rollback, the process just deletes the lines
in the batches subject to the status conditions. At the end of rollback even if the batches are
empty, the headers are left free by the program. It is expected that the Admin later purges
them as required.
Replacement Batches for OTLR timecards

Each payroll period has one specific batch for a group of employees, controlled by the profile
option HXT_BATCH_SIZE. Conventionally, there are hundreds of timecards included in one
specific batch. When rolling back a single timecard from this batch, a new replacement batch
is provided for the timecard being rolled back, so that the existing timecards not requiring a
rollback are not touched.
A replacement batch is named as REP_XXXX_YYYY where XXXX is the batch id of the batch
being replaced and YYYY is the concurrent request id of the rollback.
Eg 1.
Timecard for 100 OTLR employees, Emp1-Emp100 created in OTL.
Transfer time from OTL to BEE invoked, which creates the respective timecards in OTLR
under batch BATCH_A, batch_id 1234. HXT_BATCH_SIZE is set as 100, and hence all
timecards fall into one batch.
Validate for BEE and Transfer to BEE run for the batch BATCH_A.
Status of the batch in BEE is Unprocessed.
19

At this point, Admin decides to rollback time for one employee Emp10, and invokes OTL:
Rolllback Batches for BEE with employee name parameter and concurrent request id
301.
After process completes successfully, querying Emp10 in Entry/Validation/Approval

screen shows that it is now attached to a new batch REP_1234_301. Status of the
timecard is Hold.
The existing batch BATCH_A now has 99 employees time and all timecards are still in
Transferred to BEE status in OTLR.
Eg 2.
Timecard for 100 OTLR employees, Emp1-Emp100 created in OTL.
Transfer time from OTL to BEE invoked, which creates the respective timecards in OTLR
under batch BATCH_A, batch_id 1234. HXT_BATCH_SIZE is set as 100, and hence all
timecards fall into one batch.
Validate for BEE and Transfer to BEE run for the batch BATCH_A.
From BEE Summary Screen, BEE Batch Process is run for BATCH_A, and the status of the
batch in BEE is Transfer.
At this point, Admin decides to rollback time for one employee Emp20, and invokes OTL:
Rolllback Batches for BEE with employee name parameter and concurrent request id
302.
o Transferred Batch Action : Create Reversal Batch
After process completes successfully, querying Emp20 in Entry/Validation/Approval

screen shows that it is now attached to a new batch REP_1234_302. Status of the
timecard is Hold.
The existing batch BATCH_A now has 99 employees time and all timecards are still in
Transferred to BEE status in OTLR.
A new reversal batch is created to Negate the lines for Emp20 in BEE. This batch is
named REV_1234_302.
20

Please note that both Replacement and Reversal batches are created in this scenario. A
reversal batch is to negate the already transferred entries where as a Replacement batch is to
process the timecard again to BEE.
Errors in Rollback Programs

All rollback processes are equipped to handle data integrity wherein only complete timecard
Rollbacks are committed to the system. If a particular process is supposed to handle 100
timecards, a database commit is issued only after processing each complete timecard. In case
the process errors out midway while processing the 31st timecard, the first 30 timecards would
have been completely rolled back. The process can be restarted after fixing the errors.
For OTLR Rollback process OTL: Rollback Batches from BEE such a scenario results in automatic
creation of a replacement batch as a fallback mechanism. This is made clear by the following
scenario.
Eg.
100 timecards included in batch Batch_A.
Batch_A transferred to BEE, now the timecard status in E/V/A screen is Transferred to BEE.
At this point Admin invokes OTL: Rollback Batches from BEE for Batch_A.
Each successfully Rolled back timecard is attributed to a new replacement batch

REP_1234_301.
After all timecards are successfully rolled back, timecards are updated back with Batch_A.
In case the process errors out midway, say after processing 40 timecards, the 40 rolled back
timecards would be included in REP_1234_301 in status Hold, while the rest of the timecards
would still be in Batch_A, in status Transferred to BEE.
21

Manual Changes in BEE Changes to Hours from OTL

Batch line hours transferred to BEE can be manually edited in BEE to change the number of
hours.
Eg. 8 hrs entered for a timecard in OTL can be transferred to BEE, and could be changed from
there to 9 hours.
When such a batch is reversed from Unprocessed state, there is no impact because the line is
going to be deleted, and there is no impact in payroll. The manual adjustment is lost anyway.
When such a batch is reversed from Transferred status, there should be no impact because the
Reversal Batchs line should now hold -9 hours including the manual adjustment done.
Manual Changes in BEE New entries in OTLs batches in BEE

This rollback process framework does not cover any new entry made in BEE. Such entries will
remain in BEE unless manually deleted.
Manual Changes in OTLR Entry/Validation/Approval screen

Often Administrators make changes to timecards retrieved to OTLR in
Entry/Validation/Approval screen before they are moved to BEE. These changes may be
adjustments to existing details or completely new entries. When requesting a rollback for a
timecard entered in OTL(Time Store) and transferred to OTLR and BEE back to Time store, the
system presents a parameter to control such time entries. The parameter Action on Changes in
OTM for OTL: Rollback OTLR timecards can be set to Error out (to stop processing such
timecards) or Delete manual entries (to delete all manual changes in Entry/Validation/Approval
Screen).
Accommodating Latest Changes in OTL

Latest changes in the timecard are always accommodated in all Retrieval processes and this
behavior will have no change.
Eg.
Timecard created with 40 hours in OTL.
Transfer time from OTL to BEE run to create the batch in BEE.
22

Timecard now modified to have 50 hours in all.
Rollback process executed for the already transferred batch.
o Process either deletes the batch lines or reverses it with a replacement

batch for 40 hours.
Running Transfer time from OTL to BEE process transfers 50 hours which is the
latest data in OTL.
The 40 hours once rolled back is not transferred again after it is adjusted in OTL.
BEE IV Upgrade
BEE IV Upgrade is an option available in Payrolls Generic Upgrade mechanism. Prior to BEE IV
Upgrade, all input values created by interfacing applications in BEE are stored in display format.
Input values are all stored in Character type columns. If a given Oracle implementation hasnt
executed BEE IV Upgrade, all time values are stored in BEE tables in display format. Eg. 8.25.
If the user running Transfer time from OTL to BEE has a Numeric Character setting of 10.000,00,
which uses a , for a decimal character, the data gets stored in BEE tables as 8,25 instead of
8.25. This poses the following problem in certain Rollback scenarios as described below.
Users enters 8.5 hours in OTL.
Admin user with Numeric Character setting of 10.000,00 runs Transfer time from OTL to
BEE process.
Batch line created with Input Value for Hours as 8,5.
Batch transferred to Element Entry.
Rollback Program is initiated with Transferred Batch Action parameter set to Create
Reversal Batch from a user having numeric character setting 10,000.00 a . for
decimal character.
Program tries to negate 8,5 by multiplying it with -1, but errors with an ORA-6512
error because -8,5 is not a valid number in the current session.
It is desirable to ensure that BEE IV Upgrade is run to avoid this issue completely and for other
benefits of the Generic Upgrade Mechanism. Information about this is available in MOS Note:
561154.1. In case this is not an option, ensure that the batch is not in Transferred status in BEE
when a user with a different Numeric Character preference invokes OTLs Rollback processes.
23

OTL: Rollback Non OTLR Timecards
Screenshot
Description
This process is the rollback option for Transfer time from OTL to BEE process, for Non OTLR
timecards. This process has to be run to rollback any Non OTLR timecards either fully or
partially. The process is equipped to display an output which shows in detail all processed
timecards and how they are processed. All reversal batches are displayed in the output file.
Parameters Start Date to Person are used to spot the timecards and the rest of the parameters
determine the behavior of the rollback process. A description of individual parameters are
provided below. The program completes with a warning if at least one of the timecards
processed ends in an error during Rollback.
Parameters
Mode
o Validate Only: Runs the process in a Validate mode and displays all information
about how the Rollback would have processed. Does not actually execute the
24

rollback. The process can be run again and again in this mode with the timecards
not being rolled back, but results being validated
o Validate and Execute: Runs the process in a complete mode, finishing the
Rollback.
Start Date: Defines the date range for the timecard period. Only timecards falling
completely inclusive in the date range are picked up. Eg. If timecard starts on 1-january,
and start date specified is 3-January, the timecard will not be picked up.
End Date: Defines the date range for the timecard period. Only timecards falling
completely inclusive in the date range are picked up. Eg. If timecard ends on 1-january,
and end date specified is 30-December, the timecard will not be picked up.
GRE: Assignment Attribute
Organization: Assignment Attribute
Location: Assignment Attribute
Payroll: Assignment Attribute
Person: Employee who submits timecard
Rollback Mode:
o Rollback As Per Selection: When selected, the process rolls back the latest
retrieval that happened for a timecard, as per the details specified. For instance,
if a timecard for 1-Dec to 7-Dec is retrieved in a batch named DecFirst for the
first time. This timecard is subsequently modified and retrieved again in a batch
RetroDec for the second time. Right now, RetroDec is the latest batch on this
timecard, and only the latest change will be rolled back. At the end of the
Rollback process, the second change to the timecard will be eligible for retrieval
again. When this parameter is selected, the next set of parameters, like
Request, Batch etc would be made enabled to give the option to choose
specifics. If the timecards latest retrieval does not attribute to any of the
selected parameters, the timecard would not be rolled back.
o Rollback All Details: When selected, the process rolls back all the details of the
timecard ever transferred to BEE. In the above example, batches DecFirst and
RetroDec would be rolled back, and timecard as a whole will be eligible for
retrieval again. A transfer of this timecard subsequently result in the timecard
details moving to BEE as a fresh new entry. Selecting this parameter disables all
the following parameters like Request, Batch etc.
Concurrent Request: This parameter gives the option to select a certain request of
Transfer Time from OTL to BEE process.
Retrieval Transaction Code: Gives the option to select a Retrieval transaction code
entered on a specific Transfer time from OTL to BEE.
25

Batch Name: Gives an option to select one specific Batch Name to rollback.
Batch Reference: Gives an option to select a specific Batch reference to target a list of
batches.
Dependent Batch Action: Enabled only when Batch Name/Batch Reference is selected.
User has chosen to rollback one or more timecards, specifying a batch name. A detail
that got into one batch may or may not have a dependent batch. If the detail is getting
transferred to BEE for the first time, it is a fresh entry and there are no dependent
batches. If the detail was transferred previously and the specified batch transferred a
change to an already transferred entry, there is also a retro batch which transferred the
contra entry for the previously transferred measure. These are the dependent batches.
There are two options for users to choose if only one batch was specified and the
process encounters a dependent batch.
o Error Out: When a dependent batch is encountered, the process displays an
appropriate message and skips to the next timecard.
o Process Dependent batches: When a dependent batch is encountered, the
process reverses dependent batch lines too.
Transferred Batch Action: An ideal way of rolling back a batch from BEE is to delete the
line which was transferred to BEE by the timecard specified. While rolling back
timecards All or Latest, the process may encounter a batch which is still in Transferred
status in BEE ( Batch lines transferred to Element Entry). This parameter defines how
the process behaves in such a case.
o Error Out: When a transferred batch is encountered, the process errors out.
o Create Reversal Batch: A transferred batch line is reversed by creating retro
entries for the transferred lines, with ve hours.
Common Error Messages
System does not have enough details to Rollback this timecard: The timecard being
processed was created and transferred before the Rollback framework was installed. At
this point, the system does not have enough information about the timecard to execute
an effective rollback.
26

This timecard was transferred with OTLR rules YES at least once: The timecard being
processed was created and transferred at least once with OTLR option Yes and cannot
be processed with this program.
This timecard may be Archived and cannot be processed: The timecard being processed
is either partially or fully Archived using the Archive Data Set program and cannot be
rolled back.
Last Changes on this timecard were once rolled back. Rollback all details: The timecard
being processed is being requested to be rolled back with Rollback Mode value Rollback
as per selection. The latest retrieval on this timecard was once rolled back in this mode
and hence this action is not permitted. This timecard can only be rolled back by
Rollback All Details mode.
Batch &BATCHNAME- has Transferred status and we are not rolling back these: The
request was initiated with Transferred Batch action parameter set to Error out. The
batch currently encountered is in Transferred status in BEE and cannot be processed as
per the parameters chosen.
Batch -&BATCHNAME- is a dependent batch and we are not processing dependent

batches: The request was initiated with Dependent Batch Action parameter set to Error
out. The batch currently encountered is a dependent batch of the batch requested to
be rolled back. This action is not permitted as per the parameters chosen.
27

Understanding the Output File
Parameters
Timecard Details
28

Unprocessed batch, reversed by deleting lines
Transferred batch, reversed by creating

reversal lines
New Reversal batch created
29

OTL: Rollback OTLR Timecards
Screenshot
Description
This program is the rollback option for OTLR timecards for the process Transfer time from OTL
to BEE. The program also handles complete rollback of timecards transferred from OTLR to BEE
using Validate and Transfer processes. The driving parameters here are payroll and payroll time
period, which are used to converge on the timecards to be rolled back. The process creates an
Output file which displays the details of the timecard in OTLR before and after rollback. There
is also an option to define the extent of rollback, either from BEE to OTLR or BEE to OTLR to
OTL.
The program completes with a warning when at least one of the timecards processed
encounters an error.
30

Parameters
Mode
o Validate Only : Runs the process in a Validate mode and displays all information
o Validate and Execute : Runs the process in a complete mode, finishing the
Rollback.
Payroll: Since OTLR timecards are tightly coupled with a Payroll and Payroll period, this
is a mandatory parameter to spot timecards to rollback.
Time Period: When a payroll is selected, a payroll period has to be selected to spot the
timecard.
GRE: Assignment Attribute
Organization: Assignment Attribute
Location: Assignment Attribute
Person: Employee who submits timecard
Batch Reference: Option to choose a specific batch reference to spot the timecards.
Batch Name: Option to choose a specific batch name to spot the timecards. These
batches are not retro batches, but the actual batch that the timecard was first created in
BEE.
Transferred Batch Action: An ideal way of rolling back a batch from BEE is to delete the
line which was transferred to BEE by the timecard specified. While rolling back
timecards All or Latest, the process may encounter a batch which is still in Transferred
status in BEE ( Batch lines transferred to Element Entry). This parameter defines how
the process behaves in such a case.
Rollback Timecards to: A timecard in OTLR may be created in SS/TK/API and transferred
to OTLR to have OTLR rules applied. Rolling back this timecard may require all the details
to be removed from BEE, and have them transferred fresh from OTLR. Or it may be
required to be rolled back completely out of OTLR back to OTL so that it can be
transferred to OTLR again and freshly exploded. Options are
o OTM
o Time Store
31

Action on Changes in OTM: This parameter is enabled only if Time Store is selected as an
option for the previous parameter. A timecard originally created in SS/TK/API and
transferred to OTLR with Transfer time from OTL to BEE is available in the
Entry/Validation/Approval screen for modification. There may be additions to timecards
entered in this screen. These details cant be rolled back to OTL.
o Error Out: When a timecard with a manual entry from E/V/A screen is
encountered, throw an appropriate error message and skip to the next timecard.
o Delete Manual changes in OTM: Delete any manual entry from E/V/A screen off
OTLR before rolling back the changes to OTL.
Error Messages
rolled back.
Batch &BATCHNAME- has Transferred status and we are not rolling back these: The
request was initiated with Transferred Batch action parameter set to Error out. The
batch currently encountered is in Transferred status in BEE and cannot be processed as
per the parameters chosen.
There are manual entries in OTM: The request was initiated with Action for Changes in
OTM parameter entered as Error out, and the timecard is being rolled back to Time
Store. Until these manual entries in OTM are deleted, this action is not permitted.
32

Understanding the Output file.
Parameters
Timecard Information
Timecard before Rollback
Batch Information
Timecard Post Rollback
33

OTL: Rollback Batches from BEE
Screenshot
Description
This program is the rollback option for Transfer to BEE process. The process is equipped with
the same parameters as the Transfer process to spot batches. The process handles only Normal
batches created from OTLR( not retro batches).
An additional option of rolling back only a single persons timecard is provided subject to
conditions as mentioned below. The process ends with a warning when at least one of the
timecards processed encounters an error.
Parameters
Mode
34

Rollback.
Starting Batch: A required parameter to choose the batch name to rollback. If a given
timecard is modified further with retro batches, it wont be available in the list.
Ending Batch: If a given timecard is modified further with retro batches, it wont be
available in the list.
Batch Reference: Batch reference for any batch that is transferred to BEE
Person: Gives an option for the user to rollback only one specific persons timecard from
the batch.
Transferred Batch Action: This parameter is available only if a person is selected. If a
person parameter is not selected, a batch is eligible for rollback only if it is in
Unprocessed.
Error Messages
Batch -&BATCHNAME- is Transferred. Transferred Batches cannot be rolled back

without specifying a person: The process is initiated for a batch which is in Transferred
status in BEE. A batch in Transferred status needs to be rolled back to BEE in
Unprocessed status before this program can be run. It can be run for a single person
even if the batch is in status Transferred, but a person name parameter should be
specified.
Batch -&BATCHNAME- is Transferred. Option selected is to Delete lines from Unprocessed

batches: The process is initiated with a person name parameter, but Transferred Batch Action
parameter is chosen as Error Out. The batch currently encountered has Transferred status in
BEE. This action is not permitted as per the options.
35

rolled back.
Understanding Output File

The output file for this program follows the same format as OTL: Rollback OTLR Timecards
program, mentioned above.
36

OTL: Rollback Batches from BEE(Retro)
Screenshot
Description
This program is the Rollback option for Transfer to BEE(Retro) process. This has the same
parameters as the Transfer program. The process is equipped to rollback only Retro batches
created from OTLR. The process completes with a warning when at least one timecard
encounters an error.
Rollback by creating Reversal batches is not allowed for this program because retro batches
usually are one each per timecard. If one particular retro batch has to be rolled back from BEE
to OTLR, it can be rolled back first from Element Entry to BEE by using BEE Batch
Process(Rollback), without affecting other timecards.
Parameters
Mode
37

Rollback.
Starting Batch: A required parameter to choose the batch name to rollback. Lists only
batches which are retro batches. If a timecard is further modified with multiple Retro
batches, the list would return only the last retro batch.
Ending Batch:
Batch Reference: Batch reference for any batch that is transferred to BEE
Error Messages
This batch is Transferred and need to be rolled Back from EE first: The process is
initiated to rollback a batch which is in Transferred status in BEE. BEE Batch
Process(Rollback) needs to be initiated to rollback this batch to BEE first before this
program is run.
rolled back.
Understanding Output File

The output file for this program follows the same format as OTL: Rollback OTLR Timecards
program, mentioned above.
38

Rollback applied on Non OTLR timecard flow
The diagram below represents a common timecard lifecycle with multiple updates and
retrievals to the timecard. The available rollback options are listed in the table that follows.
Timecard Lifecycle
Xfer time from OTL to BEE

Stage 1: Timecard Stage 2: Timecard
created Transferred to BEE
Stage 4: Timecard Xfer time from OTL to BEE

Stage 3: Timecard
Transferred to BEE Edited again in OTL
Stage 5: Timecard Xfer time from OTL to BEE

Stage 6: Timecard
Edited again in OTL Transferred to BEE
Rollback Options
Rollback Requirement Program to be used Rollback Mode

Stage 6 -> stage 1 OTL: Rollback Non OTLR Timecards Rollback All details
Stage 6 -> Stage 5 OTL: Rollback Non OTLR Timecards Rollback Specific Details
Stage 4-> Stage 3 OTL: Rollback Non OTLR Timecards Rollback Specific Details
Stage 2-> Stage 1 OTL: Rollback Non OTLR Timecards Rollback Specific Details
39

Rollback Applied to OTLR timecard flow

The diagram below represents a typical OTLR timecard lifecycle. The table that follows lists the
available options to rollback at different stages.
Timecard Lifecycle
Stage 1: Timecard Xfer time from OTL to BEE Stage 2: Timecard

created in OTL created in OTLR
Validate for BEE/Transfer to BEE
Stage 4: Timecard Stage3: Timecard

edited in OTL Xferred to BEE
Xfer time from OTL to BEE
Validate for BEE(Retro)/Transfer

Stage5: Timecard to BEE(Retro) Stage 6: Adjusted
Adjusted in OTLR TC xferred to BEE
Xfer time from OTL to BEE Stage7: Timecard

Stage8: Timecard
edited in OTL
adjusted in OTLR
Validate for BEE(Retro)/Transfer to BEE(Retro)
Stage9: Adjusted
TC Xferred to BEE
40

Rollback Options
Rollback Requirement Program to be used Options
Stage 2 -> Stage 1 OTL: Rollback OTLR Timecards Rollback Timecards To: Time Store
Stage 3 -> Stage 2 OTL: Rollback Batches From BEE
Stage 6 -> Stage 5 OTL: Rollback Batches from BEE(Retro)
Stage 6 -> Stage 2 OTL: Rollback OTLR Timecards Rollback Timecards To: OTM
Stage 9 -> Stage 8 OTL: Rollback Batches from BEE(Retro)
41

Common Rollback Scenarios

Scenario 1: Wrong Parameters
ABC Corporation has 1000 employees in US Business group. These employees are all paid in
two payrolls Full Time Payroll and Part Time Payroll based on their job description. Rules
evaluation is not opted for both payrolls.
Usually ABC Corps Time and payroll administrator runs two Xfer time from OTL to BEE
processes every Friday evening to move time from OTL to BEE, with batch references named
like FT-5-JAN-11 and PT-5-JAN-11. Usually they expect to see 5 batches for FT payroll, and 5
batches for PT payroll, with each batch having 100 employees.
One particular weekend, an oversight from the admin user made him miss out the payroll
parameter when he ran the Xfer process for the first time. As a result, the process created 10
FT batches instead of 5, and all 1000 employees got into the FT batches. This would mess up
the rest of their calculations because they follow the process of maintaining separate payrolls in
separate batches. They noticed this issue when they got time moved to Element Entry.
Fix:
Since the batches are in Element Entry, the first step is to run BEE Batch Process
(Rollback) and get the batches out of Element entry. Ideally they should remain in
Unprocessed status in BEE for OTL to Rollback them completely.
Since they are not using OTLR, the Admin need to use only OTL: Rollback Non OTLR
timecards process.
There are two ways in which this can be done, either rollback the whole process and
transfer freshly again, or rollback only those timecards belonging to PT payroll only and
process them again.
For first approach, Admin needs to run OTL: Rollback Non OTLR process using the
following parameters
o Appropriate Start and End Date
o Retrieval Transaction Code: Appropriate transaction code entered for Xfer time
from OTL to BEE job, FT-XXXXX
o Request Id: Appropriate Request id

42

o Batch Reference: Appropriate batch reference as entered for Xfer time process.
Note: Either of Retrieval Transaction Code, Request Id and Batch reference will
take care of rolling back the timecards. They are not all mandatory parameters.
At this point all the 10 batches having Batch reference as FT_XXXX will be
emptied in BEE. The timecards are now eligible to be retrieved again. These
empty batch headers may all be purged later.
For the second approach, Admin needs to run OTL: Rollback Non OTLR timecards for the
following parameters.
o Payroll: Part Time Payroll( to locate only the part time employees)
Note: Either of Retrieval Transaction Code, Request Id and Batch reference will
take care of rolling back the timecards. They are not all mandatory parameters.
At this point, all employees having Part Time payroll, would have the
corresponding time data deleted from the batches. The process does not touch
the batch headers, but the batch lines in them would be deleted for the filtered
employees. Currently, the batches under FT_XXXX reference would not have any
PT employee, and even some of them may be empty. Admin may purge the
empty batches.
The timecards for PT employees are now ready for retrieval again. Running
them with the correct payroll and appropriate batch reference would create the
PT batches.
43

Scenario 2: Missing Time

ABC Corp requires employees who work in night shift to enter a night shift premium in their
timecards to be approved by their managers. This has to be entered on the same week as they
work in Night shift so that it can be paid promptly. Some of the new employees did not know
this and forgot to enter the Night shift premiums. The Admin finds out about this after all the
employees time reached Element Entry. Now he has two employees for whom he needs to
rollback time and reprocess correctly.
Fix:
Since only two employees are affected, the admin decides that he is going to leave the batches
in element entry and do without the BEE Batch Process (Rollback). The following steps need to
be done.
Run OTL: Rollback Non OTLR timecards with the following parameters.
o Person: The affected Employees name.
o Batch Name: Appropriate batch name from the list of batches created. Pls note
that all the parameters are not required.
o Transferred Batch Action: Create Reversal batch. Since the batches are all
transferred to Element Entry, the system needs to create a reversal batch to
negate the entries.
After the process completes, a new reversal batch would be created of the name
REV_XXXX_YYYY where XXXX is the batch id of the batch targeted and YYYY the
request id of the rollback process. REV_XXXX_YYYY would not reverse the entire
batch, but only the lines belonging to the said employee. The employees
timecard can be retrieved in a subsequent process. The new batch created and
44

REV_XXXX_YYYY batch needs to be transferred to Element Entry using BEE Batch

Process.
Scenario 3: Usage Errors

One of ABC Corps employees needed to correct the timecard for previous week because of
some correction to overtime hours. He had a timecard having 40 hours regular and 5 hours
overtime. He was required to have only the regular time. However the employee made a
mistake of deleting the 5 hours overtime and also adding a -5 hours to adjust the mistake
already made. The application is supposed to handle this internally and a manual retro entry
messes up calculations. However, this was not found out and the timecard was transferred to
payroll and processed. Weeks later, this came to the attention of the employee and
administrator, but not before multiple corrections had been done on the timecard in this way.
The employee needed to correct the timecard, but the time in payroll also has to be rolled
back.
Fix: Since this involves only one employee, the admin has to decide that batches as a whole are
not going to be rolled back from Element Entry to BEE. OTL: Rollback Non OTLR timecards
needs to be run with the following parameters.
o Person: The affected Employees name.
o Rollback Mode: Rollback All Details
o Transferred Batch Action: Create Reversal batch. Since the batches are all
transferred to Element Entry, the system needs to create a reversal batch to
negate the entries.
After the process completes, all of the time data moved to BEE in multiple
batches would have been rolled back. All reversal batches would be called as
REV_XXXX_YYYY, where XXXX is the original batch being reversed and YYYY the
concurrent request id of the rollback process.
45

Scenario 4: OTLR Preference error
ABC Corp has 100 contracted employees who are Non exempt and needs to have OTL Rules
evaluation setup done. The preference for OTLR is set at responsibility level. Due to some
mistake, the preference was not set correctly, and it was found out later that these 100
employees had their time reach BEE directly without going thru OTLR module.
Fix:
Since the wrong data is in BEE and has gone thru the Non OTLR path, the admin needs to run
OTL: Rollback Non OTLR timecards. The appropriate period and payroll has to be chosen and
the request should be verified for completion.
Scenario 5: Wrong setting in HXT_TIME_VALIDATION for new period.

HXT_TIME_VALIDATION lookup is used by OTL admins to define correctness of time data in
OTLR before moving time to BEE. This extensible lookup can be modified to set various
validations to Error/Warning/Skip level to define the behavior for Validate for BEE and Validate
for BEE(Retro) process. Eg. Time entered over 24 hrs on a day may or may not be termed as a
validation error/warning by setting appropriate valiation level in the lookup.
ABC Corp had a organization level policy change where time entered over 24 hrs is no longer
allowed. The change was supposed to come into effect on 1-Jan-12, but delays in process made
the changes applicable to the lookup only a week later. As a result, the time in first week of
january got thru to BEE without the right validation in Validate for BEE process. Now this time
has to be rolled back.
Fix:
* Since the whole batch has to be rolled back, admin has to first invoke BEE Batch
Process(Rollback) to bring the batches back to BEE.
* Admin has to run OTL: Rollback batches from BEE with the appropriate batch parameters to
rollback the time from BEE back to OTLR module.
* Transferred Batch action should be set to the default value Error Out because the batches are
ideally expected to be in Unprocessed state.
* Validate for BEE has to be run again to validate the time again and then later transfer to BEE.
46

Scenario 6: Wrong setting in HXT_TIME_VALIDATION for older period.
For the same scenario above, for a couple of their payrolls, ABC corp could not spot the issue
soon enough. By the time the issue was spotted, the timecards had been transferred to BEE
and then to Element Entry and a few retro batches had also been transferred to BEE.
At this point, ABC Corp wants all the time to be rolled back to OTLR and freshly moved to BEE
with the right validations.
Fix:
Since this involves all the employees in the payroll, admin has to first invoke BEE batch
process(Rollback) to bring all the batches - initial as well as retro batches -- back to BEE
in unprocessed state.
Admin has to run OTL: Rollback OTLR timecards with the following parameters.
o Payroll : Appropriate Payroll has to be selected.
o Time Period : Once payroll is selected, time period is available to choose.
o Batch Name: The LOV for Batch name is activated once the time period is
selected. The batch selected should be the initial batch that the timecard is
associated to ( Retro batches do not appear in this LOV).
o Transferred batch action : Default Value, Error out
o Rollback Timecards to : OTM
The process deletes all lines in all the normal and retro batches for all employees in the
given payroll and payroll period. All located timecards are now attached to a new batch
called REP_XXXX_YYYY where XXXX is the original batch id and YYYY is the concurrent
request id of the process.
The batch REP_XXXX_YYYY can be Validated and Transferred to BEE now.
The remaining batch headers must be purged.
47

Scenario 7: Input Value issue in Transfer to BEE(Retro) process.
ABC Corp has to have 3 input values associated with time namely Rate, Effective Date and
Factor. However, it was found out that because of an unintended change in input value order,
Rate values got into Factor IV position. This has affected only Xfer to BEE(Retro) process.
Fix:
Since this involves retro batches( one batch per timecard) all affected retro batches
have to be rolled back from Element Entry to BEE. BEE batch process(Rollback) to be
used here.
Next Admin has to invoke OTL: Rollback batches from BEE(Retro) for the range of
batches.
After the process completes successfully, the IV errors can be fixed and Validate for
BEE(Retro) can be ran follwed by Xfer to BEE(Retro) to complete the process correctly.
Scenario 8: Missed Merge batches step in Validate for BEE(Retro).
ABC corp usually merges all retro batches for a payroll period and processes them together.
However, a usage error resulted in merge batches parameter being missed out in Validate and
Xfer to BEE(Retro) processes. Now there are 100 retro batches in BEE instead of one and is
messy for the admin to handle later.
Fix:
Since batches are in BEE, the status is good enough for OTL Rollbacks.
Admin has to invoke OTL; Rollback Batches from BEE(Retro) for all the 100 batches with
a batch range.
Once the process completes, Admin can run Validate for BEE(Retro) with Validate
option.
48

Scenario 9: Validation issues for a small group of employees.
ABC Corp has 500 employees in OTLR and has OTL: Transfer Batch Size and
HXT_TRANSFER_BATCH_SIZE set to 100, meaning they expect 5 batches per payroll period. For
a particular payroll period, it was found that 5 employees had wrong time in Element Entry
because of wrong validations in HXT_TIME_VALIDATION lookup. Since other employees are not
affected, there is no point in bringing everything back like scenario 5 above.
Fix:
Since the batch status is Transferred in BEE, the rollback has to be taken care of with
reversal batches.
OTL: Rollback Batches from BEE lets the user select a person and allows a rollback by
creating a reversal batch. Admin has to invoke this for each of the five employees.
Lets say currently there are 5 batches out there, named like NON_XEMPT_123(batch id
301), NON_XEMPT_124(batch_id 302) etc.
The five employees to be rolled back are in the first two batches.
Admin should invoke the process with the follwing parameters.
Starting Batch : NON_XEMPT_123
Ending batch : NON_XEMPT_123
Person : Ford, John
Transferred Batch action : Create Reversal Batch.
When process completes successfully, a new reversal batch REV_301_1001, where 1001 is
the request id.
When Entry/Validation/approval screen is queried for John Ford, it can be seen that now
the timecard is attached to REP_301_1001.
49

The same process has to be repeated for the rest of the employees.
Person : Metcalf, Laurie
When process completes successfully, a new reversal batch REV_302_1002, where 1002 is the
request id.
When Entry/Validation/approval screen is queried for John Ford, it can be seen that now the
timecard is attached to REP_302_1002.
Eg.
Person : Glover, Mike
When process completes successfully, a new reversal batch REV_301_1003, where 1003 is the
request id.
When Entry/Validation/approval screen is queried for John Ford, it can be seen that now the
timecard is attached to REP_301_1003.
Scenario 10: OTLR Preference setup issue
Like scenario 4, a preference evaluation setup error can cause Non OTLR timecards to reach
OTLR module.
In this case, Admin has to invoke OTL: Rollback OTLR timecards for the following parameters.
50

Payroll : Appropriate
Time period ; As appropriate
Rollback timecards to : Time Store
Action On Changes in OTM : Delete OTM Changes.
Scenario 11: Incorrect OTLR Setup - Fresh period.
ABC Corp had a policy change which required Hour Deduction Policy of 1 hour per 8 hours to be
applied. Though it was supposed to be applied from the first week of the year, the setup was
not done at the right time. As a result Non exempt employees' time got into OTLR and from
there to BEE. When the issue was spotted, it was found out that for the given pay period, all
the timecards had to be re exploded.
Fix :
Since all employees are affected, Admin must ensure that the Batches in BEE have
status Unprocessed. If not, BEE batch process(Rollback) has to be invoked to bring
batches back to unprocessed state.
Admin has to invoke OTL: Rollback OTLR Timecards with the following parameters.
o Payroll : As appropriate
o Time period : As appropriate
o Rollback Timecards to : Time Store
o Action on Changes in OTM: Delete changes in OTM
o Transferred Batch Action : Error out.
51

Scenario 12: Incorrect OTLR Setup retro period
In the above scenario 11, ABC Corp's policy change was supposed to work only from first week
of January. But an unintended mistake on the dates in Assignment Time Information made the
setup change effective from the last week of December. As a result the retro run on
December's last week had the setup change, which was not expected. Now ABC corp has a few
retro batches in last week of december which has wrong time data.
Fix :
Here the explosion change has affected the retro batches only. However, the explosion
changes cannot be rolled back partially for a given timecard. Here, admin has to rollback all the
timecards completely back to Time store and rerun transfer processes to get the right time.
All the appropriate batches have to be rolled back from Element entry to BEE as
required, using BEE Batch Process(Rollback)
Admin has to invoke OTL: Rollback OTLR timecards with the following parameters.
Payroll : As appropriate
Time period : As appropriate
Rollback Timecards to : Time Store
Action on Changes in OTM: Delete changes in OTM
Transferred Batch Action : Error out.
All the timecards targetted will now be cleared from OTLR. They can be retrieved once
again from Time Store and the right explosion can be obtained.
52

OTL Rollback For Payroll PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OTL Rollback For Payroll PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ORACLE CORPORATION

OTL: Rollback Framework

Oracle Time and Labor Development

Oracle Time and Labor Development

Understanding the Output file............................................................................................................ 33

Oracle Time and Labor Development

Oracle Time and Labor Retrievals Troubleshooting Guide [ID 749174.1]

Working knowledge of OTL Payroll timecard lifecycle.

Oracle Time and Labor Development

Stages in Payroll retrieval Non OTLR

Transfer time from OTL to BEE

Transfer time from OTL to BEE

User creates timecard with 40 hrs for the week.

User adjusts the timecard to have 45 hrs for the week.

Oracle Time and Labor Development

BEE Batch Process

Stages in Payroll Retrieval OTLR

Transfer time from OTL to BEE

Validate for BEE

Oracle Time and Labor Development

Validate for BEE(Retro)

BEE Batch Process

Oracle Time and Labor Development

Rollback options prior to R12.1.5

Gaps in the existing flow

Oracle Time and Labor Development

Oracle Time and Labor Development

Timecard entered like below.

1-Jan 2-Jan 3-Jan 4-Jan 5-Jan 6-Jan 7-Jan

Date Name Element Hours

1-Jan 2-Jan 3-Jan 4-Jan 5-Jan 6-Jan 7-Jan

This change is transferred to BEE in batch JANFirstWeek-Change.

Oracle Time and Labor Development

Two batches will be created in BEE, like below.

Date Name Element Hours

Date Name Element Hours

Date Name Element Hours Batch

This is a total of 41 hours for the week.

Oracle Time and Labor Development

Three batches would be created as follows.

Reversal-JANFirstWeek (Reversal batch for JANFirstWeek)

Date Name Element Hours

Date Name Element Hours

Date Name Element Hours

Date Name Element Hours Batch

Oracle Time and Labor Development

Employee enters time for 40 hours for first week of Jan.

Time transferred to BEE in batch JanWeek1-1.

Employee modifies time to 45 hours for the same week.

Time transferred to BEE in batch JanWeek1-2 and JanWeek1-2_RETRO.

Employee again modifies time to 50 hours for the same week.

Time transferred to BEE in batch JanWeek1-3 and JanWeek1-3_RETRO.

Oracle Time and Labor Development

Employee enters time for 40 hours for first week of Jan.

Time transferred to BEE in batch JanWeek1-1.

Employee modifies time to 45 hours for the same week.

Time transferred to BEE in batch JanWeek1-2 and JanWeek1-2_RETRO.

Oracle Time and Labor Development

OTLR and Non OTLR Timecards

Oracle Time and Labor Development

Timecard entered for 40 hours.

Timecard transferred to BEE in Batch1.