Information

  • For the manual load profiles with time grid (PM_DAY, PM_WEEK, PM_MONTH, PM_QUART, PM_YEAR), hereinafter referred to as PM_load profiles, there is an option for automated control of under-used or over-used effort per period. This is realized by means of the new Underposting correction and Overposting correction functions.
    • The Underposting correction ensures that unused effort from previous periods is available for future periods. 
    • Overposting correction, on the other hand, ensures that, if more effort than planned was posted in a period, the effort of future periods is subtracted. 

Requirements

Information

  • For both functions, the global Activate posting correction for PM profiles parameter must be activated, i.e. set to 1.
  • For the underposting correction function you have to activate the time controlled event “Start underposting correction“.
    • If you want to work with a key date for the underbooking correction, the global Use key date must be activated, i.e. set to 1.
  • In the global Load profiles for underpostings/overpostings parameter parameter, Pm_load profiles must be stored for which the corrections are to be carried out. Here, all PM_load profiles are stored by default.
  • The function can only be used for projects which do not allow actual postings for the future, i.e. which are used with Posting type = 0.

Underposting Correction

Information

  • The correction is triggered by the time-controlled event “Start underposting correction“ which is carried out every night to check whether there are underpostings. However, the correction itself does not take place EVERY night but only at a defined point in time:
    • If the global Use keydate setting is activated, the underposting correction is carried out on the key date. 
    • Otherwise it is always carried out when a new period starts, e.g., when using the PM_QUART load profile at the change of a quarter (i.e. at the turn of the year when using it at the change of the last quarter). For the PM_WEEK profile, correction is only carried out in the night from Sunday to Monday.
  • Unused effort is not only moved from the last period, but in principle from ALL periods in the past. In practice, unused effort should only exist in the last period if underposting correction is activated, as it is regularly moved. However, if unused effort is also found in periods dating further back, it is also moved.
  • The underposting correction only takes place until the resource assignment has set an actual end date. Once an actual end date has been set, underpostings are no longer changed. This prevents unused effort from being moved “infinitely” into the future.
  • If you want only overposting correction to be executed and not underposting correction, this can be achieved by simply deactivating the time-controlled event "Start underposting correction" while the booking correction is activated.

Example

  • Thomas Schaefer is planned using the PM_QUART load profile and in the last quarter of the year 2023 there are still 25 hours of unused remaining effort. We are in January 2024, hence in the 1st quarter of the year.

  • If underposting correction is active, the remaining available capacity is moved to the next period at a particular point in time, i.e. to the 1st quarter of 2024.

Overposting Correction

Information

  • If the entire planned effort is postponed or used up during the overposting correction and there is a remainder of postings that cannot be covered by any planned effort, the system remembers this uncovered effort, i.e. the uncovered effort is saved in a data table especially designed for this purpose (DT803 Posting history). You can create an individual module in which you can see this uncovered effort.
    • Overposting is never prevented due to insufficient remaining planned effort.
  • If postings are canceled and, as a result, the effort becomes available again, it is added to the existing planned postings and used for the upcoming postings or, if the entire planned effort has already been used up, it is used to cover the uncovered effort. 
    • In the case of a reverse posting, the remaining effort is always restored starting from the last period in which the effort was canceled, regardless of which remaining effort for which day is reduced by which exact daily actual posting.
  • If overposting correction is activated, it is carried out during every schedule calculation.

Example

  • 1) Benjamin Fischer is planned using the PM_MONTH profile. He has already recorded 2 hours on 12/03, and he still has free capacities in December 2023 and in January 2024:

  • 2) Benjamin Fischer records 4 additional actual hours on 12/03. They are then subtracted from the remaining capacity for December:

  • 3) He records an additional 2 hours. Since in December there is only 1 hour of remaining effort, the second hour is subtracted from the remaining effort of the next period, ie. from January 2024.

  • 4) An additional 8 hours on the following day further reduces the available remaining effort.

  • 5) If he now works for another 4 hours, the entire remaining effort will be used up. The remaining available effort is set to 0, but since there are still 3 hours for which no planned remaining effort is available, the system remembers this uncovered effort.

  • 6) If, for example, the actual effort from December 3rd is completely canceled, the remaining effort that was used for this day becomes available again. Since, however, there were 3 hours of uncovered effort, only 5 hours of available effort are created in January.

  • 7) If the actual effort from 12/05 is now canceled as well, these 8 hours are also added to the remaining effort, which (almost) restores the status from step 3 - with the only difference being that there are now 8 hours of actual effort on 12/04 and not on 12/03. However, the sum of actual effort & remaining effort remains the same: