Understanding Time and Labor Implementation

The Time and Labor system uses Human Resources Management (HR) tables to extract all the basic information about your company that will be used during Time and Labor processing. You must set up these tables before you establish any other tables in the system. HR tables and data used by Time and Labor include the Company, Location, Department, Compensation Rate, Job Code, and Pay Group tables.

The following table shows how Time and Labor uses data extracted from Human Resources.

Benefits tables store leave plans and accrual balances. Time and Labor uses benefits tables for determining leave accrual balances. These tables include the Benefits Plan and Leave Plan tables. Set up these tables, in the following order, before setting up your Time and Labor tables.

1. Define all benefit plans by plan type, with vendor and group information.

2. Define the accrual rules for that plan on the Leave Plan table.

PeopleTools stores time/date information in only one time zone—the "Base Time Zone" you select at the time of installation. The base time zone may be set to the time zone of the company's headquarters, or perhaps to Greenwich Mean Time (GMT)—also known as UTC (Universal Coordinated Time).

When employees enter the hours they have worked in Time and Labor, they report time according to the local time zone and PeopleTools stores the information in the base time zone. The Time Administration process then converts the base time back to the local time for rules processing. To do this, it needs to know the time zone "offsets," or the differences between the local time and base time.

Two circumstances can occur when punch time is reported across a daylight saving boundary. These relate to either the transition to or from daylight saving. When transitioning to daylight saving, clocks are advanced by a fixed amount at a fixed time. Transitioning back from daylight saving clocks are put back by a fixed amount at a fixed time.

Let's look at an example:

• For the transition from daylight saving at 2:00AM, the clocks will be put back one hour. This means that an employee starting work at 11:00PM the previous day and finishing at 7:00AM on the day that daylight saving occurred, will have really worked for an elapsed period of 9 hours, not the 8 hours indicated by the clock times.

• For the transition to daylight saving at 2:00AM, the clocks will be put forward one hour. This means that an employee starting work at 11:00PM the previous day and finishing at 7:00AM on the day that daylight saving occurred, will have really worked for an elapsed period of 7 hours, not the 8 hours indicated by the clock times.

The following procedure explains how to select the base time zone and create time zone offsets.

To select the base time zone and create time zone offsets:

1. Select the base time zone on the PeopleTools Options page.

   In the Base Time Zone field, select the time zone for storing all reported time.

2. Change the default settings on the Time Zone Data page and Daylight Savings page, if applicable.

   The Time Zone Data page and Daylight Savings page display the default time zone settings delivered with PeopleTools. You can change the settings on these pages if you need to customize the information for your organization.

3. Create time zone offsets using the Time Zone Data page.

   Click the Generate Query Offsets button on the Time Zone Data page to populate the time zone offsets table with values that represent the differences between the local and base time zones.

Using PeopleTools, you can control the number of batch application engine processes—such as the Time Administration batch process—that can run concurrently.

To increase the number of concurrent batch processes, use the Process Scheduler's Server Definition page to update the Max Concurrent field for Application Engine. (Navigation: PeopleTools, Process Scheduler, Servers.) You may also need to update the MAX API Aware field. The PeopleTools PeopleBook provides instructions for updating these fields.

See the product documentation for PeopleTools PeopleSoft Process Scheduler

In addition to the Time Administration process, which runs in batch mode, Time and Labor includes the following online processes that are invoked from PeopleCode with the Call AppEngine function:

Multiple users can run online processes concurrently. The maximum number of concurrent processes depends on how many instances or images of the temporary tables are dedicated to online processing. Using the PeopleTools Options page (navigation: PeopleTools, Utilities, Administration, PeopleTools Options), you specify:

• The total number of instances you want the system to create for each temporary table (default = 3)

• The number of temporary table instances to create for online processes (default = 3)

When selecting the number of temporary table instances, keep in mind that a higher number increases the number of simultaneous users, but can also increase the consumption of disk space considerably.

