Oracle Time & Labor

Timecard Approvals – Overview and

Setups

Copyright © 2006 Oracle Corporation

All Rights Reserved
Copyright Information

Oracle Time and Labor, Releases 11i and 12

Copyright 2005 Oracle Corporation
All rights reserved.

Primary Author: Kris Van der Ploeg

Contributors: John Finnegan, Andrew Rundell, Alison Crabbe
Creation Date: 01-Mar-06
Last Updated: 03-Apr-06

This software was not developed for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It is the customer's responsibility to take all appropriate measures to ensure the safe use of
such applications if the programs are used for such purposes.
This software/documentation contains proprietary information of Oracle Corporation; it is provided under a license
agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering
of the software is prohibited.
If this software/documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is
delivered with Restricted Rights and the following legend is applicable:
Restricted Rights Legend Use, duplication, or disclosure by the
Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in
Technical Data and Computer Software (October 1988).
Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
If this software/documentation is delivered to a U.S. Government Agency is not for use within the Department of
Defense, then it is delivered with “Restricted Rights", as defined in FAR 52.227-14, Rights in Data - General,
including Alternate III (June 1987).
The information in this document is subject to change without notice. If you find any problems in the
documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error
free. No part of this document may be reproduced or transmitted in any form or by any means electronic or
mechanical, for any purpose without the express written permission of Oracle Corporation.
Oracle is a registered trademark and ConText, Enabling the Information Age, Oracle7, Oracle8, Oracle8i, Oracle
Access, Oracle Application Object Library, Oracle Financials, Oracle Discoverer, Oracle Web Customers, Oracle
Web Employees, Oracle Workflow, Oracle Work in Process, PL/SQL, Pro*C, SmartClient, SQL*, SQL*Forms,
SQL*Loader, SQL*Menu, SQL*Net, SQL*Plus, and SQL*Report are trademarks or registered trademarks of
Oracle Corporation.
All other products or company names are used for identification purposes only, and may be trademarks of their
respective owners.

Page 2
Table of Contents

1. Introduction ..................................................................................................................................................................4
1.1 Purpose of this Document....................................................................................................................................4
1.2 Intended Audience..................................................................................................................................................4
1.3 Definitions.................................................................................................................................................................4
2. Overview of OTL’s Approval Processing..............................................................................................................6
3. Approve On Submit ....................................................................................................................................................7
4. Time Categories ..........................................................................................................................................................8
4.1 Overview....................................................................................................................................................................8
4.2 Operators ..................................................................................................................................................................8
4.3 Empty Values ...........................................................................................................................................................9
4.4 Examples...................................................................................................................................................................9
5. Approval Methods.....................................................................................................................................................13
5.1 Auto Approve .........................................................................................................................................................13
5.2 Entry Level Approval............................................................................................................................................14
5.3 Formula (Selects Mechanism) ...........................................................................................................................19
5.4 HR Supervisor........................................................................................................................................................20
5.5 Person......................................................................................................................................................................23
5.6 Project Manager ....................................................................................................................................................26
5.7 Workflow .................................................................................................................................................................26
5.8 Combining Approval Methods...........................................................................................................................26
6. Approval Rules ..........................................................................................................................................................28
7. Override Approvers and Approval Styles...........................................................................................................33
8. Approval Periods of Different Lengths than Timecard Periods....................................................................34
9. Appendix – Document References & Further Reading ...................................................................................36

Page 3
1. Introduction

1.1 Purpose of this Document

OTL’s approval functionality is very flexible and powerful. It allows various workers’ timecards to be
approved in different ways, and even allows various time entries on a single timecard to be approved in
various ways. This document is intended help customers better understand how OTL processes timecard
approvals. It provides explanations of what options are available, and provides examples of how to
configure approval styles to match various business requirements.

A number of additional resources are also provided to assist OTL’s customers with their approval
configurations. This document does not replace or duplicate that information. Rather, it is intended to
provide an overview and some examples of OTL’s approval functionality, and to assist the reader to find
further reference materials.

1.2 Intended Audience

