ETC Calculation for Timesheets and Posting

### ETC Calculation for Timesheets and Posting

book

calendar_today

#### Products

Clarity PPM On Premise Clarity PPM SaaS

#### Issue/Introduction

The following document describes the logic used in calculating ETC in timesheets and during posting.

#### Environment

Release: All Supported
Component: Clarity Timesheets

### Posting

1. During the posting of a timesheet entry, the system examines the assignment and determines what the current estimate is.
2. The system then determines what the remaining estimate is by subtracting the timesheet's actuals from the estimate it had already gathered (as described in step I).
3. The system then updates the estimate curve based on the logic below. (Note: The estimate curve is a distribution of the estimates over time.)

1. If the assignment's load pattern is fixed, then the estimate curve is cleared for the time period of the timesheet being posted (the estimates are essentially consumed for this time period). The remaining estimate for the following time periods would remain unchanged.

e.g. If the estimate was 40 hours for this week and another 80 hours for the next 2 weeks, and this week the resource only logged 17 hours of time, after posting there will be 80 hours of estimate, even though 40 - 17 = 23 hours. The 40 hours of estimates are consumed for this week.

2. If the assignment's load pattern is NOT fixed, then the estimate curve is recalculated according to 1, 2 or 3 below.

1. If the work for this time period = the estimate for the time period being posted, then the estimate curve is cleared for the posted time period. The remaining segments of the estimate curve remain unchanged.
2. If there is no remaining estimate, then the entire estimate curve is cleared.
3. If there is still same estimate remaining, then

1. If the actuals thru date is beyond the end of the estimate, then we extend the estimate curve's finish date to one day after the actuals thru date.

2. The remaining estimate is distributed into the curve starting from the assignment start or actuals thru date, whichever one is later.

e.g. If the estimate was 40 hours for this week and another 80 hours for the next 2 weeks, and this week the resource only logged 17 hours of time, after posting there will be 103 hours of estimate re-distributed after the act thru or assignment start date.

4. If there is no work done for an assignment, but the resource had a timesheet posted for the period, the rules in (III) would apply, except that the amount of work would be 0. Estimates would be moved forward and recalculated for non-fixed and for fixed the estimate for that period would be cleared.
5. The estimate sum field (ETC) is updated based on any estimate curve updates in the previous steps.

### Timesheet Editing

1. ETC and Saving a timesheet

1. If the value in the ETC field on the timesheet was overwritten, then

1. If the value was changed to null (the field was cleared), then the system will set the pending estimate to null.
2. Otherwise we store the value entered into the pending estimate field in the assignment.

2. If the ETC field was not changed, then

1. If values were entered into the time entry, then the system will subtract the sum of the time entry actuals from the pending estimate.
2. If the pending estimate = (estimate - all pending actuals), then set the pending estimate to null.

Note: If the pending estimate is changed and actuals are applied to the time entry, upon save, the pending estimate that was entered will remain (no subtraction of the actuals takes place - see 1b above)

e.g. ETC field shows 32 hours. User enters 7 hours actuals and 49 hours into the ETC field. Upon save and refresh, the system displays the 7 hours of actuals and 49 hours of ETC highlighted (which indicates the displayed value is now a pending estimate)

1. If there is a pending estimate from the assignment, then we display the pending estimate into the ETC field.
2. Otherwise

1. If the load pattern is fixed then get the sum of the estimate curve from the finish of the current period.
2. Otherwise we subtract the pending actuals from the estimate and use that for the ETC field.

Scenario 1: ETC with 2 timesheets

I have two un-posted timesheets for the 28 th of May and the 4 th of June. Each timesheet will have 2 tasks, a fixed load pattern task called "fixed task" and a front-loaded task, called "front task". I entered 40 hours of ETC on each of the assignments. I also entered an end date of June 27th for the assignment on the fixed task. I then press the populate button.

The fixed task shows with an ETC of 30.91, the amount of estimate per week subtracted from 40 hours. The front loaded task has 40 hours of ETC. I then enter 10 hours of actuals for each task. The ETC on the fixed task stays the same. The front loaded task now shows 30 hours.

Then I access the next timesheet (June 4th) and populate it. I see that the fixed task shows 21.82 hours of ETC and the front loaded task still shows 30 hours. After entering 10 hours on each task, the ETC is reduced to 20 hours on the front loaded task. The fixed task's ETC remains the same.

If I view the May 28th timesheet, I will see an ETC of 20 hours on the front loaded task and the fixed task will show 30.91 hours. (Note here the difference in how the ETC of the fixed and front loaded tasks shows between subsequent time periods.)

Scenario 2: Pending Actuals and an Adjustment

I have an unposted timesheet for 28th of May. The timesheet has 2 tasks, a fixed load pattern task called "fixed task" and front-loaded task, called "front task". I entered 40 hours of ETC on each of the assignments. I also entered an end date of June 27th for the assignment on the fixed task.

Then I press the populate button and enter 10 hours to each task. The fixed task shows an ETC of 30.91, the amount of ETC per week subtracted from 40 hours. The front loaded task has 40 hours of ETC. I then enter 10 hours of actuals for each task. The ETC on the fixed task stays the same. The front loaded task is now showing 30 hours. The pending actuals (prPendActSum) field on the assignment shows 10 hours on each assignment.

I then submit, approve and post the timesheet. Upon observing the posted timesheet, I see no differences in ETC from the pre-posted timesheets. The assignment shows 0 hours of pending actuals for each assignment.

If I create an adjustment at this point and replace the 10 hours with 4 hours of actuals on each task, the fixed task ETC will stay the same, but the ETC on the front loaded task will change to 36 hours(This the behavior of bug 86825. The system should not alter the ETC on an adjustment.) The pending actuals on both assignments will show as having 4 hours.

Scenario 3: Pending Actuals and an Adjustment

I have an unposted timesheet for 28th of May . The timesheet has 2 tasks, a fixed load pattern task called "fixed task" and non-fixed task, called "front task". I entered 40 hours of ETC on each of the assignments.

I also entered an end date of June 27th for the assignment on the fixed task. I then press the populate button and entered 10 hours to each task. The fixed task shows an ETC of 30.91, the amount of ETC per week subtracted from 40 hours. The front loaded task has 40 hours of ETC. I then enter 10 hours of actuals for each task. The ETC on the fixed task stays the same. The front loaded task is now showing 30 hours. A check of the pending actuals on the assignment table shows 10 hours on each assignment.

Then I submit, approve and post the timesheet. Upon observing the posted timesheet, I see no differences in ETC from the pre-posted timesheets. The pending actuals (prPendActSum) field on the assignment shows 0 hours of pending actuals for each assignment.

If I create an adjustment at this point, override the ETC to 17 hours, enter actuals of 2.2 per entry and hit save, the ETC value I entered will remain as 17 hours. However, if I enter another hour of actuals on the task then the ETC will decrement to 16 on both fixed or front loaded tasks. The pending actuals on both assignments will show as 3.2 hours.