approvals how to

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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.

Step 4: Enter and submit the timecard.

Step 5: Approve the timecard.

The supervisor’s notification without absence entries

The details of the supervisor’s notification without absence entries

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.

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.

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.

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.

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.

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

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

Step 4: Assign your approval style to your workers

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

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.

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.

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

The approval notification’s details

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)

https://metalink.oracle.com/metalink/plsql/docs/FLEXUG.PDF

https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=207333.1

http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=258309.1



https://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=344022.1

https://metalink.oracle.com/metalink/plsql/docs/A73295.PDF