Using Batch Processing Tips
Q. How can I process both a prior period adjustment for an exception reporter and the "current" time reporting period if the current period does not fall within the period of interest for batch processing, and how can I avoid skipping periods when I run Time Administration in a situation like this?
A. Because Payable Time cannot be created for a date or a period that is not contained within the period of interest (and which is therefore not included in Intermediate Payable Time), the current period may need to be processed in a separate run from the prior period adjustment. The following example illustrates why this might occur, and how to avoid skipping a period when you run Time Administration.
Note: The information contained in this topic assumes that you are familiar with the explanation of how Time Administration calculates the period of interest, and the material on the relationship between the period of interest, Intermediate Payable Time, and Payable Time.
Example: Creating Time for an Exception Reporter with a Prior Period Adjustment
Assume the following:
You are processing an exception time reporter.
The time reporter belongs to a workgroup with a monthly rule in the workgroup rule program.
As illustrated in the following diagram, the last period processed for this time reporter is Week 6 (the current week to be processed is Week 7). After Week 6 is processed, the earliest change date is automatically reset to the first day of the next period—that is, Week 7 (after processing an exception time reporter, the earliest change date is automatically reset to the start of the period immediately following the one intersected by the current date or process date used in the current Time Administration run).
This graphic illustrates the example: Creating Time for an Exception Reporter with a Prior Period Adjustment
After Week 6 is processed, the time reporter makes a change to prior period time—he neglected to report a vacation day at the beginning of Week 3, and then does so during Week 7. Because of this, the earliest change date for the time reporter moves from the beginning of Week 7 to the start of Week 3.
After our time reporter reports new data in the prior period, the system administrator runs Time Administration for Week 7, setting the process date to the end of the week (Week 7). When the process is started, Time Administration defines the initial period of interest as the time reporting period intersected by the earliest change date (Week 3 in our example). The system then expands the period of interest to create time for the monthly rule, giving us a final period of interest that begins on January 1 and ends on January 31. Because there is no positively reported time for periods after January 31, the final period of interest does not extend into the current month or even to the current week (Week 7). This means that Payable Time for the time reporter cannot be created, during this run of Time Administration, for the current period (Week 7), as the data for this period does not fall within the period of interest (and therefore does not exist in Intermediate Payable Time). Payable Time will, however, be created for the month of January.
Problem:
In a situation like this, you may still want to create Payable Time for the time reporter in Week 7, which is the "current" period (the period in the present you want to process.) How can you do this, given that the period of interest does not extend into the current month? (Remember, you cannot move time into Payable Time unless it falls within the period of interest, and is included in Intermediate Payable Time.) And how can you avoid skipping a time reporting period—Week 7 in this example—given that the earliest change date is automatically reset to the start of Week 8 (that is, the start of the period immediately following the one intersected by the current date or process date used in the last Time Administration run)?
Solution:
After processing an exception reporter, Time Administration automatically resets the earliest change date to the first day of the time reporting period following the one intersected by the process date used in the current run. In our example, the earliest change date for our time reporter moves to Week 7 after Week 6 is processed, back to Week 3, and finally to Week 8—but time is not picked up for Week 7. In this situation (in which there is a prior period adjustment, and the period of interest does not include the "current" period), you can ensure that all the time for a time reporter is processed (both prior and current), by initially setting the process date to the last day of the last period processed (the one prior to the current period you want to process). After running Time Administration, the earliest change date will be reset to the start of the current period, and you can then move the process date into this period and process current time. So in this example, you would first set the process date to the end of Week 6 (the last period processed), run Time Administration, and then process Week 7.