This document is intended to help customers who are unfamiliar with configuring OTL approval styles, or
who would like to better understand how OTL processes timecard approvals. It should also assist those
who have a variety of requirements for approving their timecards, or whose approval requirements are
complex and multi-faceted, to define approval styles that best suit their business’s needs.

NOTE: It is assumed that readers are familiar with OTL’s basic setups, such as defining recurring periods
and assigning preferences to workers, and with the Flexfield structures in Oracle eBusiness Suite. It is
further assumed that readers are familiar with Oracle FastFormula and Oracle Workflow if they are
attempting to use approval functionality that is dependent on FastFormula or Workflow.

1.3 Definitions

Approval Rules
Also known as Data Interdependency Rules, these rules allow you to define when timecard approvals
need to be processed in ways other than the workers’ default processing method under various
circumstances.

Approval Period
The period during which submitted time entries are to be considered for approval
The approval period may be of a different length than the timecard’s period.

Approval Style
The combination of approval rules and approval methods that defines who approves the worker’s
timecards for each recipient application in the worker’s application set, as well as which data need to be
approved for each application, and which updates to the timecard’s data require resubmission

Approval Style Component

Defines which approval method to use for data belonging to a particular application

Defer Approval Process on Timecard Submission

A profile option that allows the workflow approval process to run in the foreground
By default, this process runs in the background and requires the Workflow Background Process to be
running.
NOTE: This option may impact performance on a Production instance.

Entry Level Approval (ELA)

Allows timecard approvers to see only the time entries they are responsible for approving

Mapping Component

Page 4
Time entry attributes that relate to segments you have defined in the OTL Information Types Descriptive
Flexfield

Oracle Time and Labor (OTL)

Oracle Time & Labor is a single point of time entry for use by multiple applications that meets your time
entry needs for employees and contingent workers for the entire eBusiness Suite. OTL provides several
methods of time entry, including the ability for your workers to enter their own time. You can subject the
time entries to various approval processes, according to your business rules. All entered time is available
for retrieval by any of the applications that require your workers' data.

OTL Preferences
Rules that permit you, for example, to define how individual workers or groups of workers can use the
application, into which applications you will retrieve data about a worker's time, and whether or not your
timecard data requires approval

Override Approver
An approver other than the default approver as defined in the approval style
If an override approver is selected, the timecard is sent to this approver only, and the usual approval style
is not activated.
Recipient Application
An application other than OTL that consumes timecard data

Recurring Period
The length of the timecard’s period or of the approval period

Time Categories
Groupings of timecard data for reporting and identification of time to be analyzed by time entry rules or
approval rules
For example, you can define categories for particular projects, or for vacation, or for overtime.

Time Store
OTL's central repository where all time data is stored
The time store serves as a gatekeeper of time entry data to other Oracle applications.

Workflow Background Process

The concurrent process for deferred (due to high cost) workflow activities, timed out notification activities,
and wait activities

Page 5
2. Overview of OTL’s Approval Processing
OTL’s approval processing follows these general steps along the road from timecard submission to approval
or re-approval:
• Upon the timecard’s initial submission:
o The approval style preference assigned to the worker is evaluated; the timecard is marked as
approved if appropriate.
o A time building block in the HXC_TIME_BUILDING_BLOCKS table is created for each
application style component in the worker’s approval style, including one for each ELA
component. The timecard is considered approved if all of these application_period time
building blocks have been marked as approved.
o If the timecard’s approval style is not Approve on Submit, a workflow will be initiated to
handle its approval(s). A child process is spawned for any application period which is in
submitted status once all the days within that application period have been submitted, and if
no earlier sequenced application periods are still in submitted (or rejected) statuses.
• The workflow performs the following steps:
o Categorizes the time entries according to your defined time categories or approval style.
o Applies any defined approval rules to determine if human approval is required.
If the rule’s outcome indicates human approval is required for that application’s data,
evaluates the approval style components to determine the method of approval for
each application in the application set.
Auto-approves the time if the rule’s outcome indicates no approval is required.
o If no rules are defined, proceeds with evaluating the approval style components to determine
the method of approval for each application in the application set.
o Determines who should receive an approval notification and the appropriate layout of the
notification.
• Upon the timecard’s resubmission:
o The deposit process changes the application_period time building blocks to ‘submitted’ as
appropriate.
o A new workflow will be initiated that:
Cancels any outstanding notifications.
Categorizes the time entries as appropriate.
Evaluates any rules set up to execute upon resubmission to determine if re-approval
is required.
If re-approval is required, the remaining steps are the same as for initial approval.
• OTL’s approval process does not alter the data provided on the time entries in any way. It only
determines whether or not approval is required, and handles those approvals and notifications as
appropriate. If you customize OTL’s approval processes in any way, including customizing the
workflow, your customizations likewise must not alter the data associated with time entries. If they
do, you risk causing serious problems with OTL’s other delivered processes.

Page 6
3. Approve On Submit
OTL delivered this predefined approval style in Mini-pack J (HXT.J) to approve timecards automatically
without running the Workflow Background Process. If you associate this approval style to your workers, then
the OTL application automatically approves their timecards when they submit them. This approval style can
be very beneficial for some businesses in very particular cases. Here are some points to consider when
deciding whether or not this approval style is right for your business’s needs:

The timecards’ status, displayed on the Recent Timecards page of workers who have been assigned
this approval style, will be ‘Approved’, just as the status of manually approved or auto-approved
timecards is.
The Approve on Submit approval style approves timecard data for all applications in the worker's
application set. For example, if the worker's application set includes Oracle Projects and Payroll, then
the OTL application automatically approves the timecard for both of these applications in a single
step. You can only use this approval style if no timecard data for any of the applications in your
workers’ application set requires human approval.
Approve on Submit is an entire approval style, that is, you can only use Approve on Submit for all
applications in your application set. You cannot choose it as the approval mechanism in your
approval style components.
The timecard’s time period and approval period must be of the same length to use this approval style.
If all of your workers are assigned this approval style, you will not need to schedule the Workflow
Background Process to run at all for OTL approvals.
Because no workflows are initiated with this approval style, no notifications can be sent to your
workers regarding their timecards’ statuses.
Once a timecard has been approved using Approve on Submit, OTL recommends that you do not
change the approval style for that timecard. If you need to change the worker’s approval style, best
practice is to make the change effective for the first period for which no timecard has been submitted.

Page 7
4. Time Categories

4.1 Overview

OTL’s time categories allow you to group an extended range of attributes of time entries you want to analyze
in your enterprise. The attributes include user-defined value sets, input values, and all mapping components
that use a table-validated value set.
A time category is a group of time entries on a timecard, such as elements, projects, or tasks. You can define
one or more specific value for each category. For example, you can define the category Regular Time
containing the elements Regular Salary and Time Entry wages, or you can define a time category for Project
A and Task 1. Time categories can contain mapping components, alternate name sets, or other time
categories. For example, you can define time categories for Sick and Vacation, and then define a third
category called Absence that contains these two categories.
Mapping components relate to segments you have defined in the OTL Information Types Descriptive
Flexfield. These segments can have a value set associated with them, which define the list of values. Time
categories are used in Entry Level Processing, Entry Level Approval, time entry rules, approval rules, and to
control the display of totals on the Review page and for workflow approval notifications.
With the OTL time category functionality, you can:
Create a time category limited to values in a defined table validated value set.
If your system’s patching level is at Mini-pack H (HXT.H) or lower, time category components are
made up of two mutually exclusive components, Mapping Component and Time Category. With the
enhanced time category functionality delivered in HXT.H, you can include a third mutually exclusive
component called Alternate Name. You can define time categories using alternate name values,
which enables the categorization of multiple dependent mapping components in one.
Enforce the parent time category operator to take precedence over child time categories operators,
since the restriction that all nested time category operators must be the same has been removed.
Define explicitly how empty values in time category components are interpreted.
Use the sum of all of the time entries included in the category for validation or approval rules.

4.2 Operators

