The documentation from version 39.5.17 of PLANTA project can be found in the new PLANTA Online Help.
Please note
  • Below you find explanations (with examples) of the operating principles of date planning and scheduling in PLANTA project as well as descriptions of common application cases and of the behavior under particular settings. The program depictions used here are based on an older software status and are to be regarded functionally only.
  • General information on date, resource, and cost planning in PLANTA project including a calculation matrix can be found here.

Date/Resource Scheduling

Application Cases

Application Cases for Planning Strategies

Premises:
  • Active today line, Fix = 0, Planning early, CAP (as far as nothing else is specified)
Description Adher. to schedule Adh. to total float Adher. to capacity
Target How much overload arises for the employees if the dates are to be adhered to? How much buffer is available? How much overload arises for employees if the dates are adhered to? How long to tasks last taking account of capacity and requested dates? How long does a project last with predefined effort and limited capacity (no overload)?
Description of the planning method Task duration and dates are adhered to. If the task durations are longer than the remaining time horizon, the end date is shifted.
Overloads are shown
The project receives a requested end date.
The remaining duration of the task is calculated according to the resource effort. Floats are exploited. The overloads are smoothed. End dates are adhered to as far as the remaining time horizon is sufficient for the planned duration of the task.
The duration of a task is determined from
  • Effort
  • Available capacity
  • CAPload profile
  • Option: Planning with max. load/day
Planning Usually, Planned duration or alternatively Req. start - Req. end are entered (Req. start - Req. end dominates the Planned duration).
If no Planned duration has been entered, it is calculated by Req. start - Req. end.

Planning without load curves: When inputting the Planned duration of the task, the planned effort of the resource is allocated to the duration evenly.

If NO Planned duration of the task is entered, the system calculates the Remaining duration of the task by means of resource effort, CAP load profile and Max. load/day.
Usually, planned duration, or alternatively Requested start - Req. end.
If no Planned duration has been entered, it is calculated with Req. start - Req. end.

When you enter the Planned duration of the task, the Planned effort of the resource is allocated evenly to the duration.

If NO Planned duration of the task is entered, the system calculated the Remaining duration of the task by means of the resource effort, CAP load profile, and Max. load/day
Regardless of whether Planned duration has been entered or not, the Remaining duration is extended, as far as the Planned effort cannot be accomplished within the predefined time, or within the available float.
The requested date is overrun in consideration of the links if the duration of the tasks is too long.
No input of task duration or TA Req. start/Req. end required. Only input of effort in h for allocated resources. For the parameters, see above.
For tasks with resource assignments:.

Extend tasks before MA has reported hours.
In order to extend the task duration in days before hours have been reported, the Planned duration of the task is extended. Alternatively the effort can also be increased if the CAP load profile has been selected.

In order to increase the effort, the Planned effort is increased.
Increase of Planned duration, or Planned effort on employee level, provided that the CAP load profile has been selected. The Planned effort is increased on resource level, provided that the CAP load profile has been selected.
For tasks without resource assignment:

Extend tasks without actual start date.
Increase Planned duration on task level. Increase Planned duration on task level. Increase Planned duration on task level.
For tasks without resource assignment:

Extend tasks with actual start date.
Extend Remaining duration on task level or extend Requested end.
New: Remaining duration is calculated depending on the actual date.
Remaining duration = Planned durationActual duration , whereas:
Actual duration = today - Actual start date.

As before, open tasks remain with 1 remaining day as a reminder.
Extend Remaining duration on task level or extend Requested end.
New: Remaining duration is calculated regardless of the actual date.
Remaining duration = Planned durationActual duration , whereas:
Actual duration = today - Actual date.

As before, open tasks remain with 1 remaining day as a reminder.
 

Application Cases of Date Scheduling without Resources

Objective

  • To plan tasks depending on a specified task / work package duration.
Overview 1: Planned duration = 0
Application case Procedure Result
Plan task without date
  • Calculate project
Plan task with Requested start
Plan task with Requested start
Plan task from .... to .... see overview 2  

Overview 2: Planned duration > 0

Application case Procedure Result
The task has a runtime in days. Task is planned with:
Variant: Runtime with defined start date Task is planned with:
Variant: Runtime with defined end date Task is planned with:
The task has a runtime from .... to .... with defined start and end date (key dates) Task is planned with:
The task is to be shifted if a predecessor is shifted.
Runtime either by basic dates or specification in days, Fix = 0
  • Enter task with start and / or end date and / or Planned duration
  • Link predecessor to task
  • Calculate project
Task is planned with:
  • Start/end dates and Remaining duration according to requirement
  • Shifting of the predecessor causes the task to be shifted.

Behavior of TA Requested Dates and TA Remaining Duration when TA Actual SD is Set

Details Example date scheduling without resources
  • Initial situation
GR01502897-DE.png

GR01502898-DE.png

GR01502902-DE.png

GR01502901-DE.png

Application Cases of Date Scheduling with Resources

Time-Related Planning with Task Duration

Provisions
  • Planned duration
  • Load profiles not used, i.e. the load is distributed evenly over the available period without overloads being taken into consideration.
  • Resources are not loaded on non-working days (public holidays, vacations, ...).

Result

  • for planning with adherence to schedule
    • Planning along the duration without considering overloads.
    • Where possible, scheduling is carried out as a block, i.e. without interruption. Exception vacation: This resource is not scheduled during vacation.
  • for planning with adherence to total float
    • The planning is done along the duration without considering overloads but with utilization float per overloaded resource.
    • If there are hours left to be included in the planning, planning starts at the latest possible point in time. The project requested end date will not be overrun.
  • for planning with adherence to capacity
    • Standard: Planning is done without consideration of requested durations and requested project requested end dates, no overloads, no scheduling on non-available days.
      • Exception: If no available capacity is found up to the end of the planning period of the resource, loading starts at the earliest point in time, despite overload (like adherence to schedule).
Example:
  • Overload in planning with adherence to capacity with end period earlier than planned duration (provisions: Planned duration = 10 days, Planned effort = 100h, available capacity of the resource per day = 8h). The requirement cannot be fulfilled at any time. The resource is overloaded evenly.

GR01502908-DE.png

Planning with Requested Dates of the Resource

Planning with TAR Requested Start
Information Example
GR01501232-DE.png

Example

GR01501233-DE.png

Information

Example
  • As a result of the TAR Requested start, resource R1 has a reduced scheduling duration of 2 days. The effort for 16 hours will be distributed across the two days and the resource is overloaded. For resource R4, scheduling is distributed over three days without overload.
GR01501234-DE.png
  • If the task is scheduled with Sched. early and with adherence to schedule, the TA Requested start will be ignored.

Example

  • Since the task is scheduled late and adherent to schedule, TAR Requested start is ignored. The resource is scheduled on three days.
GR01501235-DE.png
  • If the task is adherent to total float or capacity and scheduled lately, a resource with a TAR Requested start is only adjusted up to this date; while all others are adjusted as before at the TA Earliest start.

Example

  • Although resource R1 is overloaded, the adjustment of the resource is not carried out at the PR Requested start, but only up to the TAR Requested start.
GR01501236-DE.png
  • If a task has started, the resource which has a TAR Requested start will start on this date; while all others have the same start as before. For splitting, the maximum of TAR Requested start and link date is applicable to the Earliest start.

Example

  • Resource R1 has a TA Actual start on 10/16/08, but only starts with the remaining loading at the TAR Requested start. This is determined by parameter DI001112 Split. = Y in window 9. This only takes effect if the task has started but not yet ended.
  • Resource R8 starts, as before, at the ‘today’ line.
GR01502920-DE.png

Planning with TAR Requested End
Information
  • If only one resources is assigned, the task ends (TA Earliest end) on the TAR Requested end if date-oriented planning is used, provided that there is no overload and the TAR dates are within the TA dates. Otherwise, TA duration = Planned effort / Max. load/day. For example, in loading with adherence to capacity, the TA is also extended.
  • If more than one resource is planned, the task duration applies; the resource with a TAR Requested end receives a shortened duration of TA Remaining duration – (TA Earliest end – TAR Requested end).
  • If the resource has a TAR Requested end, it ends on this date if date-oriented planning is used; all others end on the TA Earliest end.
  • If Sched. late is set for the task, it automatically becomes adherent to schedule if a TAR Requested end has been assigned.
  • If the task is adherent to float or capacity, and Schedule early is set, then any resource with a TAR Requested end will be smoothed up to this date. All others are adjusted at the TA Latest start + TA Remaining duration.

Planning with TAR Requested Start and TAR Requested End
Information
  • If the resource has a TAR Requested start and a TAR Requested end and no Max. load/day, in planning with adherence to schedule the duration is detected from the requested dates.
  • For loading with adherence to capacity, the TA is also extended.
Notes
  • TAR requested dates are only considered by the scheduling if they lie within the TA requested dates. If the TAR requested date is outside the TA requested dates, it has no effect on scheduling, as planning does not lead to the desired aim at this point in time. This also applies if a task is shifted, for example as a result of a link, so that the TAR requested dates do not lie within the TA Calk. start/TA Calc. end.
  • If no TA requested dates exist, TAR requested dates are only considered within the TA Calkc start/TA Calc. end.
Example 1 Example 2
  • A link shifts the above-mentioned task as follows:
  • Result:
    • The previous planning of the TAR requested dates are ignored.
    • Planning of the TAR does not have to be done from 09/10 - 09/15/08.

Overview of Application cases

Overview

  • Planning with adherence to schedule with linear load profile
Application case Procedure Result
Plan resource without dates
  • Assign resource to task
  • Enter effort
  • Calculate project
Plan resource with Requested start Note
  • The planning time of the resource is possibly shorter than the length of the task.
Plan resource with Requested end Note
  • The planning time of the resource is possibly shorter than the length of the task.
Plan resource with TAR Requested end Note
  • The planning time of the resource is possibly shorter than the length of the task.
Plan resource from .... to ....
  • Assign resource to task and enter effort
  • Enter start or end date in resources (TAR Requested start/Requested end)
  • Consider task date limits
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.

  • Planning with adherence to total float
