Step 15: Updating Payable Time

This process takes the final results of Intermediate Payable Time processing and inserts them into the Payable Time table, at which point the data becomes available to payroll or other subscribers to Time and Labor.

Payable Time supplies time data to external systems like Payroll or Project Costing, while the function of Intermediate Payable Time is to make time data available internally for rules processing. The dates needed for rules processing may be considerably larger than the range of dates needed by your Payroll system or Project Costing. For this reason, the range of dates transferred to Payable Time may not be identical to the range of dates originally loaded in the Intermediate Payable Time Table.

The Payable Time and Intermediate Payable Time (TL_ITP1) tables organize and format data differently. In contrast to Intermediate Payable Time, Payable Time attempts to sum data with the same attributes (TRC and Task) to create consolidated lines of data. For example, if two punch segments created for a single day have the same TRC in Intermediate Payable Time, Time Administration adds them to create a single row in Payable Time. The same is true of task data, whether tasks are reported positively or derived from task profiles. However, if there are separate TRCs or tasks for the rows of data in Intermediate Payable Time, the system preserves separate rows in Payable Time. If we look at how punch time is formatted in these tables, we can see the difference.

Intermediate Payable Time Versus Payable Time

As illustrated in the following table, when Time and Labor transfers punch data to Intermediate Payable Time, it arranges the data into separate rows of in and out punches, calculates the duration between each in and out punch, and stores the resulting durations or time segments in TL_QUANTITY. Because each duration has a separate row in the table, you can write rules that act differently on different time segments based on punch type, task assignment, and so forth.

In the following example, assume that detailed task information has been reported positively (time has already been assigned to Dept. A or B). We'll then look at a second example in which task assignments are derived from a task profile.

Example 1: Tasks Are Positively Reported

Assuming that tasks are positively reported, rows in TL_IPT1 before rules have been executed would appear as shown in the following table, where there is a record for each segment of time. Rules may later delete or add rows:

PUNCH_TYPE

PUNCH_BEGIN

PUNCH_END

TL_QUANTITY

TASK

In

8:00

10:00

2.00

Dept. A

Break

10:00

10:15

.25

Dept. A

In

10:15

12:00

1.75

Dept. A

Meal

12:00

13:00

1.00

Dept. A

In

13:00

15:00

2.00

Dept. B

Break

15:00

15:15

.25

Dept. B

In

15:15

17:00

1.75

Dept. B

Out

17:00

 

 

 

After rules have been executed to assign TRCs to each time segment, TL_IPT1 would look like this:

PUNCH_TYPE

PUNCH_BEGIN

PUNCH_END

TL_QUANTITY

TRC

TASK

In

8:00

10:00

2.00

Reg

Dept. A

Break

10:00

10:15

.25

Reg

Dept. A

In

10:15

12:00

1.75

Reg

Dept. A

Meal

12:00

13:00

1.00

Reg

Dept. A

In

13:00

15:00

2.00

Reg

Dept. B

Break

15:00

15:15

.25

Reg

Dept. B

In

15:15

17:00

1.75

Reg

Dept. B

Out

17:00

 

 

 

 

After rules have been run, all similar rows (those with the same TRC and task elements) for the same employee and date are summarized and passed to Payable Time. Assuming that the meals and breaks in this example are paid, Payable Time would look like this:

TL_QUANTITY

TRC

TASK

5.00

Reg

Dept. A

4.00

Reg

Dept. B

Note: In this example Payable Time creates two separate rows in TL_QUANTITY. This is because each is associated with a different task and cannot be summed.

Example 2: Task Data Derived From a Task Profile

Assume that task data has been generated through the use of a task profile, rather than positively reported, and that 25% of time is to be charged to Dept. A and 75% to Dept. B. Prior to running rules, TL_IPT1 appears as follows:

PUNCH_TYPE

PUNCH_BEGIN

PUNCH_END

TL_QUANTITY

In

08:00

10:00

2.00

Break

10:00

10:15

.25

In

10:15

12:00

1.75

Meal

12:00

13:00

1.00

In

13:00

15:00

2.00

Break

15:00

15:15

.25

In

15:15

17:00

1.75

Out

17:00

 

 

Note: When using task profiles, Time Administration refers to the instructions defined for the task profile to determine the correct allocation of time to tasks.

After rules have been executed, TL_IPT1 appears as follows:

PUNCH_TYPE

PUNCH_BEGIN

PUNCH_END

TL_QUANTITY

TRC

TASK

In

08:00

10:00

1.875

(7.5 total "In" hrs x .25)

Reg

Dept. A

Break

10:00

10:15

.125

(.5 hrs of total break time x .25)

Reg

Dept. A

Meal

12:00

13:00

.250

(1 "meal" hr x .25)

Reg

Dept. A

In

08:00

10:00

5.625

(7.5 total "In" hrs x .75)

Reg

Dept. B

Break

10:00

10:15

.375

(.5 hrs of total break time x .75)

Reg

Dept. B

Meal

12:00

13:00

.750

(1 "meal" hr x .75)

Reg

Dept. B

Assuming that breaks and meals are paid, Payable Time appears as follows:

TL_QUANTITY

TRC

TASK

2.25

Reg

Dept. A

6.75

Reg

Dept. B

Note: Although these examples include meals and breaks in the total time for the day, they would not typically be included in the TL_QUANTITY column used to determine the allocation of time to tasks. For example, if you were to use a "Default TRC" rule template to assign TRCs to reported time, you could specify which punches should get the default TRC (Punch Types = IN, ML (meal), BRK (break), OUT, and so on). Normally, you would only assign the default TRC to IN or XFER punch types, but not to ML or BRK. If ML or BRK do not get a TRC, then they do not get included in calculations in Intermediate Payable Time or Payable Time, but they could still be used to evaluate other miscellaneous rules.

Note: Even though Intermediate Payable Time contains a separate row for each time segment, this does not, for example, prevent you from writing a weekly overtime rule that sums all the segments in TL_QUANTITY for each day of the week to determine if a time reporter has met the requirement for overtime pay. You could even write a rule that sums all the hours in TL_QUANTITY for each segment in the week, deletes rows for individual segments, and writes the daily sum of hours back into TL_QUANTITY. However, you probably want to maintain separate rows for each segment, because you may have other rules that process different segments of time differently depending on their punch type or task association.