Each time category needs an operator, either ‘or’ or ‘and’, to specify how the items in the category relate to
each other.
OR
Selecting ‘or’ as the operator means if any of the time entry’s attributes included in the category are
entered on the timecard, then the rule or other setup that uses the time category as an input should
consider that the time category has been satisfied. For example, if your time category includes
Project = ‘Acme Airline Engines’ and Task = ‘2.0’, if any time is charged to either Project = ‘Acme
Airline Engines’ or Task = ‘2.0’, then the rule or setup that uses this time category should handle the
condition appropriately. If neither of the attributes appears on the timecard, then the rule or setup
should ignore the condition.
AND
Selecting ‘and’ as the operator means, if all of the time entry’s attributes included in the time category
are entered on the timecard, then the rule or other setup that uses the time category as an input
should consider that the time category has been satisfied. For example, if your time category
includes Project = ‘Acme Airline Engines’ and Task = ‘2.0’, if any time is charged to Project = ‘Acme
Airline Engines’ and Task = 2.0’, then the rule or setup that uses this time category should handle the
condition appropriately. Unless both attributes exist, the rule or setup should ignore the condition.
NOTE: If your time category contains only one item, you may select either operator.

Page 8
4.3 Empty Values

This field allows you to define how the time category should behave if an item does not appear on the time
card. For example, a common validation is: If the worker charges time to Pager Duty, then the worker must
charge exactly 84 hours. On many weeks, though, the worker may not charge any time to Pager Duty.
Depending on how you set the value in this field, you can validate for the existence of the 84 hours, but no
validation will occur if the worker does not enter any time for Pager Duty.

4.4 Examples

Particular payroll elements

Once you have defined your payroll elements (non-recurring earnings elements), you can simply group
them into a time category. In this case, we will use a mapping component, Dummy Element Context, which
is a context of the OTL Information Types Descriptive Flexfield. The system uses the Dummy Element
Context as a placeholder for the actual element provided in the time entry, so this mapping component can
be used to identify that entries containing these elements should be considered in the rule or setup for
which the time category is an input.

NOTE: This time category uses functionality available at all patching levels.

Page 9
Particular project and task combinations
You may need to handle time entries for a particular project and task combination differently than other of
your projects. For example, you may need additional validation on time charged to, or additional approval
for, a certain task of a certain project. In this case, you can create a time category from an alternate name
set to achieve the desired combination.
NOTE: This time category uses functionality available only if your system is patched to HXT.I or higher.
To set up this time category:
Add a context to the OTL Alternate Names Descriptive Flexfield, including segments for project and
task. Each segment will need a values set.

Page 10
Create an alternate name mapping for your new context.

Use this mapping to define your alternate names set, where you will identify the specific project and
task that you wish to categorize.

Page 11
 Create a time category that uses this alternate name set.

A time category of time categories

You may wish to define some time categories for use alone, but may also wish to group several of them into
a single time category, called a ‘parent’ time category. To do so, you may define your operator for the
parent time category as either ‘or’ or ‘and’, just as you would for any time category. This operator may be
different from the operator in the child time categories that you add to this parent, though. As with all
setups, be sure to carefully test the interactions of the operators in the child categories with the operator in
the parent time category.

Page 12
5. Approval Methods

5.1 Auto Approve

If some or all of your timecard data requires no human approval, OTL can automatically approve the data
with this method. Once the timecard has been submitted, the Workflow Background Process identifies
the data to auto-approve.
An important point to consider when defining your approval styles is that OTL’s default method is Auto
Approve for all timecard data unless you assign a different approval style whose definition indicates
otherwise. Also, within the approval style, OTL’s default is auto-approval, unless the setup of your
approval style indicates otherwise. For example, an approval rule may indicate that only overtime entries
require approval. If a timecard containing overtime is submitted, then the overtime entries may be routed
for human approval. The rest of that timecard’s data, and timecards with no overtime, would all be auto-
approved by default.
As you can see from the preferences displayed, this worker’s assigned approval style is the defaulted
OTL Auto Approve style, because he has no other assigned preference for his approval style. Thus,
when he submits his timecards, they will be approved automatically during the next run of the Workflow
Background Process.

Page 13
5.2 Entry Level Approval

Approval style setups

For any application for which you wish to use ELA, you will need to provide the additional ELA
components. You can access the ELA Components form once you have selected ELA as your approval
method.
In the ELA Components window, you will provide the default approval style for that application and any
time categories which should be approved in a particular way. The default approval style indicates how to
handle any time for that application that is not included in your time categories. Then you can identify the
approval method for each category.
The Project Manager approval method is available to assign to a time category used for a single ELA
component, but this selection functions differently than if you were to choose Project Manager as the
approval method for the approval style component for an entire application. In this case, the system only
categorizes the time according to the time category that you have specified here, i.e., it does not attempt
to further categorize the time within this time category by project manager. Therefore, you must ensure
that all of the time entries in your time category apply to a single project manager when selecting it as the
approval method for an individual ELA component.
Approval notifications
In general, your approvers will not wish to receive approval notifications with duplicate timecard
information, so the ELA functionality attempts to consolidate notifications whenever possible. To do so,
the system first identifies the approvers associated with a given timecard, and the time entries from that
timecard to send to each approver. Then, if the system detects that the same approver is designated to
approve the time entries in more than one time category, the time entries will be consolidated into a single
notification to send to that approver.
Example – Have the worker’s direct supervisor approve worked time entries, and have a clerical person in
the department approve all absence entries for every one in the department
In this case, since only the absence entries need to be approved using a different mechanism than all
other entries, you can use just one time category for the absence elements and assign its mechanism to
that category. You can then let all other entries default to the appropriate mechanism.

Step 1: Set up a time category for the absence time (using here the same time category as in the
example above)

Page 14
Step 2: Set up the approval style to indicate how the time in the time category should be approved,
and how all other time should be approved.

Page 15
 NOTE: The default approval style for the ELA components indicates how any time entries related to this
application that are not included in the categories listed should be approved. In this case, if any time is
entered against an element that was not included in either of the two time categories, it will be included in
the notification sent to the worker’s supervisor.

Step 3: Assign the approval style to the appropriate workers.

Page 16
Step 4: Enter and submit the timecard.

Page 17
Step 5: Approve the timecard.

The supervisor’s notification without absence entries

The details of the supervisor’s notification without absence entries

Page 18
 The notification with absence entries

The details of the notification with absence entries

5.3 Formula (Selects Mechanism)

You can write your own FastFormula to specify which approval mechanisms you would like to use under
various circumstances. For example, your formula could specify that your workers’ timecards should be
auto-approved if they reported no overtime, that their supervisors should approve their timecards if they
reported up to 10 hours of overtime, but that a particular senior vice president should approve their
timecards if they reported more overtime than that.
Your approval formula will need to return the appropriate approval mechanism and an identifier if the
mechanism requires one. The Person and Workflow mechanisms both require identifiers. You can use
the delivered formula, Override Approver WF Person Mechanism (Seeded Approval), as a model for your
own formula to select the necessary approval mechanism.

Page 19
5.4 HR Supervisor

If your workers’ primary assignment records include the name of their supervisors, the Oracle HRMS
applications maintain a supervisor hierarchy. You can use this supervisor hierarchy in your timecard
approvals by having the workflow route the approval notification to the worker’s supervisor with the HR
Supervisor method. The workflow will notify the worker’s immediate supervisor first. If the supervisor fails
to respond and the notification times out, the workflow will cancel that notification and send a notification
to the next person in the hierarchy.
A word of caution in using this method: If each supervisor at each level of the supervisor hierarchy fails to
act on a timecard notification, by default the workflow will traverse all the way to the top-most level
defined in your supervisor hierarchy. Some companies have set the default timeout to zero, to spare their
CEO from receiving a lot of approval notifications in her worklist or inbox.
In the example below, the worker has been assigned the approval style defined with HR Supervisor as
the approval method, so all of his timecards and all data on each timecard route to his supervisor for
approval.

Page 20
Page 21
Page 22
5.5 Person

In some cases, you may want to designate a particular person to be responsible for approving timecards.
To do so, you would define an approval style with the Person method, and then identify the individual you
wish to name.
In the example below, the worker has been assigned the approval style defined with Person as the
approval method, so all of his timecards and all data on each timecard route to a particular person for
approval.

Page 23
Page 24
Page 25
5.6 Project Manager