Application case Procedure Result
Plan resource without dates
  • Assign resource to task
  • Enter effort
  • Calculate project
Plan resource with Requested start
  • Assign resource to task and enter effort
  • Enter start date in resources (TAR Requested start
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • If float is required, the task duration or the resource load can be extended backward.
Plan resource with TAR Requested end
  • Assign resource to task and enter effort
  • Enter end date in resources (TAR Requested end)
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • If float is required, the task duration or the resource load can be extended forward.
Plan resource from .... to ....
  • Assign resource to task and enter effort
  • Enter start or end date in resources (TAR Requested start/Requested end)
  • Consider task date limits
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • no float exploitation by the resource within the task period.

  • Planning with adherence to capacity
Application case Procedure Result
Plan resource without dates
  • Assign resource to task
  • Enter effort
  • Calculate project
Note
  • Planning time of the resource = task duration
  • If float is required, the task duration or the planning time of the resource can be extended.
Plan resource with Requested start
  • Assign resource to task and enter effort
  • Enter start date in resources (TAR Requested start) within the calculated start and end dates of the task.
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • End dates are possibly not considered.
Plan resource with Requested end
  • Assign resource to task and enter effort
  • Enter end date in resources (TAR Requested end) within the calculated start and end dates of the task.
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • Start dates are not considered.
Plan resource from .... to ....
  • Assign resource to task and enter effort
  • Enter start or end date in resources (TAR Requested start/Requested end)
  • Consider task date limits
  • Calculate project
Note
  • The planning time of the resource is possibly shorter than the length of the task.
  • Float is used if necessary. End date is not considered.

Effort-Oriented Planning

Objective
  • To plan commitments for employees, depending on the effort.
Requirements:
  • Planning with adherence to schedule:
    • Field Load profile = CAP
    • Max.load/day field is filled with a value > 0
    • Resource assignment with planned hours
  • Planning with adherence to total buffer and capacity:
    • Field Load profile = CAP
    • Resource assignment with planned hours
    • Optional: Field is filled with a value > 0
Details
  • The Remaining duration is calculated
  • Planning with adherence to schedule:
    • Remaining duration = planned hours / max. load
    • The effort (planned hours) is distributed across the calculated duration
  • Planning with adherence to total float
    • The Remaining duration is dependent on the available capacity of the basic period (value from resource data sheet) and on the available float of the time scheduling.
    • The effort (planned hours) is distributed across the calculated duration
  • Planning with adherence to capacity:
    • The Remaining duration is dependent on the available capacity of the basic period (value from the resource data sheet). Loading in takes place without overloads.
    • The effort (planned hours) is distributed across the calculated duration
Note
  • Optionally, the Max. load/day parameter may also be used for planning with adherence to total float and capacity. The Remaining duration will be calculated as for planning with adherence to schedule.
Example: Planning with adherence to schedule
  • Max. load/day = 5.5 hours
  • Planned hours = 60 hours
  • Remaining duration = 60 / 5,5 = 10,9 days, rounded = 11 days since calculation only works with whole days.
  • Distribution of hours: 10 days @ 5.5 hours, 1 day @ 5 hours
Example: Planning with adherence to total float
  • Max. load/day = empty
  • Planned hours = 60 hours
  • available capacity of the basic period = 8 hours – 10% basic load = 7.2 hours
  • Remaining duration = 60 / 7,2 = 8,3 days, rounded = 9 days since calculation only works with whole days. If the resource is overloaded, the remaining duration will be extended up to the point where the overload no longer occurs
  • Distribution of hours:
  • without overload: 8 days @ 7.2 hours, 1 day @ 2.4 hours
  • with overload: dependent on the Remaining duration. Cannot be determined in advance because of capacity adjustment.

Application Examples

Information
  • A few application examples are provided below to illustrate the relationship between different factors that influence scheduling.
Notes
  • Unless stated otherwise, the examples are based on the settings of the standard installation and the linear load profile. (= The DI001452 Load profile data field is empty)
  • If the parameter settings are different, the results may vary accordingly.
Examples
  • Overview and short description of application cases:
No. Application case Result
1 Planning with adherence to schedule with several resources
  • Task with several task resources
  • The Planned duration of the task is preset.
  • Planning type = adherent to schedule
  • The planning is carried out by the scheduling along the duration of the task.
  • Overload is not prevented by scheduling.
  • Overloads are not displayed.
2 Planning with adherence to total float with several resources
  • Task with several task resources
  • The Planned duration of the task is preset.
  • Planning type = adherent to total float
  • Scheduling carries out the planning along the duration of the task.
  • Scheduling does not prevent overload.
  • The float of overloaded resources is used to prevent possible overloads. If there is not sufficient float, resources will be overloaded
  • Resource 1 with overload: Float is used
  • Resource 2 without overload: Starts at the earliest start date.
3 Planning with adherence to capacity
  • Task with several task resources
  • The Planned duration of the task is preset.
  • Planning type = adherent to capacity
  • The planning of the task by the scheduling is carried out without consideration of the Planned duration of the task.
  • Resources are not overloaded.
  • The float of overloaded resources is used:
  • Resources are not planned on non-working days.
4 Resources with vacation, planning with adherence to schedule
  • Resource with vacation
  • Linear load
  • The vacation duration is shorter than the task duration.
  • Planning type = adherent to schedule
  • The planning is carried out in a block by the date scheduling.
  • The resource is not planned by the scheduling during its vacation.
  • On working days, the resource is possibly planned with overloads.
5 Resources with vacation < task duration, planning with adherence to schedule
  • Resource with vacation
  • Linear load
  • The vacation duration is longer than the task duration.
  • Planning type = adherent to schedule
  • The planning is carried out by the date scheduling before or, the latest, at the beginning of vacation.
  • Due to the unavailability of the resource, the load is marked as overload during vacation.
  • If the entire task is during vacation, loading begins on the calculated start date of the task.
6 Planning with vacation
  • Vacation is entered for a resource,
  • Linear load profile
  • The vacation duration is shorter than the task duration.
  • Planning type = adherent to total float
  • The planning by scheduling is carried out in a block outside the vacation time.
  • Available float is used. If the float s used, the resource is overloaded by the scheduling.
  • The resource is not planned during vacation.
  • The planning is not splitted.
7 Planning with adherence to capacity with vacation
  • Vacation is entered for a resource,
  • Linear load profile
  • The vacation duration is shorter than the task duration.
  • Planning type = adherent to capacity
  • The planning by scheduling is carried out in a block outside the vacation time.
  • Available float is not planned during vacation.
8 Planning with adherence to total float with Requested end and Fix = 0
  • Task with several task resources.
  • The Planned duration is preset.
  • Requested end on a task
  • Fix TA parameter = 0
  • The vacation of a resource is shorter than the task.
  • Planning type = adherent to total float
  • The planning of the task is carried out by the scheduling at the Requested end.
  • By setting the Fix parameter = 0, the Requested end is overrun if necessary.
  • No consideration of float and possible overload since it is loaded with adherence to schedule due to the input of a Requested end.
  • The task is not moved.
8.1 Planning with adherence to total float with Requested end and Fix = 1
  • Task with several task resources.
  • The Planned duration is preset.
  • Requested end on task
  • Fix TA parameter = 1
  • The vacation of a resource is shorter than the task.
  • Planning type = adherent to total float
  • The planning of the task is carried out by the scheduling at the Requested end.
  • By setting the Fix parameter = 1, the Requested end is met and loaded with adherence to schedule.
  • No consideration of float and overload.
  • The task is not moved.
8.2 Planning with adherence to total float with TAR Requested start
Task with several task resources
9 Planning with adherence to total float with Requested end and Fix = 1
  • Using the Fix = 1 parameter, the task is loaded with adher. to capacity.
  • Overloads may occur.
10 Planning a task, which has a predecessor, with adherence to schedule, Requested start and Fix = 0
  • Vacation is entered for a resource
  • Linear load profile
  • The vacation duration is shorter than the task duration.
  • Task with predecessor and Requested start, Fix = 0
  • Planning type = adherent to schedule
  • The task does not start at the Requested start, but after the predecessor has finished.
  • The vacation of the resource is taken into consideration.
  • Remaining duration = Planned duration
11 Planning with adherence to total float with effort > Availability
  • Task with several task resources
  • The Planned duration is preset.
  • The capacity required for the desired duration exceeds the available capacity
  • Planning type = adherent to total float
  • The scheduling uses available float.
  • If there is no more float available, planning is carried out in a block at the latest time possible.
12 Planning with adherence to capacity with effort > availability
  • Task with several task resources
  • The Planned duration of the task is preset.
  • The capacity required for the desired duration exceeds the available capacity.
  • Planning type = adherent to capacity
  • Scheduling uses available float. Scheduling is delayed until loading in is possible in a block. Possibly the project end date is exceeded.
  • The resource is not planned during vacation, the task is not splitted
13 Planning with adherence to total float of a task with predecessor, Requested end and Fix = 0
  • Vacation is entered for a resource
  • Linear
  • The vacation duration is shorter than the task duration.
  • Task with predecessor and Requested start
  • Fix TA parameter = 0
  • Planning type = adherent to total float
  • The task does not start at the Requested start, but after the predecessor has finished.
  • The vacation of the resource is taken into consideration.
  • Remaining duration = Planned duration
  • Float is not used since a task with date is always loaded with adherence to schedule automatically.
14 Planning with adherence to capacity of a TA with predecessor, Requested end and Fix = 0
  • Vacation is entered for a resource.
  • Linear
  • The vacation duration is shorter than the task duration.
  • Task with predecessor and Requested start
  • Fix TA parameter = 0
  • Planning type = adherent to capacity
  • The task does not automatically end at the Requested end, but after the predecessor has finished.
  • The vacation of the resource is taken into consideration.
  • Remaining duration = Planned duration
  • Float is not used since a task with date is always loaded with adherence to schedule automatically.
15 Calc. start when several task resources report
  • Planning of several resourcen to one task and reporting of hours:
  • just as planned
  • earlier than planned
  • later than planned
  • The resources are planned with their remaining effort from the TAR Actual start by the scheduling.
  • If the day after the Actual start is no working day, the resource is planned on the next working day.
  • The resource is possibly overloaded.
16 Reporting during vacation
  • several resources are assigned to a task.
  • A resource is on vacation over the complete task duration, however he/she reports hours.
  • The planning of the resources without vacation is carried out by the scheduling according to the default specifications.
  • The resource which has reported during vacation is planned for the first working day after the report.
  • The resource is possibly overloaded.

Information

  • Below, the application cases specified above are displayed in detail with examples.

Planning with Adherence to Schedule with Several Resources

Objective
  • Impact of planning with adherence to schedule with several resources on time scheduling
Details
  • A project is created with several tasks and several task resources.
  • The Planned duration of the tasks is preset or calculated from Planned effort / Max. load/day.
  • The planning type is always adherent to schedule.
  • The resources are planned with the CAP load profile.
Information
  • * The planning is carried out by the scheduling along he duration of the task.
  • Overloads are marked and won’t be distributed.
  • The resources are planned by the scheduling according to PR Requested start.
Example
  • The project starts on 10/31/08
  • Resource R1 is planned in TA 01 with overload due to insufficient availability:

GR01502800-DE.png

Notes

  • In order for the scheduling not to overload the resources, the CAP load profile is required. In this case,
    • the available float can be used optimally for planning with adherence to total float
    • the project can be moved according to the available capacity for planning with adherence to capacity.

Planning with Adherence to Total Float with Several Resources

Objective
  • Impact of planning with adherenc eto total float with several resources on time scheduling
Details
  • A project is created with several tasks and several task resources.
  • The Planned duration of the tasks is preset.
  • Planning type is adherent to total float.
Information
  • The available float is used resource-related by the scheduling if necessary.
  • A resource with overload is moved by the scheduling according to the available float.
Example
  • A project starts as planned on 11/25/08
  • Resource R1 has sufficient free capacity in CW48. An overload occurs. The available float is used and the Calc. start is moved.
  • The loading of resource R2 without overload remains unchanged. Calc. start for resource R2 starts on the earliest start date.
  • The duration of task TA 01 is extended:

GR01502801-DE.png

Planning with Adherence to Capacity with Several Resources

Objective
  • Impact on the capacity planning of the time scheduling
Details
  • A project is created with several tasks and several task resources.
  • The Planned duration of the tasks is preset.
  • The planning type is adherent to capacity.
Information
  • Resources are planned without overload by the date scheduling
  • In the case of resource shortage, the task is extended even beyond the Requested end.
Example
  • PR Requested start: 10/31/2008
  • PR Requested end: 12/31/2008
  • Planning is carried out by the scheduling without considering the task duration.
  • No overloads are created.
  • Resources are not scheduled on days on which they are unavailable.

GR01502802-DE.png

Example

  • The PR Requested end of the project specified above is brought forward to 12/19/08 in order to simulate a resource bottle neck.
  • Resources are planned by the scheduling without overload as required.
  • The PR Requetsed end is overrun by 6 days:

GR01502803-DE.png

Planning with Adherence to Schedule with Vacation

Objective
  • To show the impact of vacation on the time scheduling when planning is carried out with adherence to schedule.
Details
  • Vacation is entered for a resource.
  • The planned editing period of the task does not lie completely within the vacation of the resource.
  • Planning is carried out with adherence to schedule.
Information
  • Scheduling is carried out along the task duration.
  • Vacation is taken into consideration.
  • Scheduling is possibly carried out with overloads.
Example
  • Resource R2 has four days of vacation in CW45:

GR01502804-DE.png

  • Resource R2 is not planned by the scheduling during vacation. The load of resource R2 is decreased in the week of vacation CW45 accordingly, the effort of the remaining weeks is increased.
  • Overloads are displayed.

GR01502805-DE.png

Vacation Longer than Task Duration

Objective
  • To show the impact of vacation that is longer than the task duration on the time scheduling.
Details
  • The planned processing period of the task lies completely within the vacation of the resource.
  • Planning is carried out with adherence to capacity and with linear load profile.
Information
  • Planning is carried out by the scheduling at the time available for the task.
  • Planning is carried out on the first day of vacation.
Example
  • The vacation of resource R2 starts before the end of task TA 01 and extends completely across the duration of task TA 02.

GR01502806-DE.png

  • Planning of resource R2 for task TA 01 is carried out up to the start of the vacation.
  • For task TA 02, it is carried out completely at the start of the vacation, as the whole task falls within the vacation period. The resource is overloaded.

GR01502807-DE.png

Planning with Adherence to Total Float with Vacation

Objective
  • To show the impact of resource planning with adherence to total float with vacation on the time scheduling
Details 1
  • Vacation is entered for a resource.
  • The planned editing period of the task does not lie completely within the vacation of the resource.
  • Planning is carried out with adherence to total float with a linear load profile.
Information
  • Planning is carried out along the duration of the task taking account vacation and float, if available.
  • If the float is used up, it is overload.
  • Resources are not scheduled during vacation.
Example
  • Resource R2 is on vacation in CW 46 and is not scheduled during this time.
  • As the available capacity is insufficient even when the float is used, resource R2 is overloaded:

GR01502809-DE.png

Planning with Adherence to Capacity with Vacation

Objective
  • To show the impact of planning with adherence to capacity with resource vacation on date scheduling.
Details
  • Vacation is entered for a resource.
  • The planned editing period of the task does not lie completely within the vacation of the resource.
  • The available capacity of the resource is greater than the required capacity.
  • The Planned duration of the task is preset.
  • Planning with adherence to capacity is used with a linear load profile.
Information
  • Resources are planned by the scheduling with adherence to capacity.
  • Resources are overloaded if there is not sufficient capacity due to the preset duration.
  • Resources are not scheduled during vacation.
Example
  • Planning is carried out by the scheduling along the duration of the task, taking account of vacation.
  • Resource R2 is not scheduled during its vacation in CW 48.
  • Scheduling of R2 is carried out with overloads due to the specified duration:

GR01502810-DE.png

Planning with Adherence to Total Float with Task Requested ED and Fixing = 0

Objective
  • To show the impact of planning with a non-fixed Requested end on date scheduling.
Details
  • The Planned duration of the task is preset.
  • The task has a Requested end.
  • DI009480 Fix TA parameter = 0
  • Planning is carried out adherent to total float and with linear load profile.
Information
  • The initial task duration is retained.
  • Resources are not scheduled during vacation, which can be seen for R2 in CW 48 in the example below.
  • Float times are ignored since loading is carried out with adherence to schedule due to the set Requested end. Scheduling is carried out with overloads, if necessary.
  • TAR Calc. end 12/11/08 is later than the Requested end 12/05/08 if this cannot be prevented due to the task duration.
Example
  • Due to the preset task duration, the Calc. end is later than the Requested end
  • The deviation from the Requested end is displayed for task TA 01.
  • Resource R1 is overloaded.
  • Resource R2 is not scheduled during its vacation in CW 48.

GR01502811-DE.png

Planning with Adherence to Total Float with Task Requested ED and Fixing = 1

Objective
  • To show the impact of planning with a fixed Requested end on time scheduling.
Details
  • The task has a Requested end.
  • DI009480 Fix TA parameter = 1, the task is therefore fixed to the date.
  • Planning type is adherent to total float.
Information
  • TA Requested end is not moved.
  • Resources are not scheduled during vacation.
  • An overload is scheduled if required.
  • A long duration of a task with fixed Requested end may lead to the Calc. start being earlier than the Calc. start of the project. Calc. start of the project is thereby brought forward. This only applies if the ‘today’ line is not active.
Example
  • TAR Calc. end corresponds to the Requested end
  • The task duration is not extended.
  • The resource is overloaded.
  • Resource R2 is not scheduled during its vacation in CW 46.

GR01502812-DE.png

Note

  • Task dates with Fix parameter = 1 have a similar effect to actual dates, i.e. they are not shifted by the active ‘today’ line if Requested start or Requested end are entered.

Planning with Adherence to Total Float with TAR Requested SD

Objective
  • To display the impact of planning with adherence to total float of TAR Requested start on time scheduling
Details
  • Scheduling of several tasks.
  • Several task resources are assigned to a task with Requested start.
  • The task resources have different TAR Requested start.
  • Planning type is adherent to total float.
Information
  • Resources are overloaded if necessary.
  • Resources are not scheduled during vacation.
  • The planning of the resources is carried out on the TAR requested dates, as far as they lie within the period from Calc. start to Calc. end.
Example
  • Scheduling loads in the resources for the time available.
  • Resources R3 and R4 are overloaded:

GR01502813-DE.png

Notes

Planning with Adherence to Capacity with Requested ED and Fixing = 1

Objective
  • To show the impact of planning with adherence to capacity with Requested end without fixing on date scheduling.
Details
  • The task has a Requested end.
  • DI009480 Fix TA parameter = 1
  • The planning type is adherent to capacity.
Information
  • The Requested end is not overrun by the scheduling.
  • Floats are ignored.
  • Scheduling is carried out with overloads, if necessary.
  • Resources are not scheduled during vacation.
Example
  • Float is ignored since due to Requested end with _Fix parameter = 1 loading is carried out with adherence to schedule.
  • Overloads are scheduled so that the Requested end can be met:

GR01502814-DE.png

Planning with Adherence to Schedule of a TA with Predecessor, Requested SD, and Fixing = 0

Objective
  • To show the impact of planning of a task with adherence to schedule with predecessor, Requested end with Fix parameter = 0 on date scheduling.
Details
  • Several task resources are assigned to a task with predecessor and non-fixed Requested start.
  • The planned editing period of the task does not lie completely within the vacation of the resource.
  • The processing of the predecessor takes longer than planned.
  • The planning type is always adherent to schedule.
Information
  • Scheduling may also shift the task and plan resources with overloads.
  • The deviation from the Requested start is displayed.
  • Resources are not scheduled during vacation.
Example
  • The predecessor takes longer than planned.
  • The successor starts later, the task duration is not extended. The task is scheduled with overloads.
  • The deviation from the Requested start is displayed for task TA 02 by the interval between the triangle and the start of the bar.
  • Resource R2 is not scheduled during its vacation in CW 49.

GR01502816-DE.png

Planning with Adherence to Total Float of a TA with Predecessor, Requested ED and Fix = 0

Objective
  • To show the impact of planning with adherence to total float for a task with predecessor, Requested end and Fix parameter = 0 on date scheduling.
Details
  • Several task resources are assigned to a task with predecessor and non-fixed Requested end.
  • Planning type is adherent to total float.
Information
  • Scheduling shifts the task if the predecessor takes longer than planned.
  • The deviation from the Requested end is displayed.
  • The resource is overloaded, if necessary.
  • Resources are not scheduled during vacation.
Example
  • Task 01 is linked to task 02 via an FS link.
  • Since task 01 is delayed, task 02 is shifted beyond its Requested end. A deviation of 17 days is displayed.
  • The resources are planned with overload.
  • Resource R2 is not scheduled during its vacation in CW 48.

GR01502820-DE.png

Planning with Adherence to Capacity of a TA with Predecessor, Requested ED, Fix = 0

Objective
  • To show the impact of planning with adherence to capacity of a task with predecessor, Requested end and Fix parameter = 0 on date scheduling.
Details
  • Several task resources are assigned to a task with predecessor and non-fixed Requested end.
  • Planning is carried out with adherence to capacity and with linear load profile.
Information
  • Scheduling shifts the task if the predecessor takes longer than planned.
  • The deviation from the Requested end is displayed.
  • If necessary, the resource is overloaded since the Requested end causes the planning to be carried out with adherence to schedule.
  • Resources are not scheduled during vacation.
Example
  • Task 01 is linked to task 02 via an FS link.
  • Since task 01 is delayed, task 02 is shifted beyond its Requested end. A deviation of 24 days is displayed.
  • The resources are planned with overload.
  • Resource R2 is not scheduled during its vacation in CW 48.

GR01502821-DE.png

Planning with Adherence to Total Float Higher than the Availability

Objective
  • To show the impact of planning with adherence to total float with effort higher than availability on date scheduling.
Details
  • The Planned duration of the tasks is preset.
  • The effort is higher than the availability of the resource in the planned processing period.
  • Planning is carried out with adherence to total float and with linear load profile.
Information
  • The float of the overloaded resource is used:
  • Scheduling is carried out at the latest possible point in time.
Example
  • The Planned effort of 150h within 15 days exceeds the available capacity of the resource. Task 01 is therefore scheduled at the latest point possible:

GR01502817-DE.png

Planning with Adherence to Capacity with Effort Higher than the Availability

Objective
  • To show the impact of planning with adherence to capacity with effort higher than the availability on date scheduling.
Details
  • The Planned duration of the tasks is preset.
  • The effort is higher than the availability of the resource in the planned processing period.
  • Planning is carried out with adherence to capacity and with linear load profile.
Information
  • Resources are not scheduled during vacation.
  • Scheduling shifts the task until it can be planned in a block. This means that the project end date may also be moved.
  • Scheduling evenly distributes the effort within the Planned duration across the task duration. The resource is overloaded.
  • The float is ignored, the task duration is not extended.
Example
  • Scheduling shifts the task until it can be planned in a block.
  • Resource R2 is not scheduled during its vacation in CW 45.
  • Resource R1 is overloaded.
  • PR Requested end is overrun:

GR01502818-DE.png

Note

  • If the CAP load profile is used, available float is taken into consideration.

Work Reporting of Several Task Resources

Objective
  • To show the impact of work reporting with planning with adherence to schedule without requested dates and with several resources on date scheduling.
Details
  • Several task resources with CAP load profile are assigned to a task.
  • No TAR Requested start and Requested end set.
  • The planning type is always adherent to schedule.
  • Split parameter = Y
Information
  • Calc. start of the task and all task resources is shifted to the next working day after the latest work reporting.
  • Late work reporting can thus lead to a shift of the Calc. end.
Example
  • Resource R2 is on vacation in CW 49.
  • Dates before reporting of hours:

GR01502822-DE.png

  • After reporting to 11/10/08 by R1 and carrying out a date scheduling, the Calc. start of task 01 is shifted from 11/04/08 to 11/10/08:

GR01502823-DE.png

Work Reporting on Vacation

Objective
  • To show the impact of hours reported on vacation on time scheduling.
Details
  • Several task resources are assigned to a task.
  • A resource is on vacation for the whole task duration and reports actual hours for the vacation period.
  • The resources are planned with a linear load profile.
Information
  • Resources are not scheduled during vacation.
  • Resources that report hours for the vacation period receive the remaining effort on the next working day after reporting. The resource may be overloaded.
  • Scheduling of resources without vacation is carried out in accordance with regular planning.
Example
  • Resource R8 is on vacation from 11/05/08 to 12/16/08. The total effort for task 01 is scheduled on the first day of the vacation and the resource is overloaded:

GR01502824-DE.png

  • Hours are reported during the vacation period. At task and task-resource level, scheduling reduces the reported hours from the remaining effort and overload.
  • The remaining effort is scheduled on the day after work reporting:

GR01502825-DE.png

Planning with Adherence to Schedule with CAP

Information Note
  • Even with due-date oriented planning, the resource-capacity will be optimized within the TA Remaining duration. Practical experience has indicated that by simply setting "CAP" in conjunction with planning with adherence to schedule, overloads can be significantly reduced. This positive effect is found particularly when the deployment of individual employees is being planned.
Example
TT_CAP1.png

TT_CAP2.png

TT_CAP3.png

Note

  • If the PR or TA has requested end dates or the TA has a Remaining duration and the resource cannot be planned within this period, the overload is distributed evenly across all load records on the resource’s working days within the specified period if planning is carried out with adherence to schedule.

Planning with Adherence to Total Float with CAP

Objective Details
  • TA Remaining duration is calculated just as with date-oriented planning, but it may be extended up to the end of the total float time or the planning horizon if there is insufficient capacity.
  • TA Calc. start is moved to the first day with remaining capacity, provided that its start is yet earlier than the TA Latest start. Otherwise, TA Calc. start = TA Latest start applies.
Example
GPT_CAP1.png
GPT_CAP2.png

  • Without a Max. load/day, the resource is scheduled with the maximum load per day specified in DI000804 Def. max. load in the resource data sheet.
GPT_CAP4.png

Note

  • If the Remaining effort cannot be planned within the remaining capacity of the float since the float is too small, the overloads are distributed evenly across the loading period.
GPT_CAP3.png

Planning with Adherence to Capacity with CAP

Information
  • The resources are loaded independent of one another, and calculated durations and dates are summarized to the task.
Notes
  • If the resources assigned to a task include some with CAP and some without, then the CAP resource assignments take precedence, i.e. the TA duration is determined from the CAP resource assignments. The non-CAP resources are planned on the basis of the calculated TA duration and no resource capacity adjustment is carried out for them.
    • Exceptions:
      • Remaining effort = 0 (CAP is not considered in the calculation of the TA duration)
      • MAN load profile (cf. respective section).
  • When planning with adherence to schedule and total float is carried out with CAP, overloads are distributed equally across the resource’s working day on all the load records.

Example

KT_CAP1.png

KT_CAP2.png

MAN Load Profile

Information
  • Load records of MAN resources have an effect similar to that of an actual date. The planning data is fixed and is not moved by scheduling.
  • Actual dates do not change the MAN planning either.

Example

MAN1.png

  • In a task with TA Requested start before the first MAN load record, the task starts at the TA requested start. The resource is planned for the MAN date.
MAN2.png

  • The TA can, e.g., be extended for example by planning with CAP resources. The duration of the task is not reduced by CAP planning. The minimum task duration is the timescale of the MAN dates.
    • When planning with MAN resources, resource dates override the other planning requirements. This also applies for the project key dates.
    • As soon as a MAN resource is assigned to a task, scheduling of the resources is based on the TA requested date and not on the PR requested date. The project basic dates are thus overrun.
    • As far as no TA Requested start has been set, the task starts at the PR Requested start.
Only CAP resources CAP & MAN resources
MAN3.png MAN4.png
MAN5.png

  • This does not automatically make the task adherent to schedule as soon as a MAN resource has been assigned to it. The TA can be shifted until it reaches MAN dates.
  • The Active today line, which can be controlled by the administrator via the DI000158 Active today line, does not shift dates planned with MAN.
  • Links: take effect until they reach MAN dates. (e.g. for multiple resource planning with MAN and CAP)
    • The impact when one resource is set with MAN and others with different load profiles for Hammock tasks or BLD, is similar to that described above.
      • The dates of the MAN planned resources are not shifted.
  • Duration Hammock task or Summary task MAN period
  • In the case of several resources with MAN, the earliest and latest dates of all MAN resources are used to plan the TA.
  • Via TA Req. start, the task can only start earlier than the earliest MAN planning.
  • As a result of TA Req. end, the task can only start earlier than the latest MAN planning.
  • Splitting parameter = Y: The parameter has no effect on MAN resources. For resources not planned with MAN, this parameter has the same effect as before.
  • Load records of MAN resources can only be deleted manually.
Details of new behavior for reporting hours
  • Planned hours of the MAN load profile that are before the first update report are deleted and not distributed to future loadings.
  • Reporting of hours worked with a different value than planned do not affect the other load records.
  • Update reports do not change the scheduled hours.
  • Hours planned for task resources using the MAN load profile are not shifted by scheduling.

Objective

  • Specifically preset loads per day.
Procedure
  • The user chooses the MAN load profile for the resource and enters the required loads in the Rem. load field in existing load records. This generates a discrete load distribution. It is also possible to set up new load records.
  • Appropriate module designs permit loads to be entered in the Gantt chart, directly below the bars. If the load is being displayed in summary form on a less detailed time scale (e.g. by week), then after the values have been input they are automatically distributed across the individual days.
Example
  • The weekly loads below the bars or the daily loads below the resource assignments can be edited.
GR0110SJ-DE.png

Typical application in practice:

  • Free capacity load distribution across the task duration.
  • Manual distribution of loads to achieve capacity adjustment.
  • Project meetings on fixed dates
Procedure
  • The MAN load profile is set manually for the resource.
  • Effort is entered in the Rem. effort field in the load record.
  • The old value in the Rem. load of the load record is retained and can be changed manually.
  • TAR Remaining effort = the sum of the R load values for all the associated load records, i.e. the loads are cumulated upwards.
  • The TA Remaining duration = 0, if an actual end date is set.

  • In resource assignments with MAN load profile:
    • If no TA actual start is set:
      • Duration from the first up to the last load record
    • If no TA actual start is set:
      • If no TA actual end is set:
        • Split = No
          • Duration from the first work reporting date up to the last load record
        • Split = No
          • Duration from the first up to the last load record without actual load
      • If TA actual end is set:
        • Remaining duration = 0
Note
  • An entry overrides the calculation (not in the case of tasks with subprojects)

Notes

  • Date shifts can result in the weekly loads shown under the bar being different from those shown previously. This is because loads are stored to the day but are only shown to the nearest week.
  • For MAN resource assignments, no capacity adjustment is carried out. Such tasks are loaded in on an adherense to schedule.
Objective
  • To show the behavior of manually scheduled dates in update reporting.
Details
  • Planned hours of the MAN load profile which are earlier than the first hour reported are deleted.
  • Reporting of hours worked with a different value than planned do not affect the other load records.
  • Planned hours that are earlier than the last reported hours are not distributed to future loadings.
  • Update reports do not change the scheduled hours.
  • Hours planned for task resources using the MAN load profile are not shifted by scheduling.
Notes on duration changes
  • Changes to the TA Planned duration or TA Remaining duration has no mutual influence if there are actual dates. The TA Planned duration is retained (initial value for comparison purposes) and the TA Rem. duration is obtained by calculation. If it is required to change the duration of the task, there are two possibilities:
    • Manual entry of new load records, following on from the existing ones. In the next calculation of the schedule, a new TA Remaining duration is determined.
    • Empty the Load profile data field, change the TA Planned duration, CS. After this, specify the new loads.
Notes on redoing manual load requirements

BLD Load Profile (Basic Load)

Information
  • The Basic load (BLD) load profile can be used to distribute loads evenly across the entire float time of a task. In doing this,
  • This load profile is used for resource employment planning for accompanying activities. E.g.
    • basic load tasks (e.g. 1h/day for service activities) or basic load projects
    • project management (e.g. 1 hour/day throughout the entire duration of the project, or 100 hours distributed across the entire project duration)

Peculiarities of the BLD load profile

  • If TA Remaining duration is specified, it will be taken into account.
  • If a BLD load profile is assigned to a task and no TA Remaining duration is available, the Remaining duration of the task is calculated by the TA Earliest start (= TA Calc. start) up to the TA Latest end (= TA Calc. end).
  • If a value is entered in the Max. load/day field, the Remaining effort = Max. load/day * Remaining duration is calculated.
  • If a value is entered in the Max. load/day field, the Remaining effort is distributed evenly over the Remaining duration ( Behavior as without load profile: linear load distribution).
  • Tasks with a BLD resource assignment will always be planned with adherence to schedule. Capacity adjustment will therefore not be applied to them.
  • Resources are not scheduled on their vacation.
  • The task can be stretched across the complete project duration if the Hammock task parameter has been activated (e.g. for project management or basic load projects).
    • With the help of links, a Hammock task can be extended across particular project tasks. For example, the link predecessor can be the Project kick-off milestone and the successor can be the End of planning phase milestone. The hammock task will be stretched between these two tasks if it is connected to both tasks by links.

Example 1 Project management task

  • For project management, a load of 1 hour/day is planned in over the entire duration of the project. For this purpose, 1 hour is entered in the Max. load/day field, and the Hammock task checkbox is activated.
Example 2 Project management task
  • For project management, 100 hours are planned, distributed evenly over the entire duration of the project. For this purpose, no entry is made in the Max. load/day field, and 100 hours are entered in the Remaining effort field and the Hammock task checkbox is activated.

Example construction planning

  • For TA KON load-bearing structure, 80 hours are planned over a period of 15 days (Remaining duration).
GR0110ST-DE.png

  • If this TA is to use the complete float time, BLD will be used for resource assignment and the Hammock task is activated. The task can now last 38 days instead of 15. This means that the task uses up its buffer completely. Scheduling then ignores the planned duration of 15 days.
GR0110SU-DE.png
  • If the predecessor tasks are delayed, the duration of task 2110 will be reduced accordingly.

Example PPMS Standard:

GR01503559-DE.png

  • The project is planned with PR Requested end up to 05/31/09, adherent to capacity
  • TA Meeting is a hammock task, resource planning 0,6h/day, BLD load profile
Note on effort oriented planning:
GR01503560-DE.png
  • The duration calculation for effort controlled tasks (here TA 02, 03, 04) is carried out with the help of the following parameters:
  • If there are no other restrictions by dates, successor, etc., then the task with the highest effort is calculated first since it has the lowest float.
  • In CAP the TA duration only serves to calculate the schedule outline?. I.e. within the calculated duration, the resource is planned where there is availability. If no availability can be found up to the end of the resource calendar, planning is carried out at the earliest possible date after the end of the planning horizon. In the above mentioned example, hence on 06/01/09 (=1 working day after the end of the project)

Planning with Adherence to Total Float and SS Link

Objective
  • The duration of a task is extended because of overload, provided that float times are available.
Details
  • Planning with adherence to total float
  • Two tasks are linked to each other via an SS link.
  • Both TA have an FS link to Milestone 1.
  • Resources are scheduled with CAP load profile.
  • Both tasks are planned with
Information
  • The float determined by the date scheduling are used.
    • The durations of the task are automatically increased up to the end of the float period only, in order to avoid this overload. In this example, the duration of the TA 01 task is extended up to Milestone MS 1.
C01500373-DE-00024.gif
  • Behavior of the date scheduling
    • Time scheduling determines the earliest and latest dates.
    • The float is always determined on the basis of the difference between earliest and latest start dates or end dates.
    • The latest start date of TA 01 is determined on the basis of Milestone MS 1 and task TA 02. The links are adhered to.
    • If Requested end and Requested start is deleted by MS 1 (link to TA 02 is maintained), then the Requested end of the project function as a float limit.

FAQs on Date Scheduling

Working Time Reporting during Vacation

FAQ - Question/Answer
  • Question: Can a resource record working hours for a day on which he/she is really on vacation, i.e. for a day for which Work = N is entered?
  • Answer: Yes. Here, Work = N is ignored.

The Effect of Capacity Adjustment on Other Projects

Information
  • If the impact on other projects is to be considered in the capacity adjustment, then all affected projects which have a lower priority than the one of interest must be included in the calculations. The Replanning (Calculation of all Planning Objects) does this automatically.

Capacity Adjustment Appears to be Incorrect

FAQ - Question/Answer
  • If the results of a capacity adjustment run appear incorrect, or if there are still overloads in the utilization diagrams, this is often merely a problem of visualization since PLANTA project plans on a daily basis and the utilization diagrams are often viewed in weekly format only.
    • Remedy: view the utilization diagrams in daily format.

Inexplicable Overload in Planning with Adherence to Capacity

FAQ - Question/Answer
  • A resource shows high overloads even though it is supposed to have been planned in with adherence to capacity. What checks should be carried out?
    • Is the Adjustment by effort code or Adjustment by costs set to Y for the resource? If adjustment is set to N then there will be no capacity adjustment for the resource, but instead the calculations will be planned with adherence to schedule.
    • Do all projects to which the resource is assigned have a priority greater than the value for Adherent to total float up to Priority (see the model parameters)? Projects for which this does not apply will be planned on adherence to schedule or buffer, and may cause resource overloads.
    • Have requested dates or actual dates been entered for any of the tasks to which the resource is assigned? When these are taken into account by the scheduling procedures, they may prevent capacity adjustment. * If the task lies beyond the planning horizon of the resource, the system assumes that there is unlimited capacity, but the loading will nevertheless be defined as an overload.
  • Certain tasks may continue to cause overloads although all of the above points are met. What else should be checked?
    • These tasks may lie beyond the planning horizon for the resource. The system then assumes there is then unlimited capacity, but the loading in will nevertheless be defined as an overload.
    • The load (per period) can be so large, that the available capacity is not sufficient in any period.
    • Summary tasks and hammock tasks cause planning of resources with adherence to schedule. This also applies in some cases for structure tasks. For more information, see the corresponding sections.
Example
  • For a task with Planned duration of the task = 10 days, an effort of 100 hours is entered. This corresponds to a load of 10 hours/day. For an employee resource, however, the available capacity is only 7.75 h. As a result, the task duration would have to be extended to 13 days.
  • Remedy:
    • enter the CAP load profile for the affected tasks in the Resource assignment to task.
      • In planning with adherence to total float, the TA float is used.
      • Set the planning type to Adherent to capacity. As a result, as much capacity as available in the period is used when loading in and the duration is extended for the task until the entire effort is loaded in.
  • A resource is loaded in with adherence to capacity, but many gaps remain in which nothing is loaded in. Here, remedial action is taken by entering the CAP load profile in Resource assignment to task. Enter CAP for all resource assignments of the task. This will achieve optimal utilisation of the resource. However, it should be noted that doing this may extend or shorten the prescribed task durations.

Overload with Planning with Adherence to Capacity and Different Load Profiles

FAQ - Question/Answer
  • A task loads in resources for different lengths and apparently overloads a resource unnecessarily.
Details
  • Planning with adherence to capacity
  • Planned duration = 10 days
  • Planned effort 100 hours
  • No requested dates
  • A resource with CAP load profile is loaded in without overload and for longer than 10 days.
  • A resource with a linear load profile (i.e. the load profile field is empty) is loaded in for the specified 10 days and is overloaded.
  • The following behavior is desired:
    • A resource with CAP is optimized and scheduled without overload.
    • A resource with linear load is also scheduled with overload in accordance with the Planned duration specifications.
Example
  • R1 is scheduled without overload from 11/25 - 12/12/08.
  • R8 is scheduled and overloaded for the specified duration of 10 days.
GR01502868-DE.png

Capacity Adjustment and Task Requested Dates

FAQ - Question/Answer
  • Tasks are moved by capacity adjustment, although task requested dates are set for successor tasks.
  • This is only the case when planning with adherence to capacity with Fix parameter = 0.
Examples
  • TA 100 is overloaded.
  • Planning with adherence to schedule: TA Requested start is considered. Overload of 42 hours is indicated.
GR01500478-DE.png
  • Planning with adherence to total float TA Requested start is considered as well.
GR01500478-DE.png
  • Planning with adherence to capacity: Capacity adjustment of TA 100 moves TA 200, although the latter has a TA Requested start. The deviation from TA Requested end of TA 100 is indicated as a date delay in the bar for TA 100.
GR01500479-DE.png
  • If a TA Requested start. is set for TA 200 with Fix parameter = 1, the requested date of TA 200 is adhered to. The deviation from TA Requested end of TA 100 is indicated as a date delay in the bar for TA 100.
GR01500480-DE.png

Unexpected Overload from Planning with Adherence to Capacity with CAP

FAQ - Question/Answer
  • In spite of using planning with adherence to capacity with CAP, overloads still appear.
  • The following points should be checked in this case.
    • When using planning with adherence to date and total float: All TA Requested start and TA Requested end are deleted. Otherwise, these tasks will be scheduled on an adherence to schedule.
    • Actual dates available? Tasks with a TA Actual start will be loaded in on a date-oriented basis (i.e. their remaining requirements). If appropriate, please work with Split = Y, so that the remaining resource requirement can be subject to capacity adjustment.
    • In the Resource Data Sheet, set Adjustment = Y for the respective resource.
    • Check the planning horizon. Ensure that resource periods have been set up for all the periods where capacity adjustment is to be applied. This is carried out in the Start period and End period fields in module 001343 Resource Data Sheet. There is no availability data and thus no adjustment for period for which period records are no longer available. But: do not make the planning horizon excessively long (e.g. 4 years). This costs unnecessary computation time, but usually does not yield any results of practical value.
    • Check the available capacity: Where appropriate, use Max. load/day in the resource assignment for a task to ensure that a 'mammoth task' does not tie up an employee's entire capacity for week after week, but only imposes a load of, say, 3 hours per day.
    • When planning with project structures: The project priorities must be set for subprojects in a way that causes them to be scheduled with adherence to capacity.
    • Sched. late for tasks to be calculated with adherence to capacity can deliver results in capacity scheduling which differ from those delivered by the Schedule early standard parameter and should therefore be avoided.

Task Requested Dates are Ignored

FAQ - Question/Answer
  • The tasks are not planned at the TA Requested start which is earlier than today’s date.
Details
  • The project has no Requested start.
  • The task has a Requested start that is before today’s date.
  • The task is scheduled from today’s date and before the TA Requested start.
  • Background: Scheduling starts the calculation from the PR Requested start and if this does not exist, as of the earliest realistic date, today’s date.
Example GR01502869-DE.png

Notes

  • Via the Fixing parameter = 1, the effect of the today line can be switched off, i.e. the task is scheduled for the task requested date in the past.

Planning of the Resource is far Beyond the Requested Dates

FAQ - Question/Answer
  • In planning with adherence to capacity, a resource with overload is planned far outside the requested dates.
Details
  • A special case for multi-calendar calculation with different non-working days for task and resource.
  • Parameters:
    • Planning with adherence to capacity
    • PR Requested start/Requested end is preset
    • TA Requested start / Requested end, and Planned duration are not preset.
    • A resource with a linear load profile is assigned to the task.
    • The normal company calendar has defined the period from Good Friday 04/10/09 up to and including Easter Monday 04/13/09 as non-working days.
    • The resource
      • has only defined the period from Mar. 26 up to and including March 28th, 2005 as non-working days.
      • is planned with a Planned duration of 10 h.
      • has not yet been scheduled for all of March.
Examples
  • There is no Planned duration preset for the task, therefore scheduling assumes one day as the value for the Planned duration and Remaining duration.
  • The resource is scheduled on two days outside the project requested dates on 04/10/09 and 04/14/09, as the task does not have any requested dates. In this case, the project requested date is used for information only.
  • Scheduling copies the working days of the company calendar for the calculation of the TA Remaining duration. This indicates only one working day for the period from Good Friday 04/10/09 up to and including 04/13/09.
  • The resource a preset Planned duration of 10 h. The work cannot be completed on one day with a specified daily availability of 7.2 hours. The resource is scheduled on the basis of the resource calendar and can work for two days in the aforementioned period from Good Friday from Good Friday 04/10/09 up to and including 04/13/09., while the company calendar-dependent task only indicates the duration of one day.
  • As a result, the
    • task duration one working day as per company calendar and
    • resource planning without overload restrictions are met.
  • This behavior is desired for the multi-calendar calculation. Different resources have different availabilities and are planned accordingly.
GR01502867-DE.png

Note

  • If this behavior is not desired, a requested date or sufficient Planned duration can be set for the task. In this case, date scheduling is based on this data when planning resources.

Capacity Adjustment and Maximum Links

FAQ - Question/Answer
  • When capacity adjustment is applied, it can happen that maximum links are ignored.
  • This is a topic which is currently the subject of research for the definition of results at universities.

Inexplicable Float when Planning with CAP

Problem
  • After capacity scheduling, a project has an inexplicable float.
Details
  • After date scheduling, the latest end dates of the tasks are after (later than) the requested end date of the project,
  • Capacity dates are earlier than the PR Requested end.
Cause
  • This problem only arises in planning with CAP load profile if date scheduling has already resulted in an overrun of the PR Requested end. The subsequent use of CAP planning can cause the TA durations, and hence the entire project, to be shortened to such an extent that it eventually becomes possible to meet the PR Requested end, on the basis of the capacity available.
  • If the Earliest start / Earliest end bar is made visible from the Invisible window and a time scheduling is carried out, this behavior becomes evident.
Notes
  • Capacity scheduling applies the earliest and latest dates from date scheduling as key dates for capacity adjustment. Capacity adjustment recalculates the durations, which may be shortened and may thus bring forward the times/dates, which can then result in buffers that are not immediately identifiable.
Example
  • For a TA Planned duration of 10 days and Planned effort = 16h (with CAP), date scheduling will start by assuming a 10 day throughput time. However, if it is possible to plan the 16 hrs into 2 days, the duration will be reduced by 8 days, and an additional buffer of 8 days would then be indicated.
Remedy
  • Instead of using TA durations and CAP, it is better to only use CAP with max. load. If, as in the above example, 16h are to be distributed over 10 days, it is more expedient to set Planned effort = 16 and max. load = 1,6 and Planned duration = 0.

FF Links and Capacity Adjustment

Problem
  • If in planning with adherence to capacity, 2 tasks are connected by an FF 0 link, they will be treated as FS 0, if
    • the successor task has a resource with the CAP load profile
    • the successor has a TA Planned duration = 0.
Cause
  • Movement of the successor due to capacity adjustment
  • The CAP load profile requires an initial duration for the adjustment. This duration is usually the TA Planned duration.
  • For an FF link, the following calculation is performed:
  • Capacity adjustment with CAP load profile now carries out the adjustment by working forwards from this ESD.
Work-around Notes
  • An FF link conflicts with planning with adherence to capacity, because a task which is loaded with adherence to capacity may be delayed or stretched out (CAP) up to the end of the planning horizon, and does not have to finish at the time implied by the FF link.
  • Under the conditions set out above, only an SS or SF link is meaningful; these result in the following calculation. E.g. SS:
  • Capacity adjustment starts from the Earliest start and moves or stretches the task to achieve a complete adjustment, regardless of the predecessor task’s end date.

Processing of Regular Projects/Basic Load Projects

FAQ - Question/Answer
  • How can I effect that
    • regular projects are processed in good time.
    • Basic load projects are treated subordinately.
Details
  • Initial situation:
    • The tasks of the projects are planned in good time with Planning early
    • Basic load projects
      • have a load from 01/01 to 12/31 of the respective year
      • the tasks are planned with Planning late with adherence to capacity
      • The resources have the CAP load profile
    • As a result, the resources at the end of the year are completely planned, and resources are not planned between today’s date and the end of the year.

Example

GR01504212-DE.png

  • It is desired that the basic load is loaded evenly and without overload instead of being loaded all at once at the end of the year.

Example

GR01504213-DE.png

Information

  • The CAP load profile in connection with the Planning with adherence to capacity planning strategy enables the load of the resources with respect to their capacities.
  • Here, PLANTA is oriented towards the available capacity of the resource.
  • The Linear load load profile loads the resources with the same number of hours per, however, it is not used for load adjustment. For this reason, it is not suitable for the Load without overload requirement.
Procedure
  • An option for solving the above mentioned requirement is the following:
    • The regular projects are planned as before.
    • The basic load project(s) is (are) planned with:
      • Planning early
      • Planning with adherence to capacity
      • Lower project priority than the regular projects in DI001015 PR Prio.
      • The tasks receive no Planned duration.
      • The resources receive a maximum load per day, e.g. 4 hours

GR01504214-DE.png

Example

GR01504215-DE.png

  • Due to the higher project priority of the regular projects are loaded first. The basic load project and its tasks are only loaded later.
    • Possibly, the resources will not be loaded at the end of the year.
    • If you move / extend the regular projects, the basic load project is also moved:

Example

GR01504216-DE.png

  • If there are still remaining capacities available after you have planned the regular projects, then they are used up to the defined maximum load per day by the basic load project.
  • Planning with adherence to capacity prevents overloads. The requested date of the basic load project is possibly overrun. As a result, the resource planning which is too high becomes visible and respective measures can be derived, e.g. to increase the maximum working time per day for the tasks of the basic load project or move tasks to the following year.

Example

GR01504217-DE.png

Moved Loadings

Problem
  • For the periods of a resource assignment, recorded hours are loaded at a wrong point in time.
Cause
  • The system calendar and the resources have different start periods. Recommendation: The system calendar starts earlier and ends later than the resource calendar. The system calendar should start no later than from the date of the first posting.
  • It has occasionally happened that an incorrect loading-in date was determined due to the deviating number of resource and calendar working periods.
Work-around
  • If this problem arises, correct loading in can be achieved by setting the same date for start periods of the system calendar and of the resources.

Negative Load in the Utilization Diagram

Details
  • In utilization modules, the utilization diagram starts below the zero line for individual resources.
  • If the Summarize periods resource parameter = Y, the negative utilization of the resource or a child resource is retained, even though load records with a negative actual load were deleted.
Example

GR01502171-DE.png

Cause

  • Software
Procedure/Workaround
  • Open the required resource in the Resource Data Sheet module.
  • Change parameter Summarize periods to N
  • Save.
  • Change parameter Summarize periods to Y
  • Save.
  • Carry out a replanning.
  • Close PPMS and then open it again:

Behavior of TA Update Report Date After Deletion of TA Actual ED

Details
  • If an Actual end is removed, scheduling initializes the date for update reporting and then recalculates it.
  • The date for work reporting is determined from the maximum from Actual start and the last work reportings of the resource assignments.
Example
  • Initial situation
GR01501988-DE.png

GR01501989-DE.png

  • If the TA Actual end is emptied, scheduling has the following results:
    • The date for update reporting is deleted and the task is given a remaining duration of 7 days according to the actual duration.

GR01501991-DE.png

Planning of TA Calc. SD by milestones

Details
  • Successor tasks start on the day of the Predecessor calc ED if:

GR01502028-DE.png

  • Successor tasks start on the day of the _Predecessor calc ED + 1 if the following applies to the successor task:
    • Duration = 0
    • TA Requested end is set.
    • Link time interval = 0
    • or
    • Duration > 0
    • Link time interval = 0

GR01502029-DE.png

Incorrect Calculation of the Level Field

Problem
  • Different calculation of the Level field.
Details
  • If project structures are manipulated in a module, and if then a scheduling run is performed in this module, the levels may not be calculated in the correct sequence.
Cause
  • As part of the scheduling procedures, the software always carries out a sort by level and PR Requested end. As neither a level nor a PR Requested end exists is available for the subprojects, the projects are potentially not sorted and calculated individually in the usual sequence at first. This leads to the determination of a different level.
Work-around
  • After the 2nd scheduling run and each subsequent one, the levels will be calculated correctly.
  • If the calculations are done in a module which only performs them for the main project, e.g. the project data sheet module, the levels will be determined correctly as well.
  • In the case of complete replanning, the levels will also be determined correctly.
Note
  • This behavior can lead to different analyses, if report details are selected or sorted using the Level field.

Sched. Early = N Has no Effect on Tasks with Subprojects

Problem Cause
  • In the case of tasks with subprojects, the duration and position of the task is defined by the subproject. If, for example, a task has a TA Requested start in the subproject, then this TA Requested start should be adhered to. However, this contradicts to the idea < with the intention of Planning early = N in the parent task. Consequently, a parent task will always be planned with Planning early = Y.
Work-around
  • Each task can be forced into the late position by having a predecessor for which Planning early = N is set. To do so, you can e.g. create a milestone task with Planned duration = 0, Planning early = N and a link: FS time interval = 0 to the task which is to be planned late.
  • The same effect can be achieved by setting Planning early = N for all the tasks in the subproject which have no predecessors.
Notes
  • Once a subproject has been started (i.e. there is an entry for its PR Actual start), the effect of Planning early = N can again be forced by splitting the task.
  • Requested dates for a task in the subproject will again disrupt any attempt to move the project to the latest possible dates.

Set Project Status 9 for Archiving

Objective
  • Optimum representation of costs and effort when projects or subprojects receive PR status 9 Projects to be archived.
Notes
  • All dependent projects and subprojects are to be set to status 9 at a particular point in time.
  • If this is not possible, only projects that do not have any active subprojects are to be set to status 9.
  • It is advisable to first calculate the whole project before setting it or its subprojects to status 9 after unloading. This updates the cost and effort data to the current situation.

Topic attachments
I Attachment History Size Date Comment
Jpgjpg C01500373-DE-00030.jpg r1 54.7 K 2014-08-28 - 09:31  
Pngpng GPT_CAP1.png r1 74.6 K 2019-12-18 - 09:45  
Pngpng GPT_CAP2.png r1 85.8 K 2019-12-18 - 09:46  
Pngpng GPT_CAP3.png r1 90.2 K 2019-12-18 - 09:46  
Pngpng GPT_CAP4.png r1 77.1 K 2019-12-18 - 09:46  
Pngpng GR0110S4-DE.png r1 17.0 K 2014-08-28 - 13:28  
Pngpng GR0110S5-DE.png r1 8.4 K 2014-08-28 - 13:28  
Pngpng GR0110S6-DE.png r1 8.3 K 2014-08-28 - 13:29  
Pngpng GR0110S7-DE.png r1 8.5 K 2014-08-28 - 13:29  
Pngpng GR0110S8-DE.png r1 36.5 K 2014-08-28 - 13:29  
Pngpng GR0110SA-DE.png r1 8.4 K 2014-08-28 - 13:30  
Pngpng GR0110SC-DE.png r1 10.2 K 2014-08-28 - 13:31  
Pngpng GR0110SD-DE.png r1 9.9 K 2014-08-28 - 13:31  
Pngpng GR0110SE-DE.png r1 11.9 K 2014-08-28 - 13:32  
Pngpng GR0110SF-DE.png r1 10.0 K 2014-08-28 - 13:33  
Pngpng GR0110SG-DE.png r1 11.6 K 2014-08-28 - 13:33  
Pngpng GR0110SH-DE.png r1 9.7 K 2014-08-28 - 13:33  
Pngpng GR0110SJ-DE.png r1 12.7 K 2014-08-28 - 13:35  
Pngpng GR0110SK-DE.png r1 6.4 K 2014-08-29 - 09:59  
Pngpng GR0110ST-DE.png r1 12.0 K 2014-08-28 - 13:37  
Pngpng GR0110SU-DE.png r1 12.1 K 2014-08-28 - 13:38  
Pngpng GR0110SY-DE.png r1 8.3 K 2014-08-29 - 10:33  
Pngpng GR0110SZ-DE.png r1 8.0 K 2014-08-29 - 10:33  
Pngpng GR0110T0-DE.png r1 9.1 K 2014-08-21 - 13:43  
Pngpng GR0110T1-DE.png r1 10.0 K 2014-08-29 - 10:44  
Pngpng GR0110T2-DE.png r1 4.2 K 2014-08-29 - 10:45  
Pngpng GR0110T5-DE.png r1 18.5 K 2014-08-28 - 13:40  
Pngpng GR0110TK-DE.png r1 2.4 K 2014-08-21 - 12:00  
Pngpng GR0110TL-DE.png r1 3.9 K 2014-08-21 - 12:14  
Pngpng GR0110TM-DE.png r1 12.4 K 2014-08-28 - 13:26  
Pngpng GR0110TN-DE.png r1 7.8 K 2014-08-28 - 13:27  
Pngpng GR0110TO-DE.png r1 6.8 K 2014-08-21 - 13:44  
Pngpng GR0110TQ-DE.png r1 16.1 K 2014-08-21 - 13:44  
Pngpng GR0110U2-DE.png r1 1.7 K 2014-08-26 - 12:07  
Pngpng GR0110U3-DE.png r1 1.9 K 2014-08-26 - 12:09  
Pngpng GR0110U4-DE.png r1 2.1 K 2014-08-26 - 12:10  
Pngpng GR0110U5-DE.png r1 8.8 K 2014-08-26 - 12:11  
Pngpng GR0110U6-DE.png r1 5.6 K 2014-08-26 - 12:11  
Pngpng GR0110U7-DE.png r1 22.6 K 2014-08-26 - 12:12  
Pngpng GR0110U9-DE.png r1 15.6 K 2014-08-26 - 12:25  
Pngpng GR0110UA-DE.png r1 12.3 K 2014-08-26 - 12:26  
Pngpng GR0110UB-DE.png r1 95.7 K 2014-08-26 - 12:38  
Pngpng GR0110UC-DE.png r1 10.6 K 2014-08-26 - 12:39  
Pngpng GR0110UD-DE.png r1 100.8 K 2014-08-26 - 13:07  
Pngpng GR0110UE-DE.png r1 10.0 K 2014-08-26 - 13:08  
Pngpng GR0110UK-DE.png r1 7.4 K 2014-08-27 - 09:23  
Pngpng GR0110UL-DE.png r1 15.0 K 2014-08-27 - 09:23  
Pngpng GR0110UM-DE.png r1 79.2 K 2014-08-27 - 09:33  
Pngpng GR0110UN-DE.png r1 12.5 K 2014-08-27 - 09:34  
Pngpng GR0110UQ-DE.png r1 12.0 K 2014-08-27 - 11:48  
Pngpng GR0110UT-DE.png r1 12.6 K 2014-08-27 - 11:51  
Pngpng GR0110UV-DE.png r1 16.7 K 2014-08-27 - 11:52  
Pngpng GR0110UW-DE.png r1 13.2 K 2014-08-27 - 12:37  
Pngpng GR0110UX-DE.png r1 14.1 K 2014-08-27 - 12:38  
Pngpng GR0110UY-DE.png r1 15.8 K 2014-08-27 - 12:59  
Pngpng GR0110UZ-DE.png r1 9.0 K 2014-08-28 - 08:43  
Pngpng GR0110V0-DE.png r1 10.5 K 2014-08-28 - 08:43  
Pngpng GR0110V1-DE.png r1 12.0 K 2014-08-28 - 09:30  
Pngpng GR0110V2-DE.png r1 16.2 K 2014-08-28 - 10:29  
Pngpng GR0110V3-DE.png r1 10.6 K 2014-08-28 - 10:30  
Pngpng GR0110V5-DE.png r1 5.7 K 2014-08-28 - 10:30  
Pngpng GR0110V9-DE.png r1 7.0 K 2014-08-28 - 13:14  
Pngpng GR0110VA-DE.png r1 12.0 K 2014-08-28 - 13:14  
Pngpng GR0110VB-DE.png r1 12.1 K 2014-08-28 - 13:15  
Pngpng GR0110VH-DE.png r1 19.1 K 2014-08-28 - 13:24  
Pngpng GR01500473-DE.png r1 15.0 K 2014-08-28 - 13:16  
Pngpng GR01500478-DE.png r1 6.2 K 2014-08-20 - 19:21  
Pngpng GR01500479-DE.png r1 6.4 K 2014-08-20 - 19:22  
Pngpng GR01500480-DE.png r1 6.4 K 2014-08-20 - 19:21  
Pngpng GR01500481-DE.png r1 3.9 K 2014-08-21 - 12:01  
Pngpng GR01500489-DE.png r1 10.9 K 2014-08-26 - 12:12  
Pngpng GR01500490-DE.png r1 95.6 K 2014-08-26 - 13:07  
Pngpng GR01500491-DE.png r1 10.1 K 2014-08-26 - 13:47  
Pngpng GR01500492-DE.png r1 13.6 K 2014-08-26 - 13:50  
Pngpng GR01500493-DE.png r1 11.4 K 2014-08-27 - 09:25  
Pngpng GR01500494-DE.png r1 21.8 K 2014-08-27 - 09:25  
Pngpng GR01500495-DE.png r1 17.1 K 2014-08-28 - 10:31  
Pngpng GR01500820-DE.png r1 8.8 K 2014-08-27 - 09:24  
Pngpng GR01501232-DE.png r1 9.5 K 2014-08-29 - 10:36  
Pngpng GR01501233-DE.png r1 8.3 K 2014-08-29 - 10:37  
Pngpng GR01501234-DE.png r1 12.3 K 2014-08-29 - 10:39  
Pngpng GR01501235-DE.png r1 12.7 K 2014-08-29 - 10:39  
Pngpng GR01501236-DE.png r1 10.1 K 2014-08-29 - 10:40  
Pngpng GR01501988-DE.png r1 11.5 K 2014-08-21 - 11:33  
Pngpng GR01501989-DE.png r1 11.5 K 2014-08-21 - 11:32  
Pngpng GR01501991-DE.png r1 11.4 K 2014-08-21 - 11:33  
Pngpng GR01502028-DE.png r1 11.9 K 2014-08-21 - 11:49  
Pngpng GR01502029-DE.png r1 10.9 K 2014-08-21 - 11:49  
Pngpng GR01502099-DE.png r1 9.4 K 2014-08-27 - 11:14  
Pngpng GR01502139-DE.png r1 13.1 K 2014-08-21 - 11:42  
Pngpng GR01502140-DE.png r1 13.0 K 2014-08-21 - 11:43  
Pngpng GR01502171-DE.png r1 2.2 K 2014-08-21 - 11:27  
Pngpng GR01502249-DE.png r1 6.7 K 2014-08-26 - 12:25  
Pngpng GR01502263-DE.png r1 67.2 K 2014-08-27 - 09:22  
Pngpng GR01502288-DE.png r1 18.4 K 2014-08-25 - 12:32  
Pngpng GR01502289-DE.png r1 7.0 K 2014-08-25 - 12:32  
Pngpng GR01502290-DE.png r1 19.1 K 2014-08-25 - 13:55  
Pngpng GR01502291-DE.png r1 19.8 K 2014-08-25 - 13:56  
Pngpng GR01502292-DE.png r1 12.6 K 2014-08-25 - 14:13  
Pngpng GR01502293-DE.png r1 12.7 K 2014-08-25 - 14:16  
Pngpng GR01502294-DE.png r1 12.7 K 2014-08-25 - 14:17  
Pngpng GR01502295-DE.png r1 14.9 K 2014-08-25 - 15:05  
Pngpng GR01502296-DE.png r1 15.0 K 2014-08-25 - 15:06  
Pngpng GR01502297-DE.png r1 9.4 K 2014-08-26 - 09:09  
Pngpng GR01502298-DE.png r1 9.7 K 2014-08-26 - 09:10  
Pngpng GR01502299-DE.png r1 10.1 K 2014-08-26 - 09:11  
Pngpng GR01502300-DE.png r1 10.0 K 2014-08-26 - 09:14  
Pngpng GR01502301-DE.png r1 10.0 K 2014-08-26 - 09:15  
Pngpng GR01502302-DE.png r1 15.7 K 2014-08-26 - 09:35  
Pngpng GR01502303-DE.png r1 12.8 K 2014-08-26 - 09:37  
Pngpng GR01502304-DE.png r1 13.8 K 2014-08-26 - 09:37  
Pngpng GR01502308-DE.png r1 12.5 K 2014-08-29 - 09:51  
Pngpng GR01502309-DE.png r1 12.7 K 2014-08-29 - 09:52  
Pngpng GR01502310-DE.png r1 12.8 K 2014-08-29 - 09:52  
Pngpng GR01502311-DE.png r1 12.8 K 2014-08-29 - 09:52  
Pngpng GR01502312-DE.png r1 12.8 K 2014-08-29 - 09:53  
Pngpng GR01502377-DE.png r1 3.6 K 2014-08-21 - 12:06  
Pngpng GR01502378-DE.png r1 4.0 K 2014-08-21 - 12:07  
Pngpng GR01502508-DE.png r1 10.8 K 2014-08-29 - 09:47  
Pngpng GR01502509-DE.png r1 11.9 K 2014-08-29 - 09:46  
Pngpng GR01502510-DE.png r1 11.4 K 2014-08-29 - 10:46  
Pngpng GR01502518-DE.png r1 9.1 K 2014-08-27 - 11:50  
Pngpng GR01502519-DE.png r1 9.4 K 2014-08-27 - 11:50  
Pngpng GR01502712-DE.png r1 12.0 K 2014-08-29 - 10:34  
Pngpng GR01502713-DE.png r1 11.8 K 2014-08-29 - 10:34  
Pngpng GR01502920-DE.png r1 14.3 K 2014-08-29 - 10:40  
Pngpng GR01502950-DE.png r1 11.0 K 2014-08-29 - 09:47  
Pngpng GR01502953-DE.png r1 12.0 K 2014-08-29 - 10:35  
Pngpng GR01502964-DE.png r1 17.6 K 2014-08-28 - 13:35  
Pngpng GR01502965-DE.png r1 9.4 K 2014-08-25 - 11:59  
Pngpng GR01502966-DE.png r1 9.3 K 2014-08-25 - 12:00  
Pngpng GR01503448-DE.png r1 89.4 K 2014-08-28 - 13:16  
Pngpng GR01503559-DE.png r1 10.4 K 2014-08-29 - 10:00  
Pngpng GR01503560-DE.png r1 17.1 K 2014-08-29 - 10:00  
Pngpng GR01503578-DE.png r1 2.7 K 2014-08-25 - 09:13  
Pngpng GR01503758-DE.png r1 10.2 K 2014-08-25 - 09:15  
Pngpng GR01503759-DE.png r1 14.9 K 2014-08-25 - 09:34  
Pngpng GR01503760-DE.png r1 10.2 K 2014-08-25 - 09:34  
Pngpng GR01504212-DE.png r1 1.9 K 2014-08-21 - 10:23  
Pngpng GR01504213-DE.png r1 1.5 K 2014-08-21 - 10:24  
Pngpng GR01504214-DE.png r1 5.2 K 2014-08-21 - 10:35  
Pngpng GR01504215-DE.png r1 1.4 K 2014-08-21 - 10:36  
Pngpng GR01504216-DE.png r1 1.6 K 2014-08-21 - 10:36  
Pngpng GR01504217-DE.png r1 1.6 K 2014-08-21 - 10:37  
Pngpng GR01504250-DE.png r1 7.9 K 2014-08-29 - 09:39  
Pngpng GR01504330-DE.png r1 14.7 K 2014-08-29 - 10:31  
Pngpng GR01504438-DE.png r1 14.8 K 2014-08-25 - 12:46  
Pngpng GR01504439-DE.png r1 14.8 K 2014-08-25 - 12:47  
Pngpng GR01504444-DE.png r1 7.3 K 2014-08-29 - 09:49  
Pngpng GR01504640-DE.png r1 11.7 K 2014-08-28 - 13:17  
Pngpng GR01504641-DE.png r1 32.7 K 2014-08-28 - 13:18  
Pngpng GR01504642-DE.png r1 33.4 K 2014-08-28 - 13:18  
Pngpng GR01504643-DE.png r1 34.6 K 2014-08-28 - 13:19  
Pngpng GR01504644-DE.png r1 34.5 K 2014-08-28 - 13:19  
Pngpng GR01504645-DE.png r1 34.9 K 2014-08-28 - 13:20  
Pngpng GR01504646-DE.png r1 34.6 K 2014-08-28 - 13:20  
Pngpng GR01504709-DE.png r1 13.9 K 2014-08-27 - 11:49  
Pngpng KT_CAP1.png r2 r1 66.0 K 2019-12-19 - 13:12  
Pngpng KT_CAP2.png r2 r1 75.7 K 2019-12-19 - 13:12  
Pngpng MAN1.png r1 59.2 K 2019-12-19 - 13:43  
Pngpng MAN2.png r1 59.6 K 2019-12-19 - 13:43  
Pngpng MAN3.png r1 63.6 K 2019-12-19 - 15:09  
Pngpng MAN4.png r1 63.8 K 2019-12-19 - 15:10  
Pngpng MAN5.png r1 51.2 K 2019-12-20 - 12:32  
Pngpng TT_CAP1.png r1 69.1 K 2019-12-18 - 09:09  
Pngpng TT_CAP2.png r1 71.2 K 2019-12-18 - 09:10  
Pngpng TT_CAP3.png r1 46.7 K 2019-12-18 - 09:10  

         PLANTA project









 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl