Below, you will find descriptions of individual task parameters (task data fields).
DI001098 Task ID
Technical ID of the task. It is generated automatically upon creation of the task and cannot be changed afterwards. This ID is usually not visible in modules, but it can be accessed by users with customizing rights if necessary.
DI060043 Task (functional)
Functional identification number of the task
DI041467 Task
Field in which the task ID is displayed. Here, either the task WBS codes or the functional task ID will be displayed depending on the settings of the Show WBS code instead of ID parameter.
The functional ID in the Task field is generated automatically (copied from the technical Task ID), if you enter the name of the task in the Task name field and click outside the field. The functional ID cannot be changed manually afterwards.
For newly created tasks, the WBS code is only displayed if it has been generated explicitly (depending on the version either by selecting the respective context menu command or by clicking on the Generate WBS code button in the project header line.
either generated automatically (copied from the Task ID), when you enter a task name in the Task name field and click outside the field. The functional ID can be changed manually afterwards.
or initially allocated manually.
Since the field is an output field by default, it must be changed to input field via customizing in order to be able to manually edit it. This must be redone after every database update.
Initially planned effort of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Planned effort = sum of the Planned effort of all tasks of the respective subproject.
Note
Planned effort is only summarized from the Resource assignment (DT466) to the Task (DT463) if the Effort summarization checkbox is activated in the Resource Data Sheet.
DI001135 Actual effort
Actual effort of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Actual effort = sum of the Actual effort of all tasks of the respective subproject.
Note
Actual effort is only summarized from the Resource assignment (DT466) to the Task (DT463) if the Effort summarization checkbox is activated in the Resource Data Sheet.
DI001136 Remaining effort
Remaining effort of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Remaining effort = sum of the Remaining effort of all tasks of the respective subproject.
Note
Remaining effort is only summarized from the Resource assignment (DT466) to the Task (DT463) if the Effort summarization checkbox is activated in the Resource Data Sheet.
DI000785 Total effort
Total effort of the task. The value is determined in scheduling as a sum of actual and remaining (manual input not possible).
Initially planned costs of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Calculation/summarization
Task:Planned costs = sum of Planned costs of all resources assigned to the task (except revenue resources).
Resource assignment:Planned costs = sum of all Planned cost values per day of the resource assigned to the task.
Load: Planned costsper day of the resource assigned to the task. On this level, the actual cost calculation takes place.
Planned costs = sum of the Planned costs of all tasks of the respective subproject.
DI000697 Actual costs
Actual costs of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Structure of the determination of values by areas (levels) from top to bottom:
Task:Actual costs = sum of Actual costs of all resources assigned to the task (except revenue resources).
Resource assignment:Actual costs = sum of all Actual cost values of all resources assigned to the task.
Load:Actual costs per day of the resource assigned to the task. On this level, the actual cost calculation takes place.
Actual costs = sum of the Actual costs of all tasks of the respective subproject.
DI000698 Remaining costs
Remaining costs of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Total costs from the active (last released) status report
DI059703 Total effort (active SR)
Total effort from the active (last released) status report
DI001096 Project ID/ID461
Technical ID of the project. The ID is automatically read out from the corresponding project.
DI001097 Project ID
Technical ID of the project. The ID is automatically read out from the corresponding project.
DI001110 Priority
This parameter serves to define the task priority manually Controls, along with other parameters, the sequence in which tasks are loaded within a project.
Details
The load sequence of tasks which are parallel in the network and which are not linked via Links is established in accordance with their priority.
If parent and child tasks have the same priority in a structured schedule, the parent task receives the higher priority due to the task’s higher rank.
Example
Summary task A (Priority 2)
Task A.1 (Priority 1)
Task A.2 (Priority 3)
Summary task B (Priority 1)
Task B.1 (Priority 2)
Task B.2 (Priority 4)
The loading sequence for this example is as follows: B, A, A1, B1, A2, B2.
Values
0 or empty: highest priority
1: second highest priority, etc.
The parameter can be edited in the following modules by users with modification rights:
The parameter defines whether the calculated dates result from the earliest or latest calculated dates. Earliest and latest dates only differ if the respective task has a float.
In order to be able to use the Planning early = (deactivated) parameter anyway, you have to enter a requested end date of the project or requested end dates on the respective tasks, so that there is a starting point for backward scheduling.
A task with deactivated Planning early checkbox is planned at the latest dates (TA Latest start/TA Latest end). As a result it will be shown as critical (TA Total float = 0). It is, however, only on the critical path if at least one link leads into it which has Link total float = 0 (red line).
Planning early parameter has no effect on a summary task. The summary tasks receive their dates from the child tasks. On child tasks, the Planning early parameter has the same effect as on unstructured tasks. If the child tasks have both Planning early = as well as Planning early = , the Calculated start receives the Earliest start of all child tasks from the summary task and the Calculated end receives the Latest end of all child tasks from the summary task.
Successors of tasks with deactivated Planning early checkbox are also moved. See the figure.
Example
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the Entire Schedule module variant (can be displayed in further module variants)
The respective data field is hidden by default and can be unhidden by the user if necessary.
Task in the parameters relevant for scheduling area
Typical application in practice
Certain tasks should be planned as late as possible since they tie up a lot of capital, e.g. purchase, production. Other tasks should be planned as early as possible since adherence to schedule is uncertain, e.g. construction. By proceeding like this, construction has a certain float.
DI001114 Requested end
For tasks
Requested end date of the task. For description and details, see Requested start
For quality gates
Requested end date of the quality gate. Is defined by the portfolio manager.
Details
In the Quality Gates module, a traffic light is stored on the field which behaves as follows:
As long as the quality gate is not completed by 100%, the traffic light is
Requested start date of the task. Task requested dates determine the start and end of the task unless other restrictions prevent this (e.g. links).
Details
Requested dates (Requested start/end) are taken into account during scheduling depending on the settings of the Task requested dates model parameter. They are only adhered to if the structure of the network (i.e. the dates for the predecessors) permits it.
Task requested dates prevent capacity adjustment for the respective task if Req. start and/or Req. end have been entered on the task.
They take priority over the Planning early parameter, which means that the task is loaded with adherence to schedule and total float. In the case of planning with adherence to capacity with load profile CAP, the task may be extended if there is an overload.
In the PLANTA standard, the requested dates of the tasks are visualized by blue triangles.
Note
You can prevent task requested dates from being shifted by using the Fix parameter.
Midpoint scheduling is an example for the use of requested dates on tasks
It means the planning of a project around a central date (midpoint scheduling).
For this purpose, set a task requested date for the task which marks the central date and schedule the tasks which lie before it for the latest possible date and schedule those which come after it for the earliest possible date.
The parameter can be edited in the following modules by users with modification rights:
Calculated start date of the task. The value is determined during scheduling by taking into account different planning factors, e.g. whether a task is to start on its earliest or latest calculated date, whether there is a requested start date or a predecessor which determines the start date, etc.
DI001120 Calc. end
Calculated end date of the task. The value is determined during Scheduling by taking different planning factors into account.
DI001121 Actual start
Actual start date of the task. Task actual dates dominate links, task requested dates, and the Planning early parameter.
Details
For regular tasks:
can be set manually
In scheduling of the project, the start date of the task is then automatically copied to all resource assignments which have no actual end date yet.
or it is copied from Actual start of the resource assignment in scheduling of the project, provided that they have an actual start. Otherwise it will be left empty.
If there are several resource assignments with different Actual start, the earliest Actual start will be applied to the task. For the actual end, the opposite is true: the latest Actual end of the resource assignment will be applied to the task.
Tasks with an Actual start or an Actual end behave during scheduling as in calculation with adherence to schedule, i.e. no capacity adjustment takes place. If the remainder of the task is to be adjusted anyway, it must be split with the help of the Split parameter.
Correlation of actual dates and links
Tasks with an Actual start are treated as if they had no predecessors since they can no longer be shifted by their predecessors. This is necessary to ensure that the predecessors can still be planned if the link condition is not satisfied.
If a successor in an ES link has already started (Actual start is set), without its predecessor having started yet, the predecessor has total float up to the project end after the calculation of the schedule.
A task which has been started even though it possesses a predecessor which has not been started, usually indicates an actual break in the link. In practice, such breaks occur time and again (for example, design work is started even though the customer's approval has not yet been obtained).
PLANTA is stable against such infringement of link conditions, i.e. the links which have become meaningless are ignored during the calculation of the schedule. In the situation where a task has no other links (constraining it in the forward direction) this may lead to the due-date for the task being the end of the project. This is indeed equivalent to the loss of the successor which defines the due-date, and with it the link. If this is not desired, you have the following options:
By defining an additional FF link between these two tasks, the buffer time of the predecessor can be influenced.
Activate the Planning early checkbox. The resource-scheduled dates will then be correct, but not the buffer times.
Additional links to the successor of the direct successor "for safety purposes". Simple when standard network plans are used, but otherwise may involve high updating effort.
Only introduce a new link if you note that the task is kept 'hanging'. Disadvantage: If you overlook this, the plan data will be incorrect.
Use of FF conditions, where the assumption is made that the predecessor will start "soon".
Tasks with an Actual start or an Actual end behave during scheduling as in calculation with adherence to schedule, i.e. no capacity adjustment takes place. If the remainder of the task is to be adjusted anyway, it must be split with the help of the Split parameter.
Notes on Actual end
If there is an Actual end, the Remaining duration = 0, i.e., if there still is remaining duration when the actual end is set, it will be set to zero (deleted).
Tasks with set Actual end are not considered in some user modules (e.g. My Activities) and are not displayed.
For quality gates
Date of approval of the quality gate by the portfolio manager. From here on, the quality is considered completed. The date is automatically set as soon as the portfolio manager has activated the Approval checkbox on the quality gate.
The parameter can be edited in the following modules by users with modification rights:
Earliest start date of the project. The value is determined during scheduling by taking into account different planning factors and immediately becomes the calculated start of the task if you have selected the Planning early = parameter.
Earliest start date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any). Taking soft links into account may lead to a deviation to the Earliest start date of the task.
DI009344 Earliest end soft
Earliest end date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any). Taking soft links into account may lead to a deviation to the Earliest end date of the task.
DI009345 Latest start soft
Latest start date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any) Taking soft links into account may lead to a deviation from the Latest start date of the task.
DI009346 Latest end soft
Latest end date of the task which is determined in scheduling and in which the soft links of the task are taken into account (if there are any) Taking soft links into account may lead to a deviation to the Latest end date of the task.
DI009351 Overlapping start
Date on which the task overlapping starts. A task overlapping can occur if a task has a soft link. For this purpose, see Soft link.
DI009352 Overlapping end
Date on which the task overlapping ends. A task overlapping can occur if a task has a soft link. For this purpose, see Soft link.
DI009353 Days, overlapping
Duration of the task overlapping in days. A task overlapping can occur if a task has a soft link. For this purpose, see Soft link.
DI001123 Structure start
Start date of the subproject
Calculation
Structure start of the task = Calc. start of the subproject
DI001124 Structure end
Structure end date of the subproject
Calculation
Structure end of the task = Calc. end of the subproject
DI001131 Planned duration
Initially planned duration of the task in days. Normally, this field is filled automatically if a value is entered in Remaining duration.
sum of the Actual duration of all tasks of the respective subproject
DI001133 Remaining duration
Remaining duration of the task in days. The duration can either be specified by the user or it is determined during scheduling on the basis of the other parameters. As long as no actual start date has been set, the planned duration which is automatically copied to the Planned duration field is entered here.
Details
If a TA duration has been entered (or calculated via TA Req. start + Req. end), this duration has the highest priority.
the planned duration is entered manually in the Remaining duration field
or it is calculated
from the requested dates of the tasks
if the task is defined as a hammock task
Calculation overwrites manual input. I.e. requested dates or hammock task (without requested dates) have priority, i.e. they overwrite manual input.
from the duration of the resource assignments (calculated from MAN, CAP with max. load or the requested dates of the resource assignment). If there are several resource assignments, the Remaining duration of a task is calculated from the maximum of the duration of the resource assignments.
If there is a remaining duration on the task (entered manually or determined in scheduling) and if there is also a remaining duration on the resource assignment which results from the requested dates and deviates from the task duration, the task duration will be overwritten.
If there is a remaining duration on the task (entered manually or determined in scheduling) and if there also is a remaining duration on the resource assignment which is not determined from the requested dates and deviates from the task duration, the highest of both values is used for the task, regardless of whether it has been entered or calculated.
This only applies if no requested dates are entered on the task itself. Requested dates of the task always overwrite the requested dates of the resource assignments.
the Remaining duration is calculated in scheduling as follows:
Remaining duration = initial Remaining duration - change in Actual duration
the automatically calculated value, however, can be adjusted manually if necessary (e.g. if the duration is determined from the prognoses). Manual entries will not be overwritten during calculation of the schedule, provided that no requested dates exist which may account for a deviating duration.
total Remaining duration of all tasks of the respective subproject.
Essential impact:
Planning with adherence to schedule
CAP does not shorten and extend the task duration, but the capacity adjustment within the task duration still takes place.
When working with MAN, it is recommended not to work with manually entered durations but to calculate the duration based on the resource assignment or to predefine requested dates on the task.
Requested dates on the resource assignment will only be taken into account within the task duration. In case task duration = 0, they will only be taken into account within the calc. start and latest end of the task. Logic: Resources can only be planned within the TA duration.
Planning with adherence to total float
CAP can prolong the task duration up to the latest end of the task.
Planning with adherence to capacity
As hitherto, CAP can extend the task duration up to the planning horizon of the resource.
Percentage share of the actual effort (Actual effort) of the task with respect to the total effort (Actual effort + Remaining effort). The value is determined during scheduling.
If the schedule calculation stops due to a network cycle, this parameter will be activated for every task involved in the cycle (). After the cycle has been removed, this field will be deactivated again in the next calculation of the schedule ().
DI001149 Task release
This field is set automatically during scheduling (cf. the Task release model parameter) or it can be set manually.
The parameter can be edited in the following modules by users with modification rights:
The respective data field is hidden by default and can be unhidden by the user if necessary.
DI001177 Deviation: req. end - calc. end end
Task requested date deviation from calculated end date
DI001488 Hammock task
Parameter which allows to "span" the task across the entire duration of the project. This is used, e.g., for recurring, project related activities (basic load).
Information
If a task is defined as a hammock task, the Planned duration and Remaining duration of the task are determined depending on project start and project end.
If the requested end date is in the past, the calculated end date of the hammock task is today (if there is a link to the summary task, the calculated end date is tomorrow).
If the actual start date is not set, the duration calculated initially is retained and the hammock task is completely moved forward, causing a delay.
If the actual start has been set, the duration is reduced in accordance with the date progression.
The respective data field is hidden by default and can be unhidden by the user if necessary.
Task in the parameters relevant for scheduling area
DI002001 Bar: requested dates
Bar for the visualization of the time interval between the requested dates (Requested start and Requested end) of the task
DI002002 Bar: earliest dates
Bar for the visualization of the time interval between the requested dates (Earliest start and Earliest end) of the task
DI002003 Bar: latest dates
Bar for the visualization of the time interval between the requested dates (Latest start and Latest end) of the task
DI002005 Bar: actual dates
Bar for the visualization of the interval between the actual dates (Actual start and Actual end) of the task
DI002086 Bar: actual start - work reporting date
Bar for the visualization of the interval between the actual start date and the latest work reporting date of the task
DI061285 Bar: MMS big
Bars (rhomb symbol) for the visualization of the master milestones (gates) in the schedule on the horizontal axis below the scale
Details
The number on the bar represents the time interval (in weeks) to the master milestone or, if no milestone is defined as a master milestone, the time interval to the Calc. end of the project.
The number above the bar is the WBS code of the master milestone.
DI061313 Difference from main milestone date
Time interval to the main milestone or, if no milestone is defined as a master milestone, the time interval to the Calc. end of the project in weeks
DI002346 Number of task-resources
Number of the resources assigned to the current task
DI002379 Number of links
Number of links to successors of the task, i.e. all links coming from the task. Here, all link types are counted: internal links, external links, and also external tasks.
Code which indicates whether the task is a parent task that is linked to a subproject
Details
Usage: as a selection and sorting criterion in special modules, for suppressing/showing the display of higher level (parent) tasks.
DI002621 Project name
Name of the project. Is automatically copied from the corresponding project.
DI002859 Phase
DI002951 Bar: calculated dates
Bar for calculated dates (Calc. start and Calc. end) of the task
DI003681 Duration from requested dates
Duration calculated from the task requested dates
DI006527 Bar: Milestone
Bar for milestones
DI006786 Milestone ID
Code (ID) for the Milestone parameter. For description, see Milestone: text. In standard, the parameter can be found in window 2 of the Schedule module.
DI059007 Milestone
This parameter serves to define whether the task is a regular task, a milestone, a master milestone, or a quality gate.
Values
Empty: No milestone
1: Milestone
2: master milestone
3: Quality gate: This value cannot be selected manually for tasks in the Schedule module, but it is automatically set for tasks which are defined as quality gates in the portfolio.
Information
Milestones and master milestones have the same function.
Master milestones are events with special significance. They differ from the milestones in significance, i.e. they are, even more important for reaching a project goal.
Notes
From a technical point of view, milestones and master milestones are treated during scheduling like regular tasks, i.e. they can also have a duration > 0. However, PLANTA recommends that you use milestones and master milestones as event points with a duration of 0 or 1 since this is the common procedure in practice and PLANTA has optimized modules and symbol layouts for the use of this planning model.
If you want to plan milestones/master milestones with a duration = 0, you have to comply with some requirements:
General rule in PLANTA project: If tasks are connected with links FS, and if no milestone has a duration = 0, the milestone starts on the very day on which its predecessor ends.
At what time the successor of the milestone starts if such a constellation is given depends on the Start task successor + 1 day model parameter.
Example
If Start task successor + 1 day = and the MS duration = 0, both the MS as well as the successor of MS start on the very day on which the predecessor of MS ends. I.e. in this constellation, the milestones "shorten" the project duration compared to the constellation without milestones.
Cf.
If Start task successor + 1 day = , and the MS duration = 0, the MS starts on the same day as its predecessor, the successor of MS, however, starts one day later, so that the constellation for the project duration with or without milestones is identical.
In the milestone planning, PLANTA also supports further planning models, like e.g. no links of milestones or milestone duration = 1. As a result, different impacts on the total schedule can be observed as in the examples above.
When working with milestone duration = 0, the additional effect of task requested dates is to be taken into account:
If both dates are set, the duration is automatically calculated from these values and can never be = 0.
The parameter can be edited in the following modules by users with modification rights:
Name (text) of the Milestone parameter. For description, see DI059007
DI006800 Functional completed in %
Functional degree of completion of a task as a percentage value. This value can be entered as an estimated value by the project manager.
Details
The entered value is compared to the values in the Used (Effort used in %) field, and, depending on whether these values are under- or overrun, the Completed (DI006800 Functional completed in %) field is colored green or red.
The parameter can be edited in the following modules by users with modification rights:
The parameter defines whether tasks for which adherence to the schedule is dependent on the customer are displayed in the Customer schedule module (variant of the Schedule module).
Values
- the task is displayed in the Customer Schedule module variant.
- the task is not displayed in the Customer Schedule module variant.
The parameter can be edited in the following module by users with modification rights:
In the calculation of the schedule, information on the parent task, such as duration and dates, is determined automatically from the child tasks.
Caution
When working with structured schedules, PLANTA recommends that you use summary tasks as structuring elements only, i.e. you should not carry out effort or cost planning or enter durations on this level. This includes resource planning or time recording directly to the summary task. Instead, PLANTA recommends that you carry out the planning on the child task only.
Reason: Since the scheduling detects some parameters of the summary tasks from child tasks, there may be collisions between your own planned values and those detected by the scheduling. As a result, there may be values on summary tasks that are incomprehensible at first sight.
Code (ID) of the parent task which is set when structuring the tasks
Note
DI008851 must not be confused with DI001004 Parent task ID on the project, which has the same name but a completely different function. DI001004 Parent task ID is filled with the structure task ID from the parent project when structuring a project.
DI059257 Structure task
This parameter defines whether the task in question is a normal task or a structure task.
Values (are calculated by the value range)
0 = normal task
1 = structure task
Details
After projects have been structured and the schedule has been calculated, a structure task is created automatically in each parent project. The structure task is a task which links a parent project to a subproject.
In standard, structure tasks are hidden in all modules in question by default and cannot be unhidden by the user. This is to be observed for individual customizing as well.
In order to hide structure tasks, include DI059257 Structure task in the corresponding data area and set the Filter from = 0 and Filter to parameters = 0 for this DI.
Bar for the visualization of the interval in which the tasks overlap. For more information, see here.
DI009480 Fixing
Code (ID) of the Fixing parameter. For description, see DI056886
DI056886 Fixing
Fixing options for requested dates This parameter serves to set how requested dates of the task are taken into account during scheduling. In input mode, a listbox for selection of a fixing position is displayed on the respective field.
Code
name
Meaning
Example
blank:
Without fixing
Requested dates of the task only take effect if no links exist and no capacity adjustment is carried out. Otherwise the task can be shifted, e.g. via links or capacity adjustment.
1
With fixing
The task is scheduled exactly for the requested dates.
The task duration corresponds to the specified requested dates
Links will be ignored.
Capacity adjustment is deactivated.
The resources are planned within the task requested dates. If they do not have sufficient capacity, they will be overloaded.
Active today's line will be ignored.
Only takes effect if at least one requested date is set.
2
Without fixing, adherent to schedule
No fixing, however date-oriented scheduling of task resources within the planned duration of a task.
Links will be taken into account, the task may be shifted.
Capacity adjustment is deactivated.
For Planned duration of the task = 0, the task duration is determined as the maximum duration from all resource assignments.
The resources are planned within the task requested dates. If they do not have sufficient capacity, they will be overloaded.
Loading of Max. load/day for the remaining duration period.
For Planned duration of the task = 0, the task duration is determined as the maximum duration from all resource assignments.
Stop
For data logical and data consistency reasons, tasks that have already been defined as hammock tasks (Hammock task parameter is activated) must not be frozen.
The effect of the Fixing parameter is overwritten by the Task requested dates model parameter..
Using the Fixing parameter = 1 in combination with particular other parameters may result in a scheduling problem. For further informations, see here.
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the Entire Schedule module variant (can be displayed in further module variants)
If an Actual start has been set for the task, the progress symbol will be blue.
If an Actual end has been set for the task, the progress symbol will be black.
DI057005 TDI: 1
Technical data item. It is used to visualize the number of tasks in different modules. E.g., in the Activities area (Todo items up to DB 39.5.0) in the Dashboard module, the number of process steps is displayed by 4 statuses (late, today, future, without date).
DI057577 Date status
Text on the date status (e.g. today, delayed, etc.) of the tasks
DI057950 Parent task name
Name of the parent task
DI058050 Deviation calc. start: current - selected SR
Deviation of the calculated start date of the task (from the current planning) from the calculated start date of the task (from the selected status report)
Symbols for the task estimation or task flag. New tasks, for which no notes or estimates have existed before, are initially displayed without symbols.
Values
no symbol - no note
- completed
- very critical
- critical
- being monitored
- very good
- mediocre
- bad
Details
: This symbol will automatically be displayed/hidden as soon as the Actual end date has been entered/deleted for the respective task, or can be set/deleted manually. All other symbols are set/removed manually by clicking on the Change note button in the respective task line in the Schedule module ( not in all module variants), in the Task module or in the respective task checkbox in the WBS module.
Note
The symbols can be edited by the customizer in the OLEs module.
DI040925 OLE milestone
Rhomb symbol for master milestones or milestones in the WBS module
Values
Light blue rhomb - milestone
Black rhomb - master milestone
DI059707 OLE deviation total effort: current - active SR
DI059708 OLE deviation total costs: current - active SR
Traffic light for the visualization of the deviation of Total costs from the current planning from Total costs from the active (last released) status report in the Dashboard in the Deviations area
DI059020 OLE deviation total costs: current - selected SR
Traffic light for the visualization of the deviation of the Total costs (from the current planning) from the Total costs (from the selected status report in the Deviations module)
DI059021 OLE deviation total effort: current - selected SR
Traffic light for the visualization of the deviation of the Total effort (from the current planning) from the Total effort (from the selected status report in the Deviations module)
DI059022 OLE deviation calc. end: current - selected SR
Traffic light for the visualization of the Calc. end from the current planning from Calc. end from the selected status report
DI059023 OLE deviation calc. start: current - selected SR
Traffic light for the visualization of the Calc. start from the current planning from Calc. start from the selected status report
DI059710 Deviation total effort: current - active SR
Name of the person responsible for the task. In input mode, a listbox for selection of a person responsible is displayed on the respective field.
Details
If a resource is defined as a person responsible for a task, this task is displayed in the Tasks area of the My Planning Objects module in the Employee Board of the resource.
The parameter can be edited in the following modules by users with modification rights:
By setting a task requested end, a task has no float with respect to its calculated end date
If tasks are planned late (Planning early = parameter = Total float = 0.
To get a more exact overview of the latest dates, it may help to activate the display of the latest dates bar from window 9.
Details
To visualize the tasks as critical or uncritical, the traffic light circuit of the task bars is based on the Total float parameter. Thus
regular tasks which have total float < = 0 are visualized as critical.
milestone and master milestone tasks which have total float < 0 are visualized as critical.
Since in PLANTA projecttotal float = 0 can be achieved by setting requested dates on tasks, tasks which do not necessarily lie on the critical path are marked as critical.
If you do not want this to happen, you have to plan with task duration or with task requested start dates and task duration only.
Taking floats into account in different planning types
Floats are not used in planning with adherence to schedule.
When planning with adherence to total float, existing floats are used if necessary.
When planning with adherence to capacity, floats and project end date will not be taken into account.
DI001130 Free float
Free float of the task. The free float is determined from the minimum of all successor links.
For tasks without successor, "free float" = "total float”
DI001147 Time recording date of the task
The latest date on which hours worked were recorded on the task. This date corresponds to the latest time recording date of all resource assignments of a task. If the task has no resource assignments, please take note of the information set out below.
Scheduling
If there are no resource assignments,
the time recording date of the task is set to the Actual start of the task if it already exists but no Actual end has been set yet.
the time recording date of the task is set to Actual end as soon as one exists.
the time recording date of the task = 0 if none of the actual dates exists.
DI063726 Deviation: req. end - calc. end end (text)
Absolute deviation of the calculated end date from the requested end date of the task with text specification (delay/float)
DI063937 SAP WBS element
Name of an SAP WBS element. In input mode, a listbox for selection of an SAP WBS element is displayed on the respective field in order to assign it to a PLANTA task. This link is required for transferring costs and effort from the project structure in PLANTA project to an alternative structure (e.g. an SAP project structure).
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the SAP WBS elements module variant (can be displayed in further module variants).
Position number of the quality gates within the quality gate template. It is allocated manually upon creation of the template and defines the sort sequence of the quality gates within the quality gate template.
The parameter can be edited in the following module by users with modification rights:
Checkbox used to approve a quality gate. In the course of this, an Actual end date is set automatically (in the Quality Gates module the field is named Approved on) and the quality gate will be considered completed.
The parameter can be edited in the following module by users with modification rights:
Displays the degree of completion according to percentage values and traffic light colors. The value displayed here is calculated from the degree of completion of the assigned tasks and their priority.
Values
no traffic light: the degree of completion of the quality gate is lower than 100%.
green: the quality gate is completed by 100%.
Note
The completed value of the quality gate influences the behavior of the traffic light on the Date field.
DI064994 Completed on: Manager
Date, on which the quality gate was completed. Is set by the manager of the respective project. If the field is filled, the Completed on field of the child todo items which have no completed date yet are automatically filled with the date of the quality gate.
DI064760 Time interval
Time interval to the date selected for the calculation of the date of the quality gate selected in the Start field.
The parameter can be edited in the following module by users with modification rights:
Parameter which defines whether the task is to be regarded as critical. The value is set during scheduling.
Information
Tasks the total float of which = 0 are marked as critical and therefore lie on a critical path.
Exceptions: Single tasks which have neither predecessor nor successor (which are hence not connected via links) are not marked as critical even if they have no total float, unless they determine the project length.
Details
Tasks which are planned late do not have a total float by definition and are critical.
For each requested date (project requested end date or task requested end date) there is a critical path in the project. A task can also belong to multiple critical paths. If a project float exists, a task can be critical anyway since it belongs to a critical path which is created by a task requested date.
Summary task are marked as critical (however, they are not visualized in the schedule) if at least one child task is critical.
Caution
With Server 39.5.25, PLANTA only provides the parameter for the calculation of the critical path. If you want to visualize the longest critical path in the schedules, you have to make respective individual customizing changes and embed the parameter in the task bar.
This parameter can only be used if scheduling afterrun is activated in planta_scheduler.conf.
DI064921 Longest critical path BETA
Parameter which determines whether the task lies on the longest critical path. The value is set during scheduling.
Note
The classical critical path (cf. CPM) ends on the project requested date and is therefore always the path with the longest duration.
Caution
With Server 39.5.25, PLANTA only provides the parameter for the calculation of the longest critical path. If you want to visualize the longest critical path in the schedules, you have to make respective customizing changes and embed the parameter in the task bar.
This parameter can only be used if scheduling afterrun is activated in planta_scheduler.conf.
DI064945 Relevant for external system
Checkbox with which you can mark which tasks are to be synchronized with an external system (currently PLANTA pulse or Jira).
Details
This checkbox is hidden by default and is unhidden as soon as the respective external system has been defined in the in the External system field in the Project Core Data module. However, this requires that the interface to the external system has been configured up front. Depending on which external system has been selected, the checkbox will not be titled Relevant for external system in the Schedule but either Jira or PLANTA pulse.
The parameter can be edited in the following module by users with modification rights:
Checkbox for the selection of a task. The checkbox is used in different user modules, e.g. in the Assign Tasks module.
DI001112 Split
Parameter which determines whether tasks are to be broken off (split) in editing
Details
Any task which has been started will be loaded adherent to schedule, starting from its actual start date. However, if you do not want to continue to work on the task without interruption, the task may be split.
The effect of this is that the remainder of the task (Remaining duration, Remaining effort) will be planned as if there was no actual data. It is thus also possible to carry out capacity adjustment for the residual task.
The parameter is activated in PLANTA standard by default ().
Splitting only has an effect on tasks which have already been started (Actual start reported) but are not yet completed (no Actual end reported).
Values
: The task will be scheduled as if it had no Actual start yet. It represents an interruption in a task.
: The task is scheduled continuously from the Actual start.
It can be reasonable to already set particular tasks to Split = in planning, if it is known that these tasks are usually interrupted.
If capacity adjustment is to be carried out for a task which has already started, the setting should be Split = .
If a split task is to be worked on continuously at a later time, Split can be reset to .
Show example of application...
Typical application in practice
A project team member has reported a couple of hours on the Construction task using work reporting. However, these activities are only to allow some provisional orders to be placed for long lead-time components of assemblies, and the actual design work will not be carried out until later.
Task before entry of hours worked:
Resource Benjamin Fischer has reported 5 hours of work to the Construction task. The task is not split. The calculation of the schedule results in the following picture:
Work on this task is not to be continued but scheduled for a later point in time. By setting Split = , the rest of the task will be planned according to the network plan. It is also moved by requested dates.
If the project planning type is changed, e.g. from adherent to schedule or float, and, e.g. the CAP load profile is assigned to a task, then the remainder of the task may be planned at an even later date.
Please note:
If the parameter of the same name (Split) is activated at project level and Split is deactivated on the task, the project parameter overwrites the task parameter; but not the other way around.
If the parameter is set on a summary task, it causes the Calc. start of the summary task to be the earliest Calc. start of all child tasks. This may cause unnecessary postponement of dates. Cf:
The parameter can be edited in the following modules by users with modification rights:
