Step 4: Building the Rule Map
The initial period of interest used to create batches of time reporters in Step 2 represents only the minimum amount of data (or time) that must be processed in Time Administration. This initial period does not necessarily include all the time needed to process the rules in a time reporter's rule program. To determine both how far back into the past and forward into the future Time Administration must go to retrieve, for each batch, 1) the data needed to run each individual rule in a time reporter's Rule Program, and 2) the maximum amount of data encompassing the entire group of rules in the Rule Program, Time Administration must define a second period of interest. In the following section, we refer to the maximum period of time containing the data needed to run all the rules in a rule program as the final period of interest. In addition to defining this period, the Build Rule Map process generates an output table (TL_RULE_MAP) identifying the rules to process for each batch, the priority of the rules, the AE Section containing each rule in the rule program, the effective dates of both the workgroup and the rule program, and other data.
After the rule map is complete, Time Administration sends the correct amount of time to the Intermediate Payable Time tables for processing and identify the AE section for each rule and period of interest.
As noted earlier, the initial period of interest constitutes only the first step in the definition of a period for rules processing.
Important! The following explanation of the final period of interest assumes that the Use Reported Time for POI check box on the Process Time Admin page is selected. For an explanation of what happens when the check box is cleared, see Process Time Admin page.
The final rule map may need to be extended beyond this initial period:
If a rule you are processing requires data from before the time reporting period intersected by the EARLIEST_CHGDT, the initial period of interest must be expanded back in time. For example, suppose that the time reporting period associated with the workgroup you are processing is weekly, and that the initial period of interest is the third week of the current month. If you are processing a monthly rule in connection with this workgroup, the final rule map will need to extend past the initial period of interest to capture data going back at least to the beginning of the month.
The rules you are processing may require data from periods following the period intersected by the earliest change date. The data required may extend to the end of a rule period that both includes and goes past the initial period of interest end date.
The following example illustrates how the system determines the maximum date range for the final period of interest:
Example: Determining the Final Period of Interest
Assume that the following is true:
The time reporter you are processing is a positive time reporter.
The time reporting period on the time reporter's workgroup is weekly, and the week is defined to begin on Monday and end on Sunday.
The initial period of interest—the weekly time reporting period intersected by the earliest change date--extends from February 7 to February 13 (Monday through Sunday).
The last period processed for the payee is the week of January 31 (Monday) through February 6 (Sunday).
The current week (the week to be processed) begins on February 7.
The payee has 3 rules in his rule program as represented in the following diagram: a weekly rule, a monthly rule, and a daily rule. Each of these rules is assigned a priority from one to three.
The Earliest Change Date is February 7.
The Process Date on the run control page is February 17.
The latest date of reported time is 25 February (in this example, the employee has reported a future vacation from February 23 to February 25).
This diagram illustrates the example: Determining the Final Period of Interest
Time Administration determines the maximum date range for the period of interest through a process called pyramiding (represented in the diagram by a series of lines leading in stair-step fashion from the beginning of one rule period to the next in order of priority). The algorithm that Time Administration uses to define the begin and end dates of this period can be broken down into the following steps:
Time Administration determines the latest date of reported time. In the preceding example, this date is February 25. This date—identified as Parameter 1 in the diagram—is used to determine the final period of interest end date.
Note: If no time is reported for future periods—that is, periods outside the period intersected by the earliest change date—the date of Parameter 1 is the last day of the time period intersected by the earliest change date (the end of Period 2 in our example). This date is used in the following step.
Using the date of Parameter 1, the system selects the latest date from all of the rule periods intersected by Parameter 1. In the diagram, the rule period with the maximum end date intersected by Parameter 1 is the monthly rule (rule number 1). Because the end date of this rule period is February 29, this is the date the system uses as the final period of interest end date.
The system then determines the earliest date that an instance of Payable Time has not been passed to Payroll for the set (that is, the EARLIEST_CHGDT). This includes any adjustments that have been made to reported time since the previous update to payroll. This date, identified as Parameter 2 in the diagram, is used to determine the final period of interest start date.
To determine the period of interest start date, the Rule Map process:
Locates where the earliest change date (EARLIEST_CHGDT) intersects the rule period corresponding to rule 1 in the rule program. It expands the period of interest to the start of this rule period (February 7).
Locates where the start of rule period 1 intersects the next rule in order of priority—rule 2—and expands the period of interest back to the beginning of rule period 2 (February 1).
It starts the process over again by locating where the start date of rule period 2 intersect the next rule in the priority list—rule 3—and expands the period of interest start date back to the beginning of rule period 3 (because rule 3 in this example is a daily rule, the period of interest stays at February 1).
The rule mapping program then moves back up through each rule period to capture additional time that may be needed to process any rule that could influence Payable Time. Consider the example: The weekly rule period that begins January 31 and ends February 6 overlaps with the monthly rule period. Because the weekly rule has priority and can therefore influence time (alter a TCD, create new rows in TL_IPT1, and so forth) that will later be processed by the monthly rule, the rule map pyramids backwards not just to the start of the monthly rule (February 1), but to the start of the first weekly rule period that could potentially affect the monthly rule: this is the weekly rule period that begins on January 31.
Note: The purpose of going back up through the rule program can be explained as follows: Suppose that the weekly rule in the example is an overtime rule that states that all time reporters should be paid at the overtime rate of 1.5 x Regular for each hour over 40. If the Rule Map process does not move back up through the rules to include the data for January 31, the system won't know if or when the condition for this rule was fully satisfied, and incorrect time data could then be passed to the monthly rule. Consider this scenario: Your time reporters all work ten hours a day for 5 days during the week beginning January 31. If the weekly overtime rule does not include the first day of the workweek— January 31—it will appear that no one worked overtime during the week. But in fact, the condition needed to initiate overtime pay was met at the end of the fourth day of work (x 10 hours per day). This means that the last day of the week must be paid at the overtime rate. This information can then be made available to the monthly rule, because there are dependencies between the rule periods.
Understanding How Time Administration Uses the Final Period of Interest
After the system has defined the range of dates that make up the final period of interest, Time Administration:
Transfers the data for this range of dates to Intermediate Payable Time.
After Intermediate Payable Time has been processed, Time Administration passes all or part of this time to Payable Time.
In this section we discuss the difference between the final period of interest, Intermediate Payable Time, and Payable Time, and then describe how Time Administration calculates Payable Time.
Understanding the Relationship between the Final Period of Interest, Intermediate Payable Time, and Payable Time
The range of dates transferred to Intermediate Payable Time is exactly equivalent to the final period of interest. This period includes all the data needed to process each rule in your rule program. However, the amount of data in Intermediate Payable Time can differ from the time data that Time Administration transfers to Payable Time. This is because the function of Payable Time is to supply time data to external systems, for example, Payroll or Project Costing, while the function of the period of interest Rule Map is to supply Intermediate Payable Time with the data needed to run Time and Labor rules. The range of dates needed to process these rules may be considerably larger than the range of dates needed by Payroll or Project Costing. For example, suppose you are processing a workgroup whose period type is weekly, and that the week you are processing falls in the middle of the month. The rule program for this workgroup contains several monthly rules. Your payroll system may only be interested in data for the week you are currently processing, but your Time and Labor rules need data going back at least to the beginning of the current month (to satisfy the needs of your monthly rules).
Let's examine the following rules for how Time Administration creates Payable Time for positive time reporters, and then review what occurs in the case of an exception reporter.
Rules for Positive Time Reporters
To create Payable Time for positive time reporters, Time Administration transfers to Payable Time all dates within the current time reporting period for which time has been reported positively.
In addition, Payable Time includes:
Any positively reported time for dates before the current workgroup period.
Any positively reported time for dates following the current workgroup period.
Payable Time also includes days for which time has been created using rules processing.
Example: Payable Time for Positive Time Reporters
Let's use a slightly modified version of the example we used earlier to illustrate the Building the Rule Map Process to show the type and extent of the data that can be passed from Intermediate Payable Time to Payable Time. Assume the following:
The time reporter we are processing is a positive time reporter.
The time reporting period on the time reporter's workgroup is weekly, and the week is defined to begin on Monday and end on Sunday.
The last period processed for the payee is the week of 31 January (Monday) through 6 February (Sunday).
The current week (the week to be processed) begins on 7 February.
The payee has 3 rules in his rule program as represented in the following diagram: a monthly rule, a weekly rule, and a daily rule. Each of these rules is assigned a priority from one to three.
The Process Date on the run control page is 17 February.
The latest date of reported time is 25 February (in this example, the employee has reported a future vacation from 23 February to 25 February).
The time reporter enters new time data for 6 February, a day that has already been processed and sent to payroll: He originally reported working 8 hours on 6 February when he actually worked 12, and has now corrected the mistake.
The earliest change date is 6 February—the day for which the time reporter has entered new data.
This graphic illustrates the example: Payable Time for Positive Time Reporters
This diagram illustrates the different sources of time data that can be transferred to Payable Time.
Source 1: Positively Reported Time within the Current Workgroup Period
In this example, the time reporter has reported time for each of the days in the time reporting period that begins on February 7 and ends on February 13. The data for these dates is therefore passed to Payable Time.
Source 2: Positively Reported Time for Dates Prior to the Current Workgroup Period
As illustrated in the preceding diagram, the time reporter reports new time data for June 6—a day that falls within a previously processed period (he originally reported working 8 hours on February 6 when he actually worked 12).
Source 3: Positively Reported Time for Dates Following the Current Workgroup Period
In this example the time reporter reports three future vacation days: February 23, 24 and 25 . This data must be passed to Payable Time.
Source 4: Time Created Using Rules Processing
To illustrate this last source of data, we need to make a small modification to our example. Let's assume that the monthly rule in the diagram states that as soon as a time reporter works more than 10 hours of overtime in a given month, any overtime hours paid at the normal rate must be recalculated and paid at twice the normal rate. Let's also assume that the new data our time reporter has entered for February 6 (see Source 2) increases the total number of overtime hours worked for the month to 11 hours. Because of this, the condition for the monthly rule is satisfied, and all previously reported overtime hours must be recalculated using the new rate (2 x normal rate). Assuming that our time reporter logged overtime hours on February 1-5 at the normal rate, these days (marked by cross-hatching in the diagram) are recalculated, offsets generated, and new data sent to Payable Time.
Note: The Process Date, Use Current Date or Use Reported Time for POI fields on the run control page, have no direct affect on what is sent to Payable Time in the case of positive time reporters—its primary function is to select time reporters for processing. Time Administration processes only time reporters whose earliest change date is less than or equal to (<=) the Process Date. However, in addition to selecting time reporters for processing, it also aids in determining the end date to process. The end date equates to the time period end date based on the field selected: Process Date, Use Current Date or the maximum date reported for Use Reported Time for POI field.
Rules for Exception Reporters
To create Payable Time for exception reporters:
Time Administration creates Payable Time from the time reporters' schedules for all dates within the current time reporting period (as long as the current period falls within the period of interest). If any day within this period has positive time reported for it, the positive time takes precedence over scheduled time—that is, Time Administration does not use the scheduled hours for that day.
In addition to the dates within the current time reporting period, Payable Time includes:
Any positively reported time for dates before the current workgroup period.
Any positively reported time for dates following the current workgroup period.
Payable Time also includes days for which time has been created using rules processing.
In the case of exception reporters, you can also use the Process Date on the run control page to send additional data to Payable Time according to the following criteria:
If any rule period you are processing is greater than or equal to the current workgroup period length, you can create Payable Time outside the current workgroup period by placing the Process Date outside the workgroup period but within the date range of the rule period that extends into the future. When you do this, you'll create Payable Time from the start of the current workgroup period up to the end of the time reporting period in which you set the Process Date—as long as the rule period extends at least to the end of this time reporting period. If the rule period ends before the time reporting period, then the last date for which time data will be passed to Payable Time is the end date of the rule period.
If all rule period lengths are less than or equal to the current workgroup period length, then Payable Time will be created from the time reporters' schedules for the current workgroup period (time reporting period) only—regardless of the Process Date.
Regardless of how far past the current workgroup period a rule period extends, if you use a Process Date that is within the date range of the current workgroup Time Period ID, Time Administration creates time for exception reporters for the current workgroup period only (regardless of the date ranges for the rule periods).
Note: Because of the widely differing results you can get, we do not recommend that you set the Process Date after the current workgroup period. This ensures that all exception reporters will have time created for them within the current period.
Example 1: Expanding Payable Time to the End of a Future Workgroup Period
Let's view an example in which we use the Process Date to expand Payable Time from the current workgroup period to the end of a future period.
This graphic illustrates the example using the Process Date to expand Payable Time from the current workgroup period to the end of a future period
Assume the following:
Week 3 is the current workgroup period (the week to be processed).
There is a two-month rule associated with the workgroup.
The Process Date is set to Week 6.
Because the two month rule period that begins in January extends past the current workgroup period (Week 3) to the end of February, when we set the Process Date to Week 6, Payable Time will be created from schedules to the end of Week 6.
Example 2: End of Rule Period Limits Extension of Payable Time
This is an example in which the end of rule period limits the extension of payable time.
This graphic illustrates the example in which the end of rule period limits the extension of payable time
Assume the following:
Week 3 is the current workgroup period (the week to be processed).
There is a one-month rule associated with the workgroup.
The Process Date is set to the end of Week 5; however, the one month rule period ends before this—in the middle of Week 5.
Because the one month rule period in this example extends past the current workgroup period (Week 3), when we set the Process Date to the end of Week 5, Payable Time will be created into the future. However, Payable Time will not be created past the last day of January, even though the Process Date is in February. This is because Payable Time extends either to the end of the time reporting period intersected by the Process Date, or to the end of the rule period—whichever comes first.
Note: In this example, if we had set the Process Date to the first day of Week 5, Payable Time would still only be created to the end of January. Again, this is because Payable Time extends either to the end of the time reporting period intersected by the Process Date, or to the end of the rule period—whichever is first.
Understanding the Sources of Payable Time
We've reviewed several examples of how to use the Process Date on the run control panel to extend Payable Time past the current workgroup period. Let's examine a more comprehensive example that illustrates all the sources of time data that can be transferred to Payable Time in the case of an exception reporter:
Example 3: Determining Payable Time for Exception Reporters
Assume that the following is true:
The time reporter you are processing is an exception time reporter.
The time reporting period on the time reporter's workgroup is weekly, and the week is defined to begin on Monday and end on Sunday.
The last period processed for the payee is the week of January 31 (Monday) through February 6 (Sunday).
The current week (the week to be processed) begins on February 7.
The payee has 3 rules in his rule program as represented in the following diagram: a monthly rule, a weekly rule, and a daily rule. Each of these rules is assigned a priority from one to three.
The earliest change date is February 6.
The Process Date on the run control page is February 15.
The latest date of reported time is February 25 (in this example, the employee has reported a future vacation from February 23 to February 25).
The time reporter enters new time data for 6 June, a day that has already been processed and sent to payroll: He originally reported working 8 hours on 6 June when he actually worked 12, and has now corrected the mistake.
The earliest change date is February 6 – the day for which the time reporter has entered new time data.
This graphic illustrates the example: Determining Payable Time for Exception Reporters
Using this diagram, we can illustrate the different sources of time data that can be transferred to Payable Time.
Source 1: Time within the Current Workgroup Period
In this example, the current workgroup period begins on February 7 and ends on February 13. The data for these dates is therefore passed to Payable Time.
Source 2: Time Created by Setting the Process Date after the Current Workgroup Period
Because the monthly rule period in this example extends past the current workgroup period, and the Process Date (February 15) has been set outside the workgroup period, Payable Time is created into the future—as far out as the end of Period 3 (the time reporting period intersected by the Process Date).
Source 3: Positively Reported Time for Dates Prior to the Current Workgroup Period
As illustrated in the preceding diagram, our exception reporter positively reports new time data for June 6—a day that falls within a previously processed period (he was scheduled to work 8 hours on June 6 when he actually worked 12).
Source 4: Positively Reported Time for Dates Following the Current Workgroup Period
In this example the time reporter reports three future vacation days: February 23, 24 and 25 . This data must be passed to Payable Time.
Source 5: Time Created Using Rules Processing
To illustrate this last source of data, we must make a small modification to our example. Let's assume that the monthly rule in the diagram states that as soon as a time reporter works more than 10 hours of overtime in a given month, any overtime hours paid at the normal rate must be recalculated and paid at twice the normal rate. Let's also assume that the exception reporter in our example positively reports new time for February 6 (see Source 3), and that the newly reported hours increase the total number of overtime hours worked for the month to 11 hours. Because of this, the condition for the monthly rule is satisfied, and all previously reported overtime hours must be recalculated using the new rate (2 x normal rate). Assuming that our time reporter logged overtime hours on February 1-5 at the normal rate, these days (marked by cross-hatching in the diagram) will be recalculated, offsets generated, and new data will be sent to Payable Time.