Professional Documents
Culture Documents
Approvals How To OTL
Approvals How To OTL
Copyright Information
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
1.2
Intended Audience..................................................................................................................................................4
1.3
Definitions.................................................................................................................................................................4
2.
3.
4.
Overview....................................................................................................................................................................8
4.2
Operators ..................................................................................................................................................................8
4.3
4.4
Examples...................................................................................................................................................................9
5.
Approval Methods.....................................................................................................................................................13
5.1
5.2
5.3
5.4
HR Supervisor........................................................................................................................................................20
5.5
Person......................................................................................................................................................................23
5.6
5.7
Workflow .................................................................................................................................................................26
5.8
6.
7.
8.
9.
Page 3
1. Introduction
1.1 Purpose of this Document
OTLs 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 OTLs 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 OTLs 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 businesss needs.
NOTE: It is assumed that readers are familiar with OTLs 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 timecards period.
Approval Style
The combination of approval rules and approval methods that defines who approves the workers
timecards for each recipient application in the workers application set, as well as which data need to be
approved for each application, and which updates to the timecards 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 timecards 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
The approval style preference assigned to the worker is evaluated; the timecard is marked as
approved if appropriate.
If the timecards 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.
Categorizes the time entries according to your defined time categories or approval style.
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.
Determines who should receive an approval notification and the appropriate layout of the
notification.
The deposit process changes the application_period time building blocks to submitted as
appropriate.
OTLs 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 OTLs 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 OTLs 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 businesss 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 timecards 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 workers 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
OTLs 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 systems 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 entrys 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 entrys 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
Page 9
Page 10
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
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 OTLs 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, OTLs 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 timecards data, and timecards with no overtime, would all be autoapproved by default.
As you can see from the preferences displayed, this workers 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
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 workers supervisor.
Step 3: Assign the approval style to the appropriate workers.
Page 16
Page 17
Page 18
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 workers supervisor with the HR
Supervisor method. The workflow will notify the workers 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
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 entrys 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
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 rules 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
Page 30
Step 5: Submit a timecard to test your setups more than 2 hours of overtime in a day
The submitted timecards details
Page 31
Step 6: Submit a timecard to test your setups less than 2 hours of overtime in a day
The submitted timecards details
Note that, in both cases, the approval rules evaluation is based on the sum of the hours defined in the time
category.
Page 32
Page 33
Page 34
Page 35
Page 36