Many of OTL’s customers need to capture projects-related data on their timecards. Oracle Projects
requires that all projects-related data be approved prior to its transfer from OTL to Projects. Often, the
project manager is the approver of these data, so OTL automatically identifies the appropriate project
manager and sends the timecard data for approval with the new Project Manager approval mechanism. If
your OTL system is patched to a level lower than Mini-pack I (HXT.I), in order for this functionality to work,
you will need to manually categorize your projects by project manager and set up an entry level approval
for each category in the approval style. Beginning with HXT.I, the new Project Manager mechanism uses
ELA functionality but creates time categories for the projects in your system for you.
NOTE: If you select Entry Level Approval in your approval style components, and then select Project
Manager as the mechanism for a category within the ELA setup, you will need to create and maintain the
time categories manually. OTL can only automatically categorize time entries by Projects data if you
specify that the approval mechanism for all Projects data, i.e., if you select Project Manager as the
mechanism for the approval style component for the Projects application.
In general, your approvers will not wish to receive approval notifications with duplicate timecard
information, so the Project Manager functionality attempts to consolidate notifications whenever possible.
To do so, the system first identifies the approvers associated with a given timecard, and the time entries
from that timecard to send to each approver. Then, if the system detects that the same approver is
designated to approve the time entries in more than one time category, i.e., one person manages more
than one project, the time entries will be consolidated into a single notification to send to that approver.

5.7 Workflow

This mechanism allows you to implement your own notifications, and the logic that you may require for
them. To do so, you may choose to use HXCSAW workflow item type, or use it as a model for your own.
NOTE: This approval mechanism does not handle the case where you wish to bypass OTL’s delivered
workflow and replace it with your own entirely custom one. To use any entirely custom workflow, you
would need to modify parameters on the Time Entry and Create Timecard menu functions in addition to
creating the workflow definition. If you customize the workflow, your processes must not alter the data
associated with the timecard. Doing so will likely cause serious problems for OTL’s delivered processes.

5.8 Combining Approval Methods

If your worker’s application set includes more than one application, you will need to have an approval
style component for each application. You may wish to use the same or different approval mechanisms
for each application.
You can specify if the approvals for each application’s data should happen sequentially or in parallel
(simultaneously), depending on the sequence numbers you assign to each approval style component.
Entry Level Approval also allows you to decide if notifications should be sent in parallel or sequentially for
each of your time categories.
NOTE: Different combinations of applications, approval mechanisms, and sequence numbers can have
differing effects on the approval process, and particularly on the sending of notifications. You will need to
identify your business’s exact requirements, and as with all setups and configurations, carefully test to be
sure yours produces the necessary outcome.

Example – Application set contains Projects and Payroll

o Different approver for each application’s data

If your project managers should approve the project data and the worker’s direct supervisor should
approve the payroll data, set up each approval style component with the appropriate mechanism.
In this case the workflow will send a notification to each of the project managers that the system
identifies from the project data on the timecard with all data associated with each entry related to
their projects. The supervisor will also receive a notification with all data from the entire timecard.

Page 26
 NOTE: If the worker enters time on an Entry Level Processing layout with project and payroll data,
and if any of the entries contain payroll data as well as project data, the project managers will see
the entry’s payroll data in the notification along with the project data for that entry.
If the supervisor should receive the notification only after all of the project-related entries have been
approved, then set the sequence number higher for the Payroll approval style component than the
sequence number on the Projects component. If all notifications should be sent simultaneously, set
up the components with the same sequence numbers.

o Same approver for both applications’ data

If the same approver, e.g., the Project Manager, should approve both your Payroll and Projects
data, setting up both approval components with the ‘Project Manager’ approval mechanism would
cause the approver to receive two notifications with identical data. If your approvers would not wish
to receive two notifications, an alternative setup can make use of the fact that each notification
would display all of the timecard’s data. In this case, set up the approval style component for one
of the applications with Project Manager as the approval mechanism and a low sequence number,
and set up the approval style component for the other application with Auto Approve as the
mechanism and a higher sequence number. Then the project managers’ notifications will display
all of the timecard’s data, which they need to be able to determine if they should approve or reject
the timecard. Once they have acted on the notification, the auto-approval for the other application
prevents their receiving a second notification with the same data.