You can define five types of periods in Time and Labor: daily, weekly, monthly, complex, and repeating. Although all period types are defined using the same set of pages, not all period types are used in the same way. For example, daily, weekly and monthly period types are used to create time reporting periods, but complex and repeating periods have no application to time reporting—their only purpose is to define periods for rules processing. This section discusses the different uses of periods in the system, and contains important information on when you can use each period type. Periods have the following uses in the Time and Labor system:

All time period definitions include the period length (for example, you could define a weekly period to have a length of one week, two weeks, and so on) and the frequency of the time period. The definition of time and frequency is separate from the time period calendar to make reusing time periods easy and to provide maximum flexibility during setup.

To define a time period:

1. Define the different period types to use for time reporting, tracking attendance, or processing rules.

   Note: Each time you create a time period using one of the time period pages described in this section, the system generates a time period ID. This ID uniquely identifies the time period.

   Begin Date	End Date	Frequency
   1 July	1 July	Daily
   1 July	7 July	Weekly
   1 July	30 July	Monthly
   1 July	15 July	Semi-Monthly
   1 July	31 September	Quarterly

2. Generate period instances.

   Generate actual "instances" of period types on a calendar by running the Build Time Period Calendar Process. For example, a defined weekly period begins on Monday and ends on Sunday. This period doesn't exist in the system until instances of it are generated on a calendar. To create periods based on your period definition:

   1. Define the start and end dates of your calendar. (for example, 1 February 2000 to 1 February 2001).

   2. Specify the period types to include (daily, weekly, monthly, and so on).

   3. Generate actual periods by running the Build Time Period Calendar process.

3. Define additional components.

   Time Periods Used in the Definition of:	Where Used:
   Workgroups	If the period is a time reporting period, link the period, by its time period ID, to a workgroup on the Workgroup page. Or, enter a time reporting period for individual time reporters on the Maintain Time Reporter Data page. If you do so, this period ID overrides the reporting period associated with the time reporter's workgroup.
   Rules	If the period is used to define a time segment for rules processing, link it, by its time period ID, to the rule on the Define Rule Header page.
   Attendance Tracking	If the period is an attendance-tracking period, link it, by its time period ID, to the definition of the attendance program on the Attendance Program page.

The basic overtime functionality of Time and Labor requires no special setup—employees can enter requests for overtime and managers can accept or deny requests. The following optional features require setup:

• Track overtime balances by period.

• Establish overtime limits that trigger a warning, when exceeded, on the manager's approval page.

• Base overtime limits on months of service.

• Enable workflow so that employees and managers are automatically notified when overtime requests are submitted, approved, or denied.

You assign overtime limits to workgroups, consequently, the same overtime limits apply to all employees in the same workgroup.

After defining time periods, launch the Build Time Period Calendar process to create instances of these periods for a week, a month, or years. The Build Time Period Calendar process:

• Builds time period calendars using the specified start and end dates.

  These dates do not have to correspond to pay period begin and end dates.

• Enables you to select the time periods to be included in the calendar build process.

• Provides the option to rebuild calendars to change or delete your time period definitions.

• Enables you to update an existing calendar to expand (or contract) the calendar range (that is, to change the start and end dates of the calendar while preserving existing time period definitions).

Before running the calendar build process, define the start and end dates of the calendar that will include the periods defined earlier using the period definition pages. Specify the period types or period ID's to include in (or exclude from) the calendar build. For example, you could use all the defined period types or just one, specific period. To do this, use the Build Time Period Calendar page.

Time and Labor provides many options and combinations for viewing time management calendar information. The Calendar View Options page assists in determining what will be displayed on the time calendar pages. Use the Calendar View Options page to define the time reporting codes, using TRC Value lists, which will display on the manager time calendar views, as well as associate color coding to the TRC lists and other time related data.

Each TRC or time-related event defined on the Calendar View Options page appears on the time calendar pages when applicable. The time appears in the grid associated to the time reporter who reported the time, overlaying the color associated with the particular time event. The symbols are optional, both in defining them and also using them on the time calendar pages.

The Calendar View Options page is divided into two primary sections — the Reported/Payable Time section and the Scheduled Time and Exceptions section.

Time and Labor enables you to define compensatory time plans. Compensatory time plans provide the ability to administer time off instead of pay. Unlike other leave accruals, where Time and Labor uses the employee's leave balance records maintained in Human Resources, Base Benefits to determine leave availability, compensatory time is administered entirely within Time and Labor. The system maintains each instance of a time reporter's earned compensatory time and the quantity and date earned. This gives you the ability to set expiration periods for individual instances of earned compensatory time.

For example, you may have one compensatory time plan for overtime and another compensatory time plan for meeting or exceeding a deadline. You can establish as many different plans as your organization requires and you can assign a time reporter to one or more compensatory time plans. When compensatory time is entered, the system adds to or deducts from a time reporter's compensatory time balance according to the established rules. If the time entered is within allowed limits, the balance is adjusted and maintained automatically. You do not have to manually change employee's compensatory time balances. The Time Administration process processes compensatory time plans during post-rules processing.

Exceptions are user- and system-defined warnings and errors to indicate a problem with a time reporter's time or a problem in the system. Exceptions are tied to the Time and Labor message sets in the message catalog. Defining exception conditions gives control over time reporting messages and warnings. You can keep an audit trail on resolved exceptions for problems, such as how many times an employee is tardy. If you choose to have the exception archived, you can run a query on resolved exceptions to track trends. By making exceptions allowable, you can track low-severity exceptions, and the system will create payable time without the need to make changes to reported time.

The system creates exceptions based on rules, which are defined in Time Administration, or errors that have been generated as a result of reporting time (specifically in the Time Validation process).

Almost all of the system-delivered exceptions have an exception severity of High and are defined as Not Allowable. These exceptions must be resolved before the Time Administration process creates payable time. You can change the severity and the allowable flag for system-delivered exceptions.

Exceptions that begin with TLX work with delivered attendance tracking and validations. The exceptions for attendance tracking are of a low severity, whereas the exceptions for validation are of high severity. These include validations for task reporting, time reporting codes, compensatory and leave time validations, and time reporter status validations.

The system-delivered validation sets are ST_SUBMIT, ST_TA and ST_ALL. If you don't want to have all the validations in this set run during processing, create a validation set and define which validation definitions to include. The ST_TA validation set represents all validations selected to run in Time Administration but not Submit Time. The ST_SUBMIT validation set represents all validations selected to run in Submit Time, but not in Time Administration. The ST_ALL validation set has all validations selected to run in both Submit Time and Time Administration. Each validation is configurable as to whether it is run in Submit Time, Time Administration, neither or both.

Establishing exceptions is the first part of setting up validation criteria so that the Time Validation process can generate exceptions correctly. You also need to set up PeopleSoft Application Engine sections and validation definitions in order for the system to generate exceptions through the Submit Time process. Validation definitions tie the SQL and exception information together to provide the system with a reference and a way to execute exceptions.

This graphic illustrates the areas that need to be set up so that the system can generate exceptions and perform validations during processing.

To establish user-defined exceptions, set up Time and Labor messages in the message catalog using PeopleTools. See the product documentation for PeopleTools: PeopleSoft Application Designer Developer's Guide.

After you've defined exceptions, you define your PeopleSoft Application Engine sections. Application Engine is a feature of PeopleTools that allows you to write software to perform SQL and PeopleCode processing against the data. An Application Engine program is composed of one or more Application Engine sections. Each Application Engine section typically does one discrete piece of work and is akin to a subroutine, paragraph, procedure of function in a more traditional programming language. Application Engine sections can include referential integrity or validation processing. For each Application Engine section you create, you'll specify which kind of processing should occur.

For the validation process, the system determines the validations to be processed and retrieves the related PeopleSoft Application Engine section names. Each validation definition specifies the Application Engine section name that implements the validation. Control is returned to the Process Validations function upon completion and the system calls the next PeopleSoft Application Engine section.