Making Workgroup Transfers
This section discusses the effect of workgroup transfers on the period of interest calculation in Time Administration as well as on rules processing. Because mid-period workgroup transfers can cause rules to be applied incorrectly, we strongly recommend that you schedule workgroup transfers to take place only at the beginning of a period.
Important! This section assumes that you have a thorough understanding of how Time Administration defines the period of interest for rules processing. If you are not familiar with the concept of the "period of interest," you should review the section on Batch Processing in Time Administration before reading the following section.
Transferring in the Current Period
If an employee transfers from one workgroup to another in the current period, Time Administration processes the employee in two separate batches—one for each workgroup. When Time Administration creates the rule map for each batch, it adjusts the start and end dates of the period of interest to reflect the effective date of the transfer according to the following rule: If the effective date of the new workgroup is greater than the initial period of interest begin date, the start date for the batch associated with the new workgroup will be set equal to the new workgroup effective date.
Example
In this example let's assume the following:
A time reporter changes workgroups on 9 June—in the middle of the current workgroup period (5 to 11 June).
The Time Period ID associated with each workgroup is weekly (the week begins on Monday and ends on Sunday).
Each workgroup has a rule program containing 3 rules with the same rule periods (a weekly rule, a monthly rule, and a daily rule). However, the rules are different for each workgroup.
Note: To determine the initial period of interest, Time Administration uses the Time Period ID on each time reporter's workgroup to determine the start date and the end date of the period intersected by the earliest change date. Any time reporter whose Earliest Change Date is less than or equal to the through date on the run control panel will be picked up when you run time administration—as long as his or her effective dates fall within the workgroup period, or their Max (maximum) TL_EMPL_DATA.EFFDT <= to the earliest change date. In addition, their TL_TR_STATUS.TA_STATUS must equal 'Y.'
This image illustrates the example of transferring a workgroups in the current period.
In this example Time Administration sets the end date of the period of interest associated with the old workgroup to 8 June (the last day the employee is part of the old workgroup), and the start date of the period of interest associated with the new workgroup to 9 June. The rules associated with the old workgroup are used to process all dates before and including 8 June—going back to the final period of interest start date. The rules associated with the new workgroup are used to process all dates from 9 June to the final period of interest end date. However, because the transfer occurs in mid-week, the weekly and monthly rules (for both workgroups) will not have access to data for their entire rule periods and may be applied incorrectly. (Any rule crossing the transfer date could be applied incorrectly). For this reason, we recommend that you change workgroups at the beginning of a period whenever possible. If you absolutely must change workgroups in mid-period, you will have to override rules processing and manually enter the hours to be paid during the transfer period as follows:
To report time for the transfer period:
Enter the time manually through the time reporting pages
Enter time manually for the transfer period exactly as the time reporter should be paid (including overtime hours). This time will go directly to Payable Time (see step 2).
Enter dates for the transfer period on the Override Rules page
To tell Time Administration to accept time exactly as you enter it (untouched by rules), you must enter the dates for the transfer period on the Override Rules for Time Reporters page. Time Administration will extract records from TL_IPT1 into a working table—TL_TA_RUL_OVR—before applying rules to the data stored on TL_IPT1. Time Administration will apply rules to all records stored on TL_IPT1 and update Payable Time as usual. But, as a final step, it uses data stored in the TL_TA_RUL_OVR table (preserved, untouched by rules) to replace records found on the TL_PAYABLE_TIME table.
Note: Time Administration will not change hours entered as rule overrides. Rule overrides go directly to Payable Time.
Note: The same logic that governs workgroup transfers governs changes to Rule Program effective dates as well as TL_EMPL_DATA effective dates—effective dates associated with employee hires, inactivation, or job transfers. So, for example, if the rule program associated with a workgroup changes in mid-period, the start and end dates of the period of interest must be adjusted. Similarly, because a time reporter could have more than one row in TL_EMPL_DATA with different effective dates, multiple rows per time reporter can be pushed into the batch creation process. In this case, start dates and end dates must be adjusted for such things as the TL_EMPL_DATA.EFFDT falling within the period of interest. For example, if the EFFDT of a time reporter is greater than the START_DT of the period of interest, the START_DT will be set equal to the EFFDT.
A Note on Retroactive Transfers
Retroactive workgroup transfers can also prevent rules from being applied correctly—for the same reason that transfers in the current period affect rules processing. Thus, in the previous example, if we assume that the transfer occurs during a period that has already been processed, the weekly and monthly rules may again be applied incorrectly. As in the previous example, we recommend that you change workgroups at the beginning of a period whenever possible. If you absolutely must change workgroups mid-period, you will have to manually enter the hours to be paid during the transfer period as rule overrides.
Note: In the case of retroactive transfers there is an additional factor to consider: the period you are reprocessing with new rules has already been processed, which means that offsets to the original data will be created, new data will be generated, and both the new and old results will be passed to Payable Time.