Page 27
6. Approval Rules
You may need only approvals for your workers’ timecard data, whether upon initial submission or upon
resubmission, under certain circumstances. For example, you may need to have timecards approved only if
they charge time to a particular project, or perhaps some of your workers’ timecards only re-approval if the
total hours has increased by 10% or more. You can identify these conditions with approval rules (data
interdependency rules) that you add to your approval style.
You can use any time entry rule as an approval rule. OTL provides rules for some of the most common
scenarios. You can also create your own rules, either by using one of the delivered rules as a model for
yours, or by creating your own rule from the ground up. If you write your own FastFormula for an approval
rule, the formula must return the result ‘TO_APPROVE’, set either to ‘Y’ if approval is required or ‘N’ if no
approval is required, i.e., the timecard data should be auto-approved.
You may need to add more than one approval rule to your approval style. If you have more than one
approval rule, the system will evaluate the rules in the order that you added them, from top to bottom as they
appear on the approval styles form. Once the evaluation of any of the rules indicates that approval is
required, the evaluation proceeds to determine what kind of approval is required, as specified in the approval
style components on the approval style. Depending on which rule’s evaluation determines that approval is
required, not all of the rules may execute for a given timecard. For example, if you have three approval rules
on your approval style, if the evaluation of the first rule determines that approval is required, the last two rules
will not execute for that timecard.

Example – Workers’ timecards require approval only if they include more than 2 hours of overtime on a single
day.

Step 1: Create a time category for the overtime earnings elements

Page 28
Step 2: Define a time entry rule using the ‘Approval – approval maximum (Seeded)’ formula

Step 3: Define an approval style using your time entry rule as an approval rule

Page 29
Step 4: Assign your approval style to your workers

Page 30
Step 5: Submit a timecard to test your setups – more than 2 hours of overtime in a day

The submitted timecard’s details

The approver’s notification worklist

The approval notification’s details

Page 31
Step 6: Submit a timecard to test your setups – less than 2 hours of overtime in a day

The submitted timecard’s details

The Recent Timecards table with the approved timecard

Note that, in both cases, the approval rule’s evaluation is based on the sum of the hours defined in the time
category.

Page 32
7. Override Approvers and Approval Styles
Some predefined timecard layouts have an Override Approver field. When the field is enabled, the worker
can select anyone in the business group who appears as a supervisor on any assignment record as the
override approver. The timecard is sent to this approver only, and the usual approval style is not activated.
Instead, the override approval style specified in the worker’s preference is applied.
NOTE: Your override approval style must include all applications in the worker’s application set. For the
workflow to be able to identify the override approver indicated on the timecard, you must use the method,
Formula (Selects Mechanism), with the delivered formula, HXC_OVERRIDE_APPROVER_WF_PERSON.
You enable the override approver field by setting the following preferences:
Enter Override Approver preference set to ‘Yes’.
Override Approval Style segment of the Approval Style preference set to Projects Override Approver.
(Optional) Default Approver preference set to a name to display a default value for the Override
Approver field. Setting this preference means that the override approver will always be notified
unless the worker indicates otherwise on the submitted timecard.

Page 33
8. Approval Periods of Different Lengths than Timecard Periods
In some cases, you may wish to have time periods of different lengths for time entry and for approvals.
For example, many government contractors may wish to have their workers enter time on a daily basis,
so may choose to have a daily timecard. In this case, the approvers often wish to approve all of the daily
timecards at one time at the end of a longer period, possibly weekly or bi-weekly. In this case, OTL will
consolidate the time entries from the daily timecards entered during the approval period into a single
notification for the approver. The notification will be sent after all the days within that period have been
submitted.

The confirmation page of a daily timecard

The approver’s notification worklist

Page 34
The approval notification’s details

Page 35
9. Appendix – Document References & Further Reading

Oracle Applications Flexfields Guide (Metalink Note: 236108.1)

Oracle Time & Labor Implementation and User Guide (Metalink Note: 207333.1)

Oracle Time & Labor Mini-Pack About Documents

• HXT.G (Metalink Note: 258309.1)

• HXT.H (Metalink Note: 282087.1)

• HXT.I (Metalink Note: 303755.1)

• HXT.J (Metalink Note: 344022.1)

Using Oracle FastFormula (Metalink Note: 223280.1)

Page 36