# Property Reference

## The TJP File

The TJP File
`Description` | All TaskJuggler project files should start with the project property and must contain at least one task definition. To visualize the results of the scheduling process, at least one of the reports should be specified.
`Optional Attributes` | account, copyright, csvaccountreport, csvresourcereport, csvtaskreport, export, flags, htmlaccountreport, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlmonthlycalendar, htmlweeklycalendar, include, macro, maxeffort, limits, priority, projectid, projectids, project, rate, resource, shift, supplement, task, vacation, xmlreport
`Context` |
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "My Tasks"

## account <`id`> <`name`> [ <`type`> ]

account <`id`> <`name`> [ <`type`> ]
`Description` | Declares an account. Accounts can be used to calculate costs of tasks or the whole project. Account declaration may be nested, but only the top level accounts may have a type attribute specified. An account that has sub-accounts may not have a credit or a kotrusid. sub-accounts inherit this type.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID | Each account must have a unique ID.
`name` | STRING |
`type` | ID | The type may be `cost` or `revenue`.
`Optional Attributes` | `account`, credit, kotrusid
`Context` | The TJP File, `account`,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvaccountreport, htmlaccountreport

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## account <`accountid`>

account <`accountid`>
`Description` | All amounts associated with the task will be credited to the specified account. The account must not be an account group.
`Attributes` | `Name` | `Type` | `Description`
`accountid` | ID |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | account

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## accumulate

accumulate
`Description` | If this attribute is specified the values in the calendar columns are accumulated over the reported interval.
`Context` | csvaccountreport, csvresourcereport, csvtaskreport, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## allowredefinition

allowredefinition

`Description`

If this attribute is specified, redefinitions of task, resources or accounts are not flagged as errors. The primary use of this attribute is for projects that are created by merging sub projects which are again the result of sub project merging. In certain situations enclosing tasks, accounts or resources can be included in more than one sub project. This attribute then avoids the error message which is in most other cases a real user error. So use this feature with care as real errors might go undetected.

In case attributes of the same property must be specified in two different locations the supplement construct is the recommended way to do this.

`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No

## allocate <`resource`>

allocate <`resource`>
`Description` | Specify which resources should be allocated to the task.
`Attributes` | `Name` | `Type` | `Description`
`resource` | ID |
`Optional Attributes` | alternative, limits, mandatory, persistent, purge, select, shift
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | effort

    project allocate "allocate" "1.0" 2003-06-05 2003-07-05

    resource r1 "Resource 1"
    resource r2 "Resource 2"

    task t1 "Task 1" {
      start 2003-06-05
      # All sub-tasks inherit this allocation of r1
      allocate r1
      task t2 "Task 2" {
        effort 10d
      }
      task t3 "Task 3" {
        effort 20d
        # This task has r1 and r2 allocated
        allocate r2
      }
      task m1 "Milestone 1" {
        milestone
      }
    }

## alternative <`resource`> [, <`resource`> ... ]

alternative <`resource`> [, <`resource`> ... ]
`Description` | A list of alternative resources for an allocation. There is no difference between the allocated resource and its alternatives. If no selection criteria is given, TaskJuggler picks the resource that it finds most appropriate.
`Attributes` | `Name` | `Type` | `Description`
`resource` | ID |
`Context` | allocate,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | select

    project prj "Project" "1.0" 2000-01-01 2000-03-01

    resource tuxus "Tuxus"
    resource tuxia "Tuxia"

    task t "Task" {
      start 2000-01-01
      effort 5d
      # Use tuxux or tuxia, whoever is available.
      allocate tuxus { alternative tuxia }
    }

## barlabels <`mode`>

barlabels <`mode`>
`Description` | Specifies the contents of the Gantt chart like bars in HTML calendar columns. The default is to show load values.
`Attributes` | `Name` | `Type` | `Description`
`mode` | ID | See table below for possible values.
`Context` | htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | columns, showprojectids

- `empty`
- Do not show any values on calendar bars.
- `load`
- Show task or resource load on calendar bars.

## baseline

baseline
`Description` | Disables the projection mode for the scenario. This is the default for the top-level scenario. In baseline mode it is assumed that no bookings are provided for any task.
`Context` | scenario,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | projection

## booking <`task`> <`period`> [, <`period`> ... ]

booking <`task`> <`period`> [, <`period`> ... ]

`Description`

The booking attribute can be used to report completed work. This can be part of the necessary effort or the whole effort. When the scenario is scheduled in projection mode, TaskJuggler assumes that only the work reported with bookings has been done up to now. It then schedules a plan for the still missing effort.

This attribute is also used within export reports to describe the details of a scheduled project.

The sloppy attribute can be used when you want to skip non-working time or other allocations automatically. If it's not given, all bookings must only cover working time for the resource.

`Attributes` | `Name` | `Type` | `Description`
`task` | ID |
`period` | DATEINTERVAL |
`Optional Attributes` | overtime, sloppy
`Context` | resource,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | complete, projection, sloppy, strict

    project prj "Project" "1.0" 2003-06-05 +1m {
      # The baseline date for the projection.
      now 2003-06-15
      scenario plan "Plan" {
        # Compute when the task will be ready based on the already done
        # work and the current date.
        projection { strict }
      }
    }

    resource r1 "Resource 1"

    task t1 "Task 1" {
      start 2003-06-05
      effort 10d
      allocate r1
    }

    supplement resource r1 {
      # This is the work that has been done up until now by r1.
      booking t1 2003-06-06 +8h { sloppy 2 }
      booking t1 2003-06-08 +4h,
                 2003-06-09 +4h { sloppy 2 }
      # Book interval that extends into off-hours.
      booking t1 2003-06-11-8:00 +10h { overtime 1 }
    }

## caption <`text`>

caption <`text`>
`Description` | Specifies the caption used for a report table.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | complete, copyright, headline

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    copyright "Bucks Beavis Inc."

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    htmltaskreport "ProjectBreakdown.html" {
      caption "This is the project breakdown"
      headline "Project Breakdown"
      columns name, start, end, daily
      # Don't hide any resource, meaning show them all.
      hideresource 0
    }

## celltext <`text`>

celltext <`text`>
`Description` | Specifies an alternative text that is used for all cells of the column. Usually such a text contains a runtime macro, otherwise all cells of the column will have the same fixed value.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | cellurl

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## cellurl <`url`>

cellurl <`url`>
`Description` | Specifies an URL that is attached to the cell contents of the cells of the column in HTML reports.
`Attributes` | `Name` | `Type` | `Description`
`url` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | celltext

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## columns <`columnid`> [, <`columnid`> ... ]

columns <`columnid`> [, <`columnid`> ... ]

`Description`

Specifies which columns shall be included in a report.

All columns support macro expansion. Contrary to the normal macro expansion, these macros are expanded during the report generation. So the value of the macro is being changed after each table cell or table line. Consequently only build in macros can be used. To protect the macro calls against expansion during the initial file processing, the report macros must be prefixed with an additional `$`.

`Attributes` | `Name` | `Type` | `Description`
`columnid` | ID | See table below for possible values.
`Optional Attributes` | celltext, cellurl, hidecelltext, hidecellurl, subtitle, subtitleurl, title, titleurl
`Context` | csvaccountreport, csvresourcereport, csvtaskreport, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No

- `chart`
- Use this column to get Gantt and resource charts. It's only supported by the interactive reports in the GUI.
- `completed`
- The percentage the task has been completed already. This is either the value specified by complete or a value computed according to the current date (or the date specified by now) and the length, duration or effort.
- `cost`
- The accumulated costs of the task and its sub tasks
- `criticalness`
- The criticalness of the task. It is a measure for the probability that an effort task gets the requested resources early.
- `daily`
- A day-by-day calendar view of the tasks
- `depends`
- The task index of the tasks on which this task depends
- `duration`
- The duration of the task
- `efficiency`
- The efficiency of the resource. It's a measurement of how much the resource can contribute to the workload of tasks.
- `effort`
- The effort put into the task
- `end`
- The end date of a task
- `endbuffer`
- The percentage of the endbuffer
- `endbufferstart`
- The start time of the end buffer
- `flags`
- The list of flags assigned to the task or resource
- `follows`
- The task index of the tasks that depend on this task
- `freeload`
- The workload of the resource that has not been allocated.
- `hierarchindex`
- The hierarchical index of a task. The index is calculated from the hierarchical structure of the list as well as the start and end dates.
- `hierarchno`
- The hierarchical number of a task. It is based on the order of declaration.
- `id`
- The global ID of a task
- `index`
- The index of a task. The index is calculated from the hierarchical structure of the list as well as the start and end dates.
- `kotrusid`
- The KotrRUs ID of the resource
- `maxeffort`
- The maximum daily load wanted for the resource
- `maxend`
- The latest desired end date
- `maxstart`
- The latest desired start date
- `mineffort`
- The minimum daily load wanted for the resource
- `minend`
- The earliest desired end date
- `minstart`
- The earliest desired start date
- `monthly`
- A month-by-month calendar view of the tasks
- `name`
- The name of a task, resource, or account
- `no`
- The task index in the list. It starts with 1 and increases for every listed item by 1.
- `note`
- The description of the task
- `pathcriticalness`
- The overall criticalness of the task. It is a measure for the probability that an effort task gets scheduled as early as possible. The tasks of the most critical path have the highest path criticalness.
- `priority`
- The scheduling priority
- `profit`
- The accumulated profit of the task and its sub tasks
- `projectid`
- The project ID of the task
- `projectids`
- The project IDs of the projects a resource is allocated to
- `quarterly`
- A quarter-by-quarter calendar view of the tasks
- `rate`
- The daily rate of the resource
- `reference`
- A reference to a URL that contains further information.
- `resources`
- The names of the used resources
- `responsibilities`
- A list of all tasks indices for which a resource is responsible
- `responsible`
- The name of the resource responsible for a task
- `revenue`
- The accumulated revenue of the task and its sub tasks
- `scenario`
- The name of the scenario. This column is helpful when multiple scenarios are shown in the table. See also scenarios.
- `seqno`
- The task index in the order of declaration. Each time a task declaration is completed, the sequence number is increased by 1.
- `schedule`
- A detailed schedule of the allocations for the resource.
- `start`
- The start date of a task
- `startbuffer`
- The percentage of the start buffer
- `startbufferend`
- The end time of the start buffer
- `status`
- The current status of the task. This is derived from the current date or the date specified by now and the degree of completion. The degree of completion is either computed or has been specified by complete.
- `total`
- Total accumulated values
- `utilization`
- The ratio between the allocated work load of the resource and it's overall available work load.
- `weekly`
- A week-by-week calendar view of the tasks
- `yearly`
- A year-by-year calendar view of the tasks

The following macros are supported for normal table cells:

- `$${0}`
- This is the original value of the table cell. This macro is useful if the user would like to extend the cell text with a fixed string.
- `$${accountid}`
- The ID of the account.
- `$${resourceid}`
- The ID of the resource.
- `$${taskid}`
- the id of the task.

Additionally the original contents of other cells of the same report line can be accessed by the column ID. The following columns are supported:

`index, no, hierarchindex, hierarchno, id, name`

For the title or sub title of the calendar columns (`daily, weekly, monthly, quarterly, yearly`) the following macros are supported:

`$${day}, $${month}, $${week}, $${quarter}, $${year}`.

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## complete <`percent`>

complete <`percent`>
`Description` | Specifies what percentage of the task is already completed. This can be useful for project tracking. Reports with calendar elements may show the completed part of the task in a different color. The completion percentage has no impact on the scheduler. It's meant for documentation purposes only. Tasks may not have subtasks if this attribute is used.
`Attributes` | `Name` | `Type` | `Description`
`percent` | INTEGER | The value must be between 0 and 100.
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | booking

    project simple "Some task" "1.0" 2005-06-06 2005-06-26 {
      now 2005-06-15
    }

    resource tux "Tux"

    task t "Task" {
      start 2005-06-06
      effort 10d
      allocate tux
      # This task should have be be completed much more on Jun 15, but
      # it's only 20% done.
      complete 20
    }

## copyright <`text`>

copyright <`text`>
`Description` | Adds a copyright notice to all subsequently defined reports. This notice may contain any text. The notice is added at the bottom of the report.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | headline, caption

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    copyright "Bucks Beavis Inc."

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    htmltaskreport "ProjectBreakdown.html" {
      caption "This is the project breakdown"
      headline "Project Breakdown"
      columns name, start, end, daily
      # Don't hide any resource, meaning show them all.
      hideresource 0
    }

## credit <`date`> <`description`> <`amount`>

credit <`date`> <`description`> <`amount`>
`Description` | Credits the specified amount to the account at the specified date. The description should contain some information about the reason for the transaction.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`description` | STRING |
`amount` | REAL |
`Context` | account,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## csvaccountreport <`filename`>

csvaccountreport <`filename`>
`Description` | The report lists all specified account values as a comma separated list. This is useful to export TaskJuggler data to Office Suites like OpenOffice.org or KOffice.
`Attributes` | `Name` | `Type` | `Description`
`filename` | STRING |
`Optional Attributes` | accumulate, columns, end, rollupaccount, hideaccount, period, separator, sortaccounts, start
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmlaccountreport

## csvresourcereport <`filename`>

csvresourcereport <`filename`>
`Description` | The report lists all specified resource values as a comma separated list. This is useful to export TaskJuggler data to Office Suites like OpenOffice.org or KOffice.
`Attributes` | `Name` | `Type` | `Description`
`filename` | STRING |
`Optional Attributes` | accumulate, columns, end, rollupresource, hideresource, period, separator, sortresources, start
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmlresourcereport, resourcereport

## csvtaskreport <`filename`>

csvtaskreport <`filename`>
`Description` | The report lists all specified task values as a comma separated list. This is useful to export TaskJuggler data to Office Suites like OpenOffice.org or KOffice.
`Attributes` | `Name` | `Type` | `Description`
`filename` | STRING |
`Optional Attributes` | accumulate, columns, end, rolluptask, hidetask, period, separator, sorttasks, start
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmltaskreport, taskreport

## currency <`text`>

currency <`text`>
`Description` | The default currency unit.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | currencyformat

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## currencyformat <`negativeprefix`> <`negativesuffix`> <`thousandseparator`> <`fractionseparator`> <`fractiondigits`>

currencyformat <`negativeprefix`> <`negativesuffix`> <`thousandseparator`> <`fractionseparator`> <`fractiondigits`>
`Description` | These values specify the default format used for all currency values. The `negativeprefix` and `negativesuffix` strings enclose negative currency values. The `thousandseparator` can be used to make large numbers more readable. The `fractionseparator` separates the fractional part from the rest. `fractiondigits` specifies how many fractional digits should be shown at a maximum.
`Attributes` | `Name` | `Type` | `Description`
`negativeprefix` | STRING |
`negativesuffix` | STRING |
`thousandseparator` | STRING |
`fractionseparator` | STRING |
`fractiondigits` | INTEGER |
`Context` | project,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | currency

    project prj "Project" "1.0" 2000-01-01 2000-03-01 {
      # German number format: e. g.  -10000,20 5014,11
      numberformat "-" "" "" "," 2

      # US currency format: e. g. (10,000.20) 5,014.11
      currencyformat "(" ")" "," "." 2
    }

    task t "Task" {
      start 2000-01-01
      milestone
    }

## dailymax <`value`> <`unit`>

dailymax <`value`> <`unit`>
`Description` | Sets the daily limit of a resource usage or a resource allocation to a task.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | limits,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | monthlymax, weeklymax

    project limits "Limits" "1.0" 2004-03-01 2004-05-01

    # Default limit that affects all subsequently defined resources
    limits {
      weeklymax 4d
    }

    resource r1 "R1" {
      # Limit the usage of this resource to a maximum of 2 hours per day,
      # 6 hours per week and 2.5 days per month.
      limits { dailymax 2h weeklymax 6h monthlymax 2.5d }
    }

    resource r2 "R2"

    task t1 "Task 1" {
      start 2004-03-01
      duration 60d
      # allocation is subject to resource limits
      allocate r1
    }

    task t2 "Task 2" {
      start 2004-03-01
      duration 60d
      # limits can also be specified per allocation
      allocate r2 {
        limits { dailymax 4h weeklymax 3d monthlymax 2w }
      }
    }

## dailyworkinghours <`hours`>

dailyworkinghours <`hours`>
`Description` | Set the average number of working hours per day. This is used as the base to convert working hours into working days. This affects for example the length task attribute. The default value is 8 hours and should work for most Western countries. The value you specify should match the settings you specified for workinghours.
`Attributes` | `Name` | `Type` | `Description`
`hours` | REAL |
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | yearlyworkingdays

    project prj "Example Project" "1.0" 2000-01-01 2000-03-09 {
      # The following attributes are all optional. They illustrate the
      # default values. These attributes are only needed if you want to
      # specify different values than those listed below.
      dailyworkinghours 8
      yearlyworkingdays 260.714
      timingresolution 60min
      timeformat "%Y-%m-%d %H:%M"
      shorttimeformat "%H:%M"
      currencyformat "(" ")" "," "." 0
      weekstartsmonday
        workinghours mon - fri 9:00 - 12:00, 13:00 - 18:00
        workinghours sat, sun off
      scenario plan "Plan" {
      }
    }

    task t "Task" {
      start 2000-01-01
    }

## depends <`task`> [, <`task`> ... ]

depends <`task`> [, <`task`> ... ]

`Description`

Specifies that the task cannot start before the task with the specified IDs have been finished. If multiple IDs are specified, they must be separated by commas. IDs must be either global or relative. A relative ID starts with a number of '!'. Each '!' moves the scope to the parent task. Global IDs do not contain '!', but have IDs separated by dots.

Each task ID can have optional attributes enclosed in braces.

By using the 'depends' attribute, the scheduling policy is automatically set to `asap`. If both `depends` and `precedes` are used, the last policy counts.

`Attributes` | `Name` | `Type` | `Description`
`task` | ID |
`Optional Attributes` | gapduration, gaplength
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | scheduling, precedes

    project p "P" "1.0" 2003-11-09 2003-12-24

    task foo1 "foo1" {
      task foo2 "foo2" {
        start 2003-12-04
        milestone
      }
      task foo3 "foo3" {
        depends !foo2
        length 1d
      }
    }
    task bar "bar" {
      depends foo1.foo2
      length 2d
    }

    task bar1 "bar1" {
      depends foo1 { gapduration 2d }, bar { gaplength 1d }
      duration 2d
    }

## disabled

disabled
`Description` | Disables the scenario for scheduling.
`Context` | scenario,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | enabled

    project prj "Example" "1.0" 2005-05-29 2005-07-01 {
      scenario plan "Planned Scenario" {
        scenario actual "Actual Scenario"
        scenario test "Test Scenario" {
          disabled
        }
      }
    }

    task t "Task" {
      start 2005-05-29
      actual:start 2005-06-03
      test:start 2005-06-07
    }

## duration <`value`> <`unit`>

duration <`value`> <`unit`>
`Description` | Specifies the time the task occupies the resources. This is calendar time, not working time. 7d means one week. If resources are specified they are allocated when available. Availability of resources has no impact on the duration of the task. It will always be the specified duration. Tasks may not have subtasks if this attribute is used.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | effort, length

    project duration "Duration Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task t "Enclosing" {
      start 2005-06-06
      task durationTask "Duration Task" {
        # This task is 10 calendar days long.
        duration 10d
      }

      task intervalTask "Interval Task" {
        # This task is similar to the durationTask. Instead of a start
        # date and a duration it has a fixed start and end date.
        end 2005-06-17
      }

      task lengthTask "Length Task" {
        # This task 10 working days long. So about 12 calendar days.
        length 10d
      }

      task effortTask "Effort Task" {
        effort 10d
        allocate tux
      }
    }

## efficiency <`value`>

efficiency <`value`>

`Description`

The efficiency of a resource can be used for two purposes. First you can use it as a crude way to model a team. A team of 5 people should have an efficiency of 5.0. Keep in mind that you cannot track the member of the team individually if you use this feature. The other use is to model performance variations between your resources.

All resources that do not contribute effort to the task, should have an efficiency of 0.0.

`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`Context` | resource,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | load

    project prj "Resource Efficiency Example" "1.0" 2005-07-21 2005-07-22

    # A team of 5 people. They can only be assigned en block. Either all
    # or nobody works.
    resource tuxies "Tuxies" { efficiency 5.0 }

    # A hard-working guy
    resource tux1 "Tux 1" { efficiency 1.2 }

    # And a lazy one
    resource tux2 "Tux 2" { efficiency 0.9 }

    # And a thing that cannot do any work
    resource confRoom "Conference Room" { efficiency 0 }

    task t "An important date" {
      start 2005-07-21
    }

## effort <`value`> <`unit`>

effort <`value`> <`unit`>

`Description`

Specifies the effort needed to complete the task. An effort of 4d can be done with 2 full-time resources in 2 days. The task will not finish before the resources have contributed the specified effort. So the duration of the task will depend on the availability of the resources.

WARNING: In almost all real world projects effort is not the product of time and resources. This is only true if the task can be partitioned without adding any overhead. For more information about this read "The Mythical Man-Month" by Frederick P. Brooks, Jr.

Tasks may not have subtasks if this attribute is used.

`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | duration, length

    project duration "Duration Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task t "Enclosing" {
      start 2005-06-06
      task durationTask "Duration Task" {
        # This task is 10 calendar days long.
        duration 10d
      }

      task intervalTask "Interval Task" {
        # This task is similar to the durationTask. Instead of a start
        # date and a duration it has a fixed start and end date.
        end 2005-06-17
      }

      task lengthTask "Length Task" {
        # This task 10 working days long. So about 12 calendar days.
        length 10d
      }

      task effortTask "Effort Task" {
        effort 10d
        allocate tux
      }
    }

## enabled

enabled
`Description` | Enable the scenario for scheduling. This is the default for the top-level scenario.
`Context` |
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | disabled

## end <`date`>

end <`date`>
`Description` | Specifies the end date of the report. In task reports only tasks that start before this end date are listed.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | csvaccountreport, csvresourcereport, csvtaskreport, export, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | period, start

    project prj  "Project" "1.0" 2000-01-01 2000-03-01

    resource r "Resource"

    task t "Task" {
      start 2000-01-01
      effort 10d
      allocate r
    }

    # Export the project as fully scheduled project.
    export "FullProject.tjp" {
      taskattributes all
      hideresource 0
    }

    # Export only bookings for 1st week as resource supplements
    export "Week1Bookings.tji" {
      start 2000-01-01
      end 2000-01-08
      properties bookings
      hideresource 0
    }

## end <`date`>

end <`date`>
`Description` | The end date of the task. When specified for the top-level (default) scenario this attributes also implicitly sets the scheduling policy of the tasks to `alap`.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | period, start, maxend, minend, scheduling, endbuffer

    project duration "Duration Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task t "Enclosing" {
      start 2005-06-06
      task durationTask "Duration Task" {
        # This task is 10 calendar days long.
        duration 10d
      }

      task intervalTask "Interval Task" {
        # This task is similar to the durationTask. Instead of a start
        # date and a duration it has a fixed start and end date.
        end 2005-06-17
      }

      task lengthTask "Length Task" {
        # This task 10 working days long. So about 12 calendar days.
        length 10d
      }

      task effortTask "Effort Task" {
        effort 10d
        allocate tux
      }
    }

## endbuffer <`percent`>

endbuffer <`percent`>
`Description` | Specifies how much slack time you expect to have at the end of the task. This has no impact on the scheduling of the process. This information is for documentation purposes only.
`Attributes` | `Name` | `Type` | `Description`
`percent` | REAL | Percent slack of the overall effort, duration or length of the task.
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | duration, effort, length, startbuffer

    project simple "Simple Project" "$Id" 2000-01-01 2000-01-20

    resource tux1 "Tux1"

    task t1 "Task1" {
      start 2000-01-01
      length 10d
      # 20% of the working time of this task are marked as buffer at the
      # beginning.
      startbuffer 20
      # An additional 10% of the working time of this task are marked as
      # buffer at the end.
      endbuffer 10.0
      allocate tux1
    }

    # Generate a report that lists the start end end dates for the
    # buffers.
    htmltaskreport "Buffer.html" {
      columns no, name, start, startbufferend, endbufferstart, end,
      startbuffer, endbuffer, duration, effort, daily
      hideresource 0
    }

## endcredit <`amount`>

endcredit <`amount`>
`Description` | Specifies an amount that is credited to the account specified by the account property at the moment the tasks ends.
`Attributes` | `Name` | `Type` | `Description`
`amount` | REAL |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | startcredit

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## export <`filename`>

export <`filename`>

`Description`

The export report looks like a regular TaskJuggler file but contains fixed start and end dates for all tasks. The tasks only have start and end times, their description and their project id listed. No other attributes are exported unless they are requested using the taskattributes attribute. The contents also depends on the extension of the file name. If the file name ends with `.tjp` a complete project with header, resource and shift definitions is generated. In case it ends with `.tji` only the tasks and resource allocations are exported.

If specified the resource usage for the tasks is reported as well. But only those allocations are listed that belong to tasks listed in the same export report.

The export report can be used to share certain tasks or milestones with other projects. When an export report is included the project IDs of the included tasks must be declared first with the project id property.

`Attributes` | `Name` | `Type` | `Description`
`filename` | STRING |
`Optional Attributes` | end, hideresource, hidetask, properties, rollupresource, rolluptask, period, scenarios, start, taskattributes, taskroot
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | include

    project prj  "Project" "1.0" 2000-01-01 2000-03-01

    resource r "Resource"

    task t "Task" {
      start 2000-01-01
      effort 10d
      allocate r
    }

    # Export the project as fully scheduled project.
    export "FullProject.tjp" {
      taskattributes all
      hideresource 0
    }

    # Export only bookings for 1st week as resource supplements
    export "Week1Bookings.tji" {
      start 2000-01-01
      end 2000-01-08
      properties bookings
      hideresource 0
    }

## extend <`property`>

extend <`property`>

`Description`

Often it is desirable to collect more information in the project file than is necessary for task scheduling and resource allocation. To add such information to tasks, resources or accounts the user can extend these properties with user-defined attributes. The new attributes can be `text` or `reference` attributes. Optionally the user can specify if the attribute value should be inherited from the enclosing property.

`Attributes` | `Name` | `Type` | `Description`
`property` | ID | Possible values are `task`, `resource` or `account`
`Optional Attributes` | inherit
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No

<type> <id> <name>

- type:
- Specifies the type of the user-defined attribute. `text` is a simple text attribute. `reference` is an URL to another document.
- id:
- An user-defined ID that is unique within the used-defined task attributes. To avoid conflicts with future built-in attributes, all user defined attributes must start with a capital letter.
- name:
- A short description of the attribute. It will be used as default column header in reports.

    project ca "Custom Attributes" "1.0" 2003-05-28 2003-06-28 {
      extend task {
        reference MyLink "My Link"
        text MyText "My Text" { inherit }
      }
    }

    task t "Task" {
      start 2003-05-28
      milestone
      MyLink "http://www.taskjuggler.org" { label "TJ Web" }
      MyText "TaskJuggler is great!"
    }

## flags <`flag`> [, <`flag`> ... ]

flags <`flag`> [, <`flag`> ... ]
`Description` | Attach a set of flags. The flags can be used in logical expressions to filter properties from the reports.
`Attributes` | `Name` | `Type` | `Description`
`flag` | ID |
`Context` | resource, task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | flags

    project prj "Flags Example" "1.0" 2005-07-21 2005-08-26

    # Declare the flag to mark important tasks
    flags important

    task items "Project breakdown" {
      start 2005-07-22

      task plan "Plan work" {
        length 3d
        flags important
      }

      task implementation "Implement work" {
        length 5d
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        flags important
      }
    }

    taskreport "My Tasks" {
      # Show only the important tasks
      hidetask ~important
      # Turn treemode off so parent tasks are not automatically included.
      sorttasks nameup
    }

## flags <`flag`> [, <`flag`> ... ]

flags <`flag`> [, <`flag`> ... ]
`Description` | Declare a set of flags for later use.
`Attributes` | `Name` | `Type` | `Description`
`flag` | ID |
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | flags

    project prj "Flags Example" "1.0" 2005-07-21 2005-08-26

    # Declare the flag to mark important tasks
    flags important

    task items "Project breakdown" {
      start 2005-07-22

      task plan "Plan work" {
        length 3d
        flags important
      }

      task implementation "Implement work" {
        length 5d
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        flags important
      }
    }

    taskreport "My Tasks" {
      # Show only the important tasks
      hidetask ~important
      # Turn treemode off so parent tasks are not automatically included.
      sorttasks nameup
    }

## gapduration <`value`> <`unit`>

gapduration <`value`> <`unit`>
`Description` | Specifies the minimum required gap between the end of a preceding task and the start of this task, or the start of a following task and the end of this task. This is calendar time, not working time. 7d means one week.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | depends, precedes,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | duration, gaplength

    project prj "Example Project" "1.0" 2005-05-29 2005-07-01

    task t1 "Task 1" {
      start 2005-05-29
    }

    task t2 "Task 2" {
      # starts 5 calendar days after t1
      depends !t1 { gapduration 5d }
    }

    task t3 "Task 3" {
      # starts 5 working days after t1
      depends !t1 { gaplength 5d }
    }

## gaplength <`value`> <`unit`>

gaplength <`value`> <`unit`>
`Description` | Specifies the minimum required gap between the end of a preceding task and the start of this task, or the start of a following task and the end of this task. This is working time, not calendar time. 7d means 7 working days, not one week. Whether a day is considered a working day or not depends on the defined working hours and global vacations.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | depends, precedes,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | gapduration, length

    project prj "Example Project" "1.0" 2005-05-29 2005-07-01

    task t1 "Task 1" {
      start 2005-05-29
    }

    task t2 "Task 2" {
      # starts 5 calendar days after t1
      depends !t1 { gapduration 5d }
    }

    task t3 "Task 3" {
      # starts 5 working days after t1
      depends !t1 { gaplength 5d }
    }

## headline <`text`>

headline <`text`>
`Description` | Specifies the headline for a report.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | caption, copyright

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    copyright "Bucks Beavis Inc."

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    htmltaskreport "ProjectBreakdown.html" {
      caption "This is the project breakdown"
      headline "Project Breakdown"
      columns name, start, end, daily
      # Don't hide any resource, meaning show them all.
      hideresource 0
    }

## hideaccount <`logicalexpression`>

hideaccount <`logicalexpression`>
`Description` | Do not show accounts that match the specified logical expression. If the report is sorted in tree mode (default) then enclosing accounts are listed even if the expression matches the account.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvaccountreport, htmlaccountreport,
`Inheritable` | No | `Scenario Spec.` | No

## hidecelltext <`expression`>

hidecelltext <`expression`>
`Description` | If the expression is true, the cell will be empty.
`Attributes` | `Name` | `Type` | `Description`
`expression` | LOGICALEXPRESSION |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | hidecellurl

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## hidecellurl <`expression`>

hidecellurl <`expression`>
`Description` | If the expression is true, no URL will be attached to the cell contents.
`Attributes` | `Name` | `Type` | `Description`
`expression` | LOGICALEXPRESSION |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | hidecelltext

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## inherit

inherit
`Description` | If this flag is present a user defined attribute gets inherited by child properties when specified for a parent.
`Context` | extend,
`Inheritable` | No | `Scenario Spec.` | No

## hideresource <`logicalexpression`>

hideresource <`logicalexpression`>
`Description` | Do not show resources that match the specified logical expression. If the report is sorted in tree mode (default) then enclosing resources are listed even if the expression matches the resource.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvresourcereport, export, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, icalreport, resourcereport, taskreport, xmlreport,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    copyright "Bucks Beavis Inc."

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    htmltaskreport "ProjectBreakdown.html" {
      caption "This is the project breakdown"
      headline "Project Breakdown"
      columns name, start, end, daily
      # Don't hide any resource, meaning show them all.
      hideresource 0
    }

## hidetask <`logicalexpression`>

hidetask <`logicalexpression`>
`Description` | Do not show tasks that match the specified logical expression. If the report is sorted in tree mode (default) then enclosing tasks are listed even if the expression matches the task.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvtaskreport, export, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, icalreport, resourcereport, taskreport, xmlreport,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"
    resource tuxia "Tuxia"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        task phase1 "Phase 1" {
          effort 5d
          allocate tuxia
        }
        task phase2 "Phase 2" {
          effort 2d
          allocate tux
        }
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "Project Breakdown" {
      columns start, end, effort
      # Open only the first level of tasks
      rolluptask treelevel() > 1
    }

    resourcereport "Resource Allocations" {
      columns id, effort
      # We only want to see the tasks with real work (without parents),
      # sorted by name
      sorttasks nameup
      hidetask ~isleaf()
    }

## htmlaccountreport <`file`>

htmlaccountreport <`file`>
`Description` | The report lists all specified account values as a HTML page.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | accumulate, caption, columns, end, headline, hideaccount, period, rawhead, rawstylesheet, rawtail, rollupaccount, scenarios, shorttimeformat, sortaccounts, start, timeformat
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvaccountreport, htmlresourcereport, htmltaskreport

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## htmlmonthlycalendar <`file`>

htmlmonthlycalendar <`file`>
`Description` | Generates a calendar like HTML report with one column for each month.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | accumulate, barlabels, caption, columns, end, headline, hideresource, hidetask, loadunit, period, rawhead, rawstylesheet, rawtail, rollupresource, rolluptask, scenarios, shorttimeformat, showprojectids, sortresources, sorttasks, start, taskroot, timeformat, weekdays
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmlaccountreport, htmlresourcereport, htmltaskreport, htmlstatusreport, htmlweeklycalendar

## htmlresourcereport <`file`>

htmlresourcereport <`file`>
`Description` | The report lists all resources and their respective values as a HTML page. The tasks that the resources are allocated to can be listed as well.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | accumulate, barlabels, caption, columns, end, headline, hideresource, hidetask, loadunit, period, rawhead, rawstylesheet, rawtail, rollupresource, rolluptask, scenarios, shorttimeformat, showprojectids, sortresources, sorttasks, start, taskroot, timeformat
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvresourcereport, htmlaccountreport, htmltaskreport, resourcereport

## htmlstatusreport <`file`>

htmlstatusreport <`file`>
`Description` | Generates a HTML status report. The report consists of 4 tables: Overdue tasks, ongoing tasks, finished tasks and upcoming tasks. The default reporting interval is 1 week.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | scenarios, period, start, end, headline, caption, rawhead, rawstylesheet, rawtail, loadunit, timeformat, shorttimeformat
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmlaccountreport, htmlresourcereport, htmltaskreport, htmlmonthlycalendar, htmlweeklycalendar

## htmltaskreport <`file`>

htmltaskreport <`file`>
`Description` | The report lists all tasks and their respective values as a HTML page. The resources that are allocated to the tasks can be listed as well.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | accumulate, barlabels, caption, columns, end, headline, hideresource, hidetask, loadunit, period, rawhead, rawstylesheet, rawtail, rollupresource, rolluptask, scenarios, shorttimeformat, showprojectids, sortresources, sorttasks, start, taskroot, timeformat
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvtaskreport, htmlaccountreport, htmlresourcereport, taskreport

## htmlweeklycalendar <`file`>

htmlweeklycalendar <`file`>
`Description` | Generates a calendar like HTML report with one row for each week.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | accumulate, barlabels, caption, columns, end, headline, hideresource, hidetask, loadunit, period, rawhead, rawstylesheet, rawtail, resourcereport, rollupresource, rolluptask, scenarios, shorttimeformat, showprojectids, sortresources, sorttasks, start, taskroot, timeformat, weekdays
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlstatusreport

## icalreport <`file`>

icalreport <`file`>
`Description` | Generates an ICal report according to RFC2445. This is standardized format used by many calendar applications such as KOrganizer. The filename should have a `.ics` extension.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | hideresource, hidetask, rollupresource, rolluptask, scenarios
`Context` |
`Inheritable` | No | `Scenario Spec.` | No

    project prj "ICal Export Demo" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"
    resource tuxia "Tuxia"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        task phase1 "Phase 1" {
          effort 5d
          allocate tuxia
        }
        task phase2 "Phase 2" {
          effort 2d
          allocate tux
        }
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    icalreport "Tux-TODO-List.ics" {
      # Only export tasks that tux is assigned to
      hidetask ~isDutyOf(tux, plan)
    }

## include <`file`>

include <`file`>

`Description`

Includes the specified file name as if its contents would be written instead of the include property. The only exception is the `include` statement itself. When the included files contains other include statements or report definitions, the filenames are relative to file where they are defined in. `include` commands can be used in the project header, at global scope or between property declarations of tasks, resources, and accounts.

For technical reasons you have to supply the optional pair of curly brackets if the include is followed immediately by a macro call that is defined within the included file.

`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | taskprefix
`Context` | The TJP File, project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | export

    project yourId "Your Project" "1.0" 2005-04-05 2005-05-01

    task main "Main task" {
    }

    include "Include2.tji" { taskprefix main }

## journalentry <`date`> <`text`>

journalentry <`date`> <`text`>
`Description` | Journal entries are meant for documentation purposes. They consist of a date and a text entry. Each journal entry adds a new entry to the journal of the property.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`text` | STRING |
`Context` | project, resource, task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | note, statusnote

    project journal "Project" "$Id" 2000-01-01 2000-01-04 {
      journalentry 2000-01-02 "The project started."
      journalentry 2000-01-03 "We made some progress."
    }

    resource tux "Tux" {
      journalentry 2000-01-02 "This guy is a bummer."
    }

    task t1 "Task1" {
      journalentry 2000-01-01 "Probably will be done sooner."
      journalentry 2000-01-03 "Maybe not."
      start 2000-01-01
      milestone
    }

    taskreport "Tasks"

## kotrusid <`id`>

kotrusid <`id`>
`Description` | The KoTrus ID of the account (cost object). This is a special reserved keyword.
`Attributes` | `Name` | `Type` | `Description`
`id` | STRING |
`Context` | account, resource,
`Inheritable` | Yes | `Scenario Spec.` | No

## label <`text`>

label <`text`>
`Description` | Specifies the text for the URL in HTML reports. If no label is specified, the URL will be displayed. If a label has been specified, the URL will not be shown.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | reference,
`Inheritable` | No | `Scenario Spec.` | No

    project ca "Custom Attributes" "1.0" 2003-05-28 2003-06-28 {
      extend task {
        reference MyLink "My Link"
        text MyText "My Text" { inherit }
      }
    }

    task t "Task" {
      start 2003-05-28
      milestone
      MyLink "http://www.taskjuggler.org" { label "TJ Web" }
      MyText "TaskJuggler is great!"
    }

## length <`value`> <`unit`>

length <`value`> <`unit`>

`Description`

Specifies the time the task occupies the resources. This is working time, not calendar time. 7d means 7 working days, not one week. Whether a day is considered a working day or not depends on the defined working hours and global vacations. A task with a length specification may have resource allocations. Resources are allocated when they are available. The availability has no impact on the duration of the task. A day where none of the specified resources is available is still considered a working day, if there is no global vacation or global working time defined.

Tasks may not have subtasks if this attribute is used.

`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | duration, effort

    project duration "Duration Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task t "Enclosing" {
      start 2005-06-06
      task durationTask "Duration Task" {
        # This task is 10 calendar days long.
        duration 10d
      }

      task intervalTask "Interval Task" {
        # This task is similar to the durationTask. Instead of a start
        # date and a duration it has a fixed start and end date.
        end 2005-06-17
      }

      task lengthTask "Length Task" {
        # This task 10 working days long. So about 12 calendar days.
        length 10d
      }

      task effortTask "Effort Task" {
        effort 10d
        allocate tux
      }
    }

## limits

limits

`Description`

Specifies limits on the usage of a resource in general, or of the allocation of a resource to a task. This property replaces the less flexible properties maxeffort and load.

When applied to an allocation this limits the use of all alternative resources or group members as a whole. There has been a bug in version 2.0.x that resulted in faulty limit computation. This has been fixed with version 2.1.

`Optional Attributes` | dailymax, weeklymax, monthlymax
`Context` | The TJP File, allocate, resource,
`Inheritable` | Yes | `Scenario Spec.` | No

    project limits "Limits" "1.0" 2004-03-01 2004-05-01

    # Default limit that affects all subsequently defined resources
    limits {
      weeklymax 4d
    }

    resource r1 "R1" {
      # Limit the usage of this resource to a maximum of 2 hours per day,
      # 6 hours per week and 2.5 days per month.
      limits { dailymax 2h weeklymax 6h monthlymax 2.5d }
    }

    resource r2 "R2"

    task t1 "Task 1" {
      start 2004-03-01
      duration 60d
      # allocation is subject to resource limits
      allocate r1
    }

    task t2 "Task 2" {
      start 2004-03-01
      duration 60d
      # limits can also be specified per allocation
      allocate r2 {
        limits { dailymax 4h weeklymax 3d monthlymax 2w }
      }
    }

## load <`factor`>

load <`factor`>

`Description`

This property has been replaced by limits. The further usage of load is strongly discouraged. It will be dropped from future versions of TaskJuggler.

Specifies the daily load of a resource for an allocation. A load of 1.0 (default) means the resource is allocated for as many hours as specified by dailyworkinghours. A load of 0.5 means half that many hours. This only works if enough working hours have been specified for the particular day.

`Attributes` | `Name` | `Type` | `Description`
`factor` | REAL |
`Context` |
`Inheritable` | No | `Scenario Spec.` | No
`See also` | workinghours, vacation

## loadunit <`unit`>

loadunit <`unit`>
`Description` | Specifies the unit in which loads are reported in a report.
`Attributes` | `Name` | `Type` | `Description`
`unit` | ID | See table below for possible values.
`Context` | htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | dailyworkinghours, yearlyworkingdays

- `days`
- Show load in man or resource-days.
- `hours`
- Show load in man resource-hours.
- `longauto`
- Show load in the most appropriate unit and show long unit name.
- `minutes`
- Show load in man or resource-minutes.
- `months`
- Show load in man or resource-months.
- `shortauto`
- Show load in the most appropriate unit and show short unit name.
- `weeks`
- Show load in man or resource-weeks.
- `years`
- Show load in man or resource-years.

## macro <`id`>

macro <`id`>
`Description` | Defines a text fragment that can later be inserted by using the specified ID. See the description of the `include` statement for details on how to use a macro immediately after including the file where the macro has been defined in.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` |

The body is not optional. It must be enclosed in [ ]. Macros can be declared like this:

    macro FOO [ This text ];

If later ${FOO} is found in the project file, it is expanded to ' This text '. Macros may have arguments. Arguments are special macros with numbers as names. The number specifies the index of the argument.

    macro FOO [ This ${1} text ]

will expand to ' This stupid text ' if called as ${FOO "stupid"}. Macros may call other macros.

Macro IDs should have at least one uppercase letter as all lowercase letter IDs may be used in a later version for built-in macros like 'if', 'expr' or 'for'. Macro names can be prefixed by a question mark. In this case the macro will expand to nothing if the macro is not defined. Otherwise the undefined macro would be flagged with an error message.

    This macro call ${?foo} will expand to nothing if foo is undefined.

## mandatory

mandatory
`Description` | Makes a resource allocation mandatory. This means, that for each time slot only then resources are allocated when all mandatory resources are available. So either all mandatory resources can be allocated for the time slot, or no resource will be allocated.
`Context` | allocate,
`Inheritable` | No | `Scenario Spec.` | No

    project prj "Project" "1.0" 2000-01-01 2000-03-01

    resource tuxus "Tuxus"
    resource truck "Truck" {
      # Truck does not do any work!
      efficiency 0.0
    }

    task t "Ship stones to customers" {
      start 2000-01-01
      effort 5d
      # We need the truck to deliver the stones, so only allocate
      # tuxus when the truck is available.
      allocate tuxus
      allocate truck { mandatory }
    }

## maxeffort <`workingdays`>

maxeffort <`workingdays`>
`Description` | This property has been replaced by limits. The further usage of maxeffort is strongly discouraged. It will be dropped from future versions of TaskJuggler. The daily maximum effort for a resource. Resources will not be scheduled to be used more than this value. A value of 1.0 means a full working day. 0.5 means half a working day.
`Attributes` | `Name` | `Type` | `Description`
`workingdays` | REAL |
`Context` | The TJP File, resource,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | dailyworkinghours, workinghours

## maxend <`date`>

maxend <`date`>
`Description` | Specifies the maximum wanted end time of the task. The value is not used during scheduling, but is checked after all tasks have been scheduled. If the end of the task is later than the specified value, then an error is reported.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | maxstart, minend, minstart

    project minmax "Min Max Example" "1.0" 2005-06-06 2005-06-26

    task items "Project breakdown" {
      start 2005-06-07

      task plan "Plan work" {
    		note "Some more information about this task."
        # Set acceptable interval for task start
        minstart 2005-06-06
        maxstart 2005-06-08
        length 3d
        # Set acceptable interval for task end
        minend 2005-06-09
        maxend 2005-06-11
      }
    }

## maxstart <`date`>

maxstart <`date`>
`Description` | Specifies the maximum wanted start time of the task. The value is not used during scheduling, but is checked after all tasks have been scheduled. If the start of the task is later than the specified value, then an error is reported.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | maxend, minend, minstart

    project minmax "Min Max Example" "1.0" 2005-06-06 2005-06-26

    task items "Project breakdown" {
      start 2005-06-07

      task plan "Plan work" {
    		note "Some more information about this task."
        # Set acceptable interval for task start
        minstart 2005-06-06
        maxstart 2005-06-08
        length 3d
        # Set acceptable interval for task end
        minend 2005-06-09
        maxend 2005-06-11
      }
    }

## minend <`date`>

minend <`date`>
`Description` | Specifies the minimum wanted end time of the task. The value is not used during scheduling, but is checked after all tasks have been scheduled. If the end of the task is earlier than the specified value, then an error is reported.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | maxend, maxstart, minstart

    project minmax "Min Max Example" "1.0" 2005-06-06 2005-06-26

    task items "Project breakdown" {
      start 2005-06-07

      task plan "Plan work" {
    		note "Some more information about this task."
        # Set acceptable interval for task start
        minstart 2005-06-06
        maxstart 2005-06-08
        length 3d
        # Set acceptable interval for task end
        minend 2005-06-09
        maxend 2005-06-11
      }
    }

## minslackrate <`rate`>

minslackrate <`rate`>
`Description` | Specifies the minimum percentage of slack a task path can have before it is marked as critical. A path is any list of explicitely or implicitely connected tasks measured from first task to last task. The slack is the time between start of the first task and end of the last task that is not covered by any task of the path. The default value is 10%.
`Attributes` | `Name` | `Type` | `Description`
`rate` | REAL |
`Context` | scenario,
`Inheritable` | Yes | `Scenario Spec.` | Yes

    project prj "Critical Path Example" "1.0" 2006-08-22 +1m {
      scenario plan "Planned Scenario" {
        # All pathes with less than 15% slack should be marked as
        # critical.
        minslackrate 15.0
      }
    }

    task t1 "Task 1" {
      start 2006-08-22
      duration 2d
    }

    task t2 "Task 2" {
      depends t1 { gaplength 2d }
      duration 3d
    }

    task t3 "Task 3" {
      depends t1 { gaplength 1d }
      duration 4d
    }

    taskreport "Tasks" {
      columns no, name, chart
    }

    htmltaskreport "CriticalTasks.html" {
      # Generate a list of all tasks that are on a critical path.
      hidetask ~isOnCriticalPath(plan)
    }

## minstart <`date`>

minstart <`date`>
`Description` | Specifies the minimum wanted start time of the task. The value is not used during scheduling, but is checked after all tasks have been scheduled. If the start of the task is earlier than the specified value, then an error is reported.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | maxend, maxstart, minend

    project minmax "Min Max Example" "1.0" 2005-06-06 2005-06-26

    task items "Project breakdown" {
      start 2005-06-07

      task plan "Plan work" {
    		note "Some more information about this task."
        # Set acceptable interval for task start
        minstart 2005-06-06
        maxstart 2005-06-08
        length 3d
        # Set acceptable interval for task end
        minend 2005-06-09
        maxend 2005-06-11
      }
    }

## milestone

milestone
`Description` | Turns the task into a special task that has no duration. You may not specify a duration, length, effort or subtasks for a milestone task. A task that only has a start or an end specification and no duration specification or sub tasks, will be recognized as milestone automatically.
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | No

    project prj "Milestone demo" "1.0" 2005-07-15 2005-08-01

    task project_start "Project Start" {
      start 2005-07-15
      milestone
    }

    task deadline "Important Deadline" {
      start 2005-07-20
      # A task with only a start or end date and no duration specification
      # is automatically assumed to be a milestone.
    }

## note <`text`>

note <`text`>
`Description` | Attach a note to the task. This is usually a more detailed specification of what the task is about.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | journalentry, statusnote

    project minmax "Min Max Example" "1.0" 2005-06-06 2005-06-26

    task items "Project breakdown" {
      start 2005-06-07

      task plan "Plan work" {
    		note "Some more information about this task."
        # Set acceptable interval for task start
        minstart 2005-06-06
        maxstart 2005-06-08
        length 3d
        # Set acceptable interval for task end
        minend 2005-06-09
        maxend 2005-06-11
      }
    }

## monthlymax <`value`> <`unit`>

monthlymax <`value`> <`unit`>
`Description` | Sets the monthly limit of a resource usage or a resource allocation to a task.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | limits,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | dailymax, weeklymax

    project limits "Limits" "1.0" 2004-03-01 2004-05-01

    # Default limit that affects all subsequently defined resources
    limits {
      weeklymax 4d
    }

    resource r1 "R1" {
      # Limit the usage of this resource to a maximum of 2 hours per day,
      # 6 hours per week and 2.5 days per month.
      limits { dailymax 2h weeklymax 6h monthlymax 2.5d }
    }

    resource r2 "R2"

    task t1 "Task 1" {
      start 2004-03-01
      duration 60d
      # allocation is subject to resource limits
      allocate r1
    }

    task t2 "Task 2" {
      start 2004-03-01
      duration 60d
      # limits can also be specified per allocation
      allocate r2 {
        limits { dailymax 4h weeklymax 3d monthlymax 2w }
      }
    }

## now <`date`>

now <`date`>
`Description` | Specify the date that TaskJuggler uses for calculation as current date. If no value is specified, the current value of the system clock is used.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | project,
`Inheritable` | Yes | `Scenario Spec.` | No

    project simple "Some task" "1.0" 2005-06-06 2005-06-26 {
      now 2005-06-15
    }

    resource tux "Tux"

    task t "Task" {
      start 2005-06-06
      effort 10d
      allocate tux
      # This task should have be be completed much more on Jun 15, but
      # it's only 20% done.
      complete 20
    }

## numberformat <`negativeprefix`> <`negativesuffix`> <`thousandseparator`> <`fractionseparator`> <`fractiondigits`>

numberformat <`negativeprefix`> <`negativesuffix`> <`thousandseparator`> <`fractionseparator`> <`fractiondigits`>

`Description`

These values specify the default format used for all numerical real values. The `negativeprefix` and `negativesuffix` strings enclose negative currency values. The `thousandseparator` can be used to make large numbers more readable. The `fractionseparator` separates the fractional part from the rest. `fractiondigits` specifies how many fractional digits should be shown at a maximum.

`Attributes` | `Name` | `Type` | `Description`
`negativeprefix` | STRING |
`negativesuffix` | STRING |
`thousandseparator` | STRING |
`fractionseparator` | STRING |
`fractiondigits` | INTEGER |
`Context` | project,
`Inheritable` | Yes | `Scenario Spec.` | No

    project prj "Project" "1.0" 2000-01-01 2000-03-01 {
      # German number format: e. g.  -10000,20 5014,11
      numberformat "-" "" "" "," 2

      # US currency format: e. g. (10,000.20) 5,014.11
      currencyformat "(" ")" "," "." 2
    }

    task t "Task" {
      start 2000-01-01
      milestone
    }

## overtime <`value`>

overtime <`value`>
`Description` | This attribute enables bookings to override working hours and vacations.
`Attributes` | `Name` | `Type` | `Description`
`value` | INTEGER | Number between 0 and 2. See table below.
`Context` | booking,
`Inheritable` | No | `Scenario Spec.` | No

- `overtime 0:`
- You can only book available working hours. (Default)
- `overtime 1:`
- You can book off-hours as well.
- `overtime 2:`
- You can book normal working hours, off-hours and vacations.

    project prj "Project" "1.0" 2003-06-05 +1m {
      # The baseline date for the projection.
      now 2003-06-15
      scenario plan "Plan" {
        # Compute when the task will be ready based on the already done
        # work and the current date.
        projection { strict }
      }
    }

    resource r1 "Resource 1"

    task t1 "Task 1" {
      start 2003-06-05
      effort 10d
      allocate r1
    }

    supplement resource r1 {
      # This is the work that has been done up until now by r1.
      booking t1 2003-06-06 +8h { sloppy 2 }
      booking t1 2003-06-08 +4h,
                 2003-06-09 +4h { sloppy 2 }
      # Book interval that extends into off-hours.
      booking t1 2003-06-11-8:00 +10h { overtime 1 }
    }

## period

period
`Description` | This property is a shortcut for setting the start and end property at the same time. In contrast to using these, it does not change the scheduling direction.
`Context` | task,
`Inheritable` | yes | `Scenario Spec.` | No
`See also` | end, start

    project prj "Period Project" "1.0" 2006-09-24 +3m {
    	now 2006-10-02
    }

    task items "Project breakdown" {
      start ${projectstart}

      task plan "Plan work" {
        period 2006-10-01 +2w
      }
    }

    taskreport "My Tasks" {
    	period ${now} +1w
    }

## period

period
`Description` | This property is a shortcut for setting the start and end propoerty at the same time.
`Context` | csvaccountreport, csvresourcereport, csvtaskreport, export, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | no | `Scenario Spec.` | No
`See also` | end, start

    project prj "Period Project" "1.0" 2006-09-24 +3m {
    	now 2006-10-02
    }

    task items "Project breakdown" {
      start ${projectstart}

      task plan "Plan work" {
        period 2006-10-01 +2w
      }
    }

    taskreport "My Tasks" {
    	period ${now} +1w
    }

## persistent

persistent
`Description` | Specifies that once a resource is picked from the list of alternatives this resource is used for the whole task. This is useful when several alternative resources have been specified. Normally the selected resource can change after each break. A break is an interval of at least one timeslot where no resources were available.
`Context` | allocate,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | alternative

    project prj "Project" "1.0" 2003-06-05 2003-07-05

    resource r1 "Resource 1"
    resource r2 "Resource 2"

    task t1 "Task 1" {
      start 2003-06-05
      effort 5d
      # Pick one of them and use it for the entire task
      allocate r1 { alternative r2 persistent }
    }

## priority <`value`>

priority <`value`>

`Description`

Specifies a priority between 1 and 1000. A task with higher priority is more likely to get the requested resources. Don't confuse the priority of a tasks with the importance or urgency of a task. It only increases the chances that the tasks gets the requested resources. It does not mean that the task happens earlier, though that is usually the effect you will see. It also does not have any effect on tasks that don't have any resources assigned (e.g. milestones).

This attribute is inherited by subtasks if specified prior to the definition of the subtask.

`Attributes` | `Name` | `Type` | `Description`
`value` | INTEGER |
`Context` | The TJP File, task,
`Inheritable` | No | `Scenario Spec.` | No

    project prj "Priority Demo" "1.0" 2005-07-15 2005-10-01

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-07-15

      task coolStuff "Do some cool stuff" {
        start 2005-08-01
        effort 10d
        priority 800
        allocate tux
      }

      task otherStuff "Other not so important stuff" {
        start 2005-08-01
        effort 20d
        priority 500
        allocate tux
      }

      task maintenance "Maintenance work" {
        # This is a fallback task. Whenever tux is not doing something
        # else he is allocated to this task.
        duration 2m
        priority 300
        allocate tux
      }
    }

## precedes <`task`> [, <`task`> ... ]

precedes <`task`> [, <`task`> ... ]

`Description`

Specifies that the tasks with the specified IDs cannot start before the task has been finished. If multiple IDs are specified, they must be separated by commas. IDs must be either global or relative. A relative ID starts with a number of '!'. Each '!' moves the scope to the parent task. Global IDs do not contain '!', but have IDs separated by dots.

By using the 'precedes' attribute, the scheduling policy is automatically set to `alap`. If both `depends` and `precedes` are used within a task, the last policy counts.

`Attributes` | `Name` | `Type` | `Description`
`task` | ID |
`Optional Attributes` | gapduration, gaplength
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | depends, scheduling

    project p "P" "1.0" 2003-11-09 2003-12-24

    task foo1 "foo1" {
      task foo2 "foo2" {
        start 2003-12-04
        milestone
      }
      task foo3 "foo3" {
        precedes !foo2
        length 1d
      }
    }
    task bar "bar" {
      precedes foo1.foo2
      length 2d
    }

## project <`id`> <`name`> <`version`> <`period`>

project <`id`> <`name`> <`version`> <`period`>

`Description`

The project property is mandatory and should be the first property in a project file. <id> is the default project ID used to register resource allocations in a global database. <name> is the name of the project. <version> is the version of the project file. Typically this is the CVS ID. <start> and <end> define the time frame of the project. The end may be well after the end of the last task, but must be specified to terminate the scheduling process.

`Attributes` | `Name` | `Type` | `Description`
`id` | ID | The default project ID.
`name` | STRING | The name of the project.
`version` | STRING | The version of the project file. This could be a revision number from a revision control system.
`period` | DATEINTERVAL | The expected interval of the project. It may be larger than necessary, but it needs to be large enough to fit all tasks.
`Optional Attributes` | allowredefinition, currencyformat, currency, dailyworkinghours, extend, include, journalentry, now, numberformat, scenario, shorttimeformat, timeformat, timezone, timingresolution, weekstartsmonday, weekstartssunday, workinghours, yearlyworkingdays
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "My Tasks"

## projectid <`id`>

projectid <`id`>
`Description` | At global scope it declares a new project id and activates it. All subsequent task definitions will inherit this ID. If used within a task it simply assigns this project ID to the task. The tasks of a project can have different IDs. This is particularly helpful if the project is merged from several sub projects that each have their own ID.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`Context` | The TJP File, task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | project, projectids

    project mainID "ProjectIDs example" "1.0" 2006-08-22 +1m

    task t1 "Task 1" {
      start 2006-08-22
    	# This task has project ID "mainID"
    }

    projectid prj1
    projectids prj2

    task t2 "Task 2" {
      start 2006-08-22
    	# This task has now project ID "prj1"
    }

    task t3 "Task 3" {
      start 2006-08-22
      projectid prj2
    	# This task has now project ID "prj2"
    }

## projectids <`projectid`> [, <`projectid`> ... ]

projectids <`projectid`> [, <`projectid`> ... ]
`Description` | Declares a list of project IDs.
`Attributes` | `Name` | `Type` | `Description`
`projectid` | ID |
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | project, projectid

    project mainID "ProjectIDs example" "1.0" 2006-08-22 +1m

    task t1 "Task 1" {
      start 2006-08-22
    	# This task has project ID "mainID"
    }

    projectid prj1
    projectids prj2

    task t2 "Task 2" {
      start 2006-08-22
    	# This task has now project ID "prj1"
    }

    task t3 "Task 3" {
      start 2006-08-22
      projectid prj2
    	# This task has now project ID "prj2"
    }

## projection

projection

`Description`

Enables the projection mode for the scenario. All tasks will be scheduled taking the manual bookings into account. The tasks will be extended by scheduling new bookings starting with the current date until the specified effort, length or duration has been reached. In sloppy mode tasks with no bookings will be filled from the original start. In strict mode all tasks will be filled starting with the current date. No bookings will be added prior to the current date.

`Optional Attributes` | sloppy, strict
`Context` | scenario,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | baseline, booking

    project prj "Project" "1.0" 2003-06-05 +1m {
      # The baseline date for the projection.
      now 2003-06-15
      scenario plan "Plan" {
        # Compute when the task will be ready based on the already done
        # work and the current date.
        projection { strict }
      }
    }

    resource r1 "Resource 1"

    task t1 "Task 1" {
      start 2003-06-05
      effort 10d
      allocate r1
    }

    supplement resource r1 {
      # This is the work that has been done up until now by r1.
      booking t1 2003-06-06 +8h { sloppy 2 }
      booking t1 2003-06-08 +4h,
                 2003-06-09 +4h { sloppy 2 }
      # Book interval that extends into off-hours.
      booking t1 2003-06-11-8:00 +10h { overtime 1 }
    }

## properties <`property`> [, <`property`> ... ]

properties <`property`> [, <`property`> ... ]
`Description` | This attribute determines which properties will be included in the report.
`Attributes` | `Name` | `Type` | `Description`
`property` | ID | See table below for possible values.
`Context` | export,
`Inheritable` | No | `Scenario Spec.` | No

- `all`
- Include all properties.
- `bookings`
- Include all bookings for the report interval. Only bookings for non-filtered resources will be included.
- `shifts`
- Include all shift definitions.
- `tasks`
- Include all task definitions for non-filtered tasks.
- `resources`
- Include all resource definitions for non-filtered resources.

    project prj  "Project" "1.0" 2000-01-01 2000-03-01

    resource r "Resource"

    task t "Task" {
      start 2000-01-01
      effort 10d
      allocate r
    }

    # Export the project as fully scheduled project.
    export "FullProject.tjp" {
      taskattributes all
      hideresource 0
    }

    # Export only bookings for 1st week as resource supplements
    export "Week1Bookings.tji" {
      start 2000-01-01
      end 2000-01-08
      properties bookings
      hideresource 0
    }

## purge <`attributeName`>

purge <`attributeName`>
`Description` | This attribute can be used to purge inherited flags or allocations. Possible values for `attributeName` are `allocations` or `flags`.
`Attributes` | `Name` | `Type` | `Description`
`attributeName` | ID |
`Context` | allocate, task,
`Inheritable` | No | `Scenario Spec.` | No

## rate <`value`>

rate <`value`>
`Description` | Specifies the daily costs of the resource. The amount are credited to the account specified with the task that makes use of the resource.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`Context` | The TJP File, resource,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | account, task

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## rawhead <`html`>

rawhead <`html`>
`Description` | Specifies a section of raw HTML code that will be inserted at the top of the report.
`Attributes` | `Name` | `Type` | `Description`
`html` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | rawstylesheet, rawtail

## rawstylesheet <`stylesheet`>

rawstylesheet <`stylesheet`>
`Description` | Specifies a stylesheet for HTML reports.
`Attributes` | `Name` | `Type` | `Description`
`stylesheet` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No

## rawtail <`html`>

rawtail <`html`>
`Description` | Specifies a section of raw HTML code that will be inserted at the bottom of the report.
`Attributes` | `Name` | `Type` | `Description`
`html` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | rawhead, rawstylesheet

## reference <`url`>

reference <`url`>
`Description` | A reference to an external document. If you need more than one reference, you can create your own URL placeholders.
`Attributes` | `Name` | `Type` | `Description`
`url` | STRING | Should be a well formed URL.
`Optional Attributes` | label
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | extend

    project ca "Custom Attributes" "1.0" 2003-05-28 2003-06-28 {
      extend task {
        reference MyLink "My Link"
        text MyText "My Text" { inherit }
      }
    }

    task t "Task" {
      start 2003-05-28
      milestone
      MyLink "http://www.taskjuggler.org" { label "TJ Web" }
      MyText "TaskJuggler is great!"
    }

## resource <`id`> <`name`>

resource <`id`> <`name`>
`Description` | Task use resources to fulfil the specified efforts.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`name` | STRING |
`Optional Attributes` | booking, efficiency, flags, journalentry, kotrusid, maxeffort, limits, rate, `resource`, shift, vacation, workinghours
`Context` | The TJP File, `resource`,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | task

    project resources "Resource Examples" "1.0" 2005-06-06 2005-06-26

    # A simple resource
    resource tux1 "Tux1"

    # A team
    resource team "A team" {
      # A 2 days of team vacation
      vacation 2005-06-07 - 2006-05-09
      resource tux2 "Tux2"
      resource tux3 "Tux3" {
        # And one extra day
        vacation 2005-06-10
      }
    }

    task t "An important date" {
      start 2005-06-10
    }

## resourcereport <`file`>

resourcereport <`file`>
`Description` | This report is intended for the TaskJuggler graphical user interface. The report lists all tasks and their respective values as a HTML page. The resources that are allocated to the tasks can be listed as well.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | caption, columns, end, headline, hideresource, hidetask, loadunit, period, rollupresource, rolluptask, scenario, shorttimeformat, showprojectids, sortresources, sorttasks, start, timeformat
`Context` |
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvtaskreport, htmlaccountreport, htmlresourcereport, taskreport

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"
    resource tuxia "Tuxia"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        task phase1 "Phase 1" {
          effort 5d
          allocate tuxia
        }
        task phase2 "Phase 2" {
          effort 2d
          allocate tux
        }
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "Project Breakdown" {
      columns start, end, effort
      # Open only the first level of tasks
      rolluptask treelevel() > 1
    }

    resourcereport "Resource Allocations" {
      columns id, effort
      # We only want to see the tasks with real work (without parents),
      # sorted by name
      sorttasks nameup
      hidetask ~isleaf()
    }

## resourcereport

resourcereport
`Description` | This attribute switches a calendar report from task report mode to resource report mode.
`Context` | htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No

## responsible <`resource`>

responsible <`resource`>
`Description` | The ID of the resource that is responsible for this task. This value is for documentation purposes only. It's not used by the scheduler.
`Attributes` | `Name` | `Type` | `Description`
`resource` | ID |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | resource

    project prj "Responsible Demo" "1.0" 2005-07-15 2005-08-01

    resource tux "Tux"
    resource ubertux "Uber Tux"

    task someJob "Some Job" {
      start 2005-07-15
      effort 1w
      allocate tux
      responsible ubertux
    }

    taskreport "Job List" {
      columns effort, resources, responsible
    }

## rollupaccount <`logicalexpression`>

rollupaccount <`logicalexpression`>
`Description` | Do not show sub-accounts of accounts that match the specified logical expression.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvaccountreport, htmlaccountreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | rollupresource, rolluptask

## rollupresource <`logicalexpression`>

rollupresource <`logicalexpression`>
`Description` | Do not show sub-resources of resources that match the specified logical expression.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvresourcereport, export, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, icalreport, resourcereport, taskreport, xmlreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | rollupaccount, rolluptask

## rolluptask <`logicalexpression`>

rolluptask <`logicalexpression`>
`Description` | Do not show sub-tasks of tasks that match the specified logical expression.
`Attributes` | `Name` | `Type` | `Description`
`logicalexpression` | LOGICALEXPRESSION |
`Context` | csvtaskreport, export, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, icalreport, resourcereport, taskreport, xmlreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | rollupaccount, rollupresource

## scenario <`id`> <`name`>

scenario <`id`> <`name`>
`Description` | Specifies the different project scenarios. A scenario that is nested into another one inherits all inheritable values from the enclosing scenario. There can only be one top-level scenario. It is usually called `plan` scenario. By default this scenario is pre-defined but can be overwritten with any other scenario.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`name` | STRING |
`Optional Attributes` | baseline, disabled, minslackrate, projection, `scenario`
`Context` | project, `scenario`,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | scenarios

    project prj "Example" "1.0" 2005-05-29 2005-07-01 {
      scenario plan "Planned Scenario" {
        scenario actual "Actual Scenario"
        scenario test "Test Scenario" {
          disabled
        }
      }
    }

    task t "Task" {
      start 2005-05-29
      actual:start 2005-06-03
      test:start 2005-06-07
    }

## scenario <`scenarioid`>

scenario <`scenarioid`>
`Description` | ID of the scenario that should be included in the report.
`Attributes` | `Name` | `Type` | `Description`
`scenarioid` | ID | The ID of the scenario.
`Context` | resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | scenario

## scenarios <`scenarioid`> [, <`scenarioid`> ... ]

scenarios <`scenarioid`> [, <`scenarioid`> ... ]
`Description` | List of scenarios that should be included in the report.
`Attributes` | `Name` | `Type` | `Description`
`scenarioid` | ID | The ID of the scenario.
`Context` | export, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, icalreport, xmlreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | scenario

## scheduled

scheduled
`Description` | This is mostly for internal use. It specifies that the task can be ignored for scheduling in the scenario.
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes

## scheduling <`type`>

scheduling <`type`>

`Description`

Specifies the scheduling policy for the task. A task can be scheduled from start to end (As Soon As Possible, `asap`) or from end to start (As Late As Possible, `alap`).

A task can be scheduled from start to end (ASAP mode) when it has a hard (start) or soft (depends) criteria for the start time. A task can be scheduled from end to start (ALAP mode) when it has a hard (end) or soft (precedes) criteria for the end time.

Some task attributes set the scheduling policy implicitly. This attribute can be used to explicitly set the scheduling policy of the task to a certain direction. To avoid it being overwritten again by an implicit attribute this attribute should always be the last attribute of the task.

A random mixture of ASAP and ALAP tasks can have unexpected side effects on the scheduling of the project. It increases significantly the scheduling complexity and results in much longer scheduling times. Especially in projects with many hundreds of tasks the scheduling time of a project with a mixture of ASAP and ALAP times can be 2 to 10 times longer. When the projects contains chains of ALAP and ASAP tasks the tasks further down the dependency chain will be served much later than other non-chained task even when they have a much higher priority. This can result in situations where high priority tasks do not get their resources even though the parallel competing tasks have a much lower priority.

As a general rule, try to avoid ALAP tasks whenever possible. Have a close eye on tasks that have been switched implicitly to ALAP mode because the `end` attribute comes after the `start` attribute.

`Attributes` | `Name` | `Type` | `Description`
`type` | ID | Possible values are `alap` or `asap`.
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | depends, end, precedes, start, period

    project prj "Scheduling Example" "1.0" 2005-07-23 2005-09-01

    task items "Project breakdown" {
      task t1 "Task 1" {
        start 2005-07-25
        end 2005-08-01
        # Implicite ALAP task
      }
      task t2 "Task 2" {
        end 2005-08-01
        start 2005-07-25
        # Implicite ASAP task
      }
      task t3 "Task 3" {
        start 2005-07-25
        end 2005-08-01
        scheduling asap
        # Explicite ASAP task
      }
      task t4 "Task 4" {
        end 2005-08-01
        start 2005-07-25
        scheduling alap
        # Explicite ALAP task
      }
    }

## separator <`sep`>

separator <`sep`>
`Description` | Specifies the separator used in CSV reports between the values. The default value is a semicolon.
`Attributes` | `Name` | `Type` | `Description`
`sep` | STRING |
`Context` | csvaccountreport, csvresourcereport, csvtaskreport,
`Inheritable` | No | `Scenario Spec.` | No

## select <`mode`>

select <`mode`>
`Description` | The select functions controls which resource is picked from an allocation and it's alternatives. The selection is re-evaluated each time the resource used in the previous time slot becomes unavailable. Even for non-persistent allocations a change in the resource selection only happens if the resource used in the previous (or next for ASAP tasks) time slot has become unavailable.
`Attributes` | `Name` | `Type` | `Description`
`mode` | ID | See table below for possible values.
`Context` | allocate,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | persistent

- `maxloaded`
- Pick the available resource that has been used the most so far.
- `minloaded`
- Pick the available resource that has been used the least so far.
- `minallocated`
- Pick the resource that has the smallest allocation factor. The allocation factor is calculated from the various allocations of the resource across the tasks. This is the default setting.
- `order`
- Pick the first available resource from the list.
- `random`
- Pick a random resource from the list.

    project prj "Project" "1.0" 2000-01-01 2000-03-01

    resource tuxus "Tuxus"
    resource tuxia "Tuxia"

    task t1 "Task 1" {
      start 2000-01-01
      effort 5d
      # First try to allocate Tuxus. When he is not available try Tuxia.
      allocate tuxus { alternative tuxia select order }
    }

    task t2 "Task 2" {
      start 2000-01-01
      effort 5d
      # Use tuxux or tuxia, whoever is available and try to balance
      # the allocated load.
      allocate tuxus { alternative tuxia select minloaded}
    }

    task t3 "Task 3" {
      start 2000-01-01
      effort 5d
      # For slave drivers: Always pick the resource that has been loaded
      # the most already.
      allocate tuxus { alternative tuxia select maxloaded}
    }

## shift <`id`> <`name`>

shift <`id`> <`name`>
`Description` | When several resource have the same working hours, these working hours should be defined as shifts. Each shift must have a unique ID. Resources can be assigned to shifts for certain intervals. Shifts can also be used to limit work on certain tasks to the hours of the shift or to switch part time schedules of a resource.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`name` | STRING |
`Optional Attributes` | `shift`, workinghours
`Context` | The TJP File, `shift`,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | shift

    project prj "Example" "1.0" 2000-01-01 2000-03-31

    shift s1 "Shift1" {
      # Special working hours Monday to Wednesday. Use program defaults
      # for other days.
      workinghours mon 10:00 - 12:00, 13:00-15:00
      workinghours tue 9:00-14:00
      workinghours wed off

      shift s2 "Shift2" {
        # Like s1 but with different times on Monday
        workinghours mon 10:00 - 17:00
      }
    }

    resource r1 "Resource1" {
      shift s1 2000-01-01 - 2000-01-10
      shift s2 2000-01-11 - 2000-01-20
    }

    shift s3 "Part-time schedule 1" {
      # The resource works on mondays, wednesdays and fridays.
      # The days that the resource doesn't work must be mentioned
      # explicitely otherwise the defaults values are used (usually
      # full-time employment).
      workinghours mon,fri 9:00 - 12:00, 13:00-18:00
      workinghours wed 9:00 - 12:00
      workinghours tue, thu off
    }

    shift s4 "Part-time schedule 2" {
      # The resource changes his schedule to work on tuesday and
      # thursdays. The days that the resource doesn't work must be
      # mentioned explicitely, otherwise the default values are used
      # (usually full-time employment).
      workinghours tue, thu 9:00 - 12:00, 13:00-18:00
      workinghours mon, wed, fri off
    }

    # Now determine when these schedules are applicable
    resource r2 "Resource2" {
      # r2 works three days a week from January to June
      shift s3 2005-01-01 - 2005-01-15
      # r2 switches to two days a week
      shift s4 2005-01-15 - 2006-01-01
    }

    task t1 "Task1" {
      start 2000-01-01
      length 200h
      # During the specified interval only work at the shift s2 working
      # hours.
      shift s2 2000-01-09 - 2000-01-17
    }

## shift <`shiftid`> [ <`dateinterval`> ]

shift <`shiftid`> [ <`dateinterval`> ]
`Description` | Limits the resource working time or work on a task to a defined shift during the specified interval. Multiple shifts can be defined, but shift intervals may not overlap.
`Attributes` | `Name` | `Type` | `Description`
`shiftid` | ID | The ID of the selected shift.
`dateinterval` | DATEINTERVAL | If an interval is specified, no allocations will be made outside the shift intervals unless other shifts have been selected for other time intervals. If the interval is omitted, the shift is assigned for the whole project time frame.
`Context` | allocate, resource, task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | shift

    project prj "Example" "1.0" 2000-01-01 2000-03-31

    shift s1 "Shift1" {
      # Special working hours Monday to Wednesday. Use program defaults
      # for other days.
      workinghours mon 10:00 - 12:00, 13:00-15:00
      workinghours tue 9:00-14:00
      workinghours wed off

      shift s2 "Shift2" {
        # Like s1 but with different times on Monday
        workinghours mon 10:00 - 17:00
      }
    }

    resource r1 "Resource1" {
      shift s1 2000-01-01 - 2000-01-10
      shift s2 2000-01-11 - 2000-01-20
    }

    shift s3 "Part-time schedule 1" {
      # The resource works on mondays, wednesdays and fridays.
      # The days that the resource doesn't work must be mentioned
      # explicitely otherwise the defaults values are used (usually
      # full-time employment).
      workinghours mon,fri 9:00 - 12:00, 13:00-18:00
      workinghours wed 9:00 - 12:00
      workinghours tue, thu off
    }

    shift s4 "Part-time schedule 2" {
      # The resource changes his schedule to work on tuesday and
      # thursdays. The days that the resource doesn't work must be
      # mentioned explicitely, otherwise the default values are used
      # (usually full-time employment).
      workinghours tue, thu 9:00 - 12:00, 13:00-18:00
      workinghours mon, wed, fri off
    }

    # Now determine when these schedules are applicable
    resource r2 "Resource2" {
      # r2 works three days a week from January to June
      shift s3 2005-01-01 - 2005-01-15
      # r2 switches to two days a week
      shift s4 2005-01-15 - 2006-01-01
    }

    task t1 "Task1" {
      start 2000-01-01
      length 200h
      # During the specified interval only work at the shift s2 working
      # hours.
      shift s2 2000-01-09 - 2000-01-17
    }

## shorttimeformat <`format`>

shorttimeformat <`format`>
`Description` | Specifies time format for time short specifications. This is normal just the hour and minutes.
`Attributes` | `Name` | `Type` | `Description`
`format` | STRING |
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, project, resourcereport, taskreport,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | timeformat

## showprojectids

showprojectids
`Description` | Specifies that calendar columns in reports should contain the project ID after the load value.
`Context` | htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | barlabels, columns

## sloppy <`value`>

sloppy <`value`>
`Description` | Controls how strict TaskJuggler checks booking intervals for conflicts with vacation and other bookings. In case the error is suppressed the booking will not overwrite the existing bookings. It will avoid the already assigned intervals during booking.
`Attributes` | `Name` | `Type` | `Description`
`value` | INTEGER | Number between 0 and 3. See table below.
`Context` | booking,
`Inheritable` | No | `Scenario Spec.` | No

- `sloppy 0:`
- Period may not contain any off-duty hours, vacation or other task assignments. (Default)
- `sloppy 1:`
- Period may contain off-duty hours, but not vacation or other task assignments.
- `sloppy 2:`
- Period may contain off-duty hours and vacation, but no other task assignments.
- `sloppy 3:`
- Period may overlap with off-duty hours, vacation or other task assignments. These are silently skipped.

    project prj "Project" "1.0" 2003-06-05 +1m {
      # The baseline date for the projection.
      now 2003-06-15
      scenario plan "Plan" {
        # Compute when the task will be ready based on the already done
        # work and the current date.
        projection { strict }
      }
    }

    resource r1 "Resource 1"

    task t1 "Task 1" {
      start 2003-06-05
      effort 10d
      allocate r1
    }

    supplement resource r1 {
      # This is the work that has been done up until now by r1.
      booking t1 2003-06-06 +8h { sloppy 2 }
      booking t1 2003-06-08 +4h,
                 2003-06-09 +4h { sloppy 2 }
      # Book interval that extends into off-hours.
      booking t1 2003-06-11-8:00 +10h { overtime 1 }
    }

## sloppy

sloppy
`Description` | Puts the scenario in sloppy bookings mode. This is the default. This mode makes only sense when you also use projection mode for this scenario. In sloppy mode all task that don't have any bookings provided will be filled with bookings according to the original schedule. In strict mode, no bookings will be filled in for any task prior to the current (or now) date.
`Context` | projection,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | booking, projection, strict

## sortaccounts <`criteria`> [, <`criteria`> ... ]

sortaccounts <`criteria`> [, <`criteria`> ... ]
`Description` | Determines how the accounts are sorted in the report. Up to 3 criteria can be specified. If one criteria is not sufficient to sort a group of accounts, the next criteria will be used to sort the accounts within this group.
`Attributes` | `Name` | `Type` | `Description`
`criteria` | SORTINGCRITERIA | Possible values are fullnamedown, fullnameup, iddown, idup, indexdown, indexup, namedown, nameup, sequencedown, sequenceup, tree
`Context` | csvaccountreport, htmlaccountreport,
`Inheritable` | No | `Scenario Spec.` | No

## sortresources <`criteria`> [, <`criteria`> ... ]

sortresources <`criteria`> [, <`criteria`> ... ]
`Description` | Determines how the resources are sorted in the report. Up to 3 criteria can be specified. If one criteria is not sufficient to sort a group of accounts, the next criteria will be used to sort the accounts within this group.
`Attributes` | `Name` | `Type` | `Description`
`criteria` | SORTINGCRITERIA | Possible values are fullnamedown, fullnameup, iddown, idup, indexdown, indexup, maxeffortdown, maxeffortup, mineffortdown, mineffortup, namedown, nameup, ratedown, rateup, sequencedown, sequenceup, tree
`Context` | csvresourcereport, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No

## sorttasks <`criteria`> [, <`criteria`> ... ]

sorttasks <`criteria`> [, <`criteria`> ... ]
`Description` | Determines how the tasks are sorted in the report. Up to 3 criteria can be specified. If one criteria is not sufficient to sort a group of accounts, the next criteria will be used to sort the accounts within this group.
`Attributes` | `Name` | `Type` | `Description`

`criteria`

SORTINGCRITERIA

Possible values are fullnamedown, fullnameup, iddown, idup, indexdown, indexup, namedown, nameup, prioritydown, priorityup, responsibledown, responsibleup, sequencedown, sequenceup, tree

In addition the following values are supported as well. They specify scenario specific values so they can be prefixed with the ID of the scenario and a colon (e.g. `plan:startup`). If no scenario is specified, the default scenario is used. Possible values are completeddown, completedup, criticalnessdown, criticalnessup, enddown, endup, pathcriticalnessdown, pathcriticalnessup, startdown, startup, statusdown, statusup

`Context` | csvtaskreport, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No

    project test "Test Project" "$Id" 2000-01-01 2000-03-01

    flags flag1, flag2, flag3, flag4

    rate 100.0

    resource r1 "FooResource 1"
    resource r2 "FooResource 2"
    resource r3 "FooResource 3"
    resource r4 "FooResource 4"

    account a1 "FooAccount 1" cost {
      account a3 "FooAccount 3"
    }

    account a2 "FooAccount 2" revenue {
      account a4 "FooAccount 4"
    }

    task t1 "FooTask1" {
      account a4
      task t1_1 "FooTask1_1" {
        flags flag2
        start 2000-01-01
        effort 20d
        allocate r1
        allocate r2
      }
      flags flag3
    }

    task t2 "FooTask2" {
      flags flag1
      start 2000-01-01
      duration 1d
      startcredit 10000.0
      account a4
    }

    task t3 "FooTask3" {
      flags flag4
      milestone
      start 2000-01-01
    }

    htmltaskreport "Report_task.html" {
      columns hierarchindex, name { title "Task Name" }, daily, effort
      sorttasks tree, startup, nameup
    }

    htmlresourcereport "Report_resource.html" {
    }

    htmlaccountreport "Report_account.html" {
      columns name, weekly
      hideaccount 0
    }

## start <`date`>

start <`date`>
`Description` | Specifies the start date of the report. In task reports only tasks that end after this end date are listed.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | csvaccountreport, csvresourcereport, csvtaskreport, export, htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, resourcereport, taskreport,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | end, period

    project prj  "Project" "1.0" 2000-01-01 2000-03-01

    resource r "Resource"

    task t "Task" {
      start 2000-01-01
      effort 10d
      allocate r
    }

    # Export the project as fully scheduled project.
    export "FullProject.tjp" {
      taskattributes all
      hideresource 0
    }

    # Export only bookings for 1st week as resource supplements
    export "Week1Bookings.tji" {
      start 2000-01-01
      end 2000-01-08
      properties bookings
      hideresource 0
    }

## start <`date`>

start <`date`>
`Description` | The start date of the task. When specified for the top-level (default) scenario this attribute also implicitly sets the scheduling policy of the task to `asap`.
`Attributes` | `Name` | `Type` | `Description`
`date` | DATE |
`Context` | task,
`Inheritable` | Yes | `Scenario Spec.` | Yes
`See also` | end, period, maxstart, minstart, scheduling, startbuffer

    project duration "Duration Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task t "Enclosing" {
      start 2005-06-06
      task durationTask "Duration Task" {
        # This task is 10 calendar days long.
        duration 10d
      }

      task intervalTask "Interval Task" {
        # This task is similar to the durationTask. Instead of a start
        # date and a duration it has a fixed start and end date.
        end 2005-06-17
      }

      task lengthTask "Length Task" {
        # This task 10 working days long. So about 12 calendar days.
        length 10d
      }

      task effortTask "Effort Task" {
        effort 10d
        allocate tux
      }
    }

## startbuffer <`percent`>

startbuffer <`percent`>
`Description` | Specifies how much slack time you expect to have at the beginning of the task. This information has no impact on the scheduling of the project. It is for documentation purposes only.
`Attributes` | `Name` | `Type` | `Description`
`percent` | REAL | Percent slack of the overall effort, duration or length of the task.
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | duration, endbuffer, effort, length

    project simple "Simple Project" "$Id" 2000-01-01 2000-01-20

    resource tux1 "Tux1"

    task t1 "Task1" {
      start 2000-01-01
      length 10d
      # 20% of the working time of this task are marked as buffer at the
      # beginning.
      startbuffer 20
      # An additional 10% of the working time of this task are marked as
      # buffer at the end.
      endbuffer 10.0
      allocate tux1
    }

    # Generate a report that lists the start end end dates for the
    # buffers.
    htmltaskreport "Buffer.html" {
      columns no, name, start, startbufferend, endbufferstart, end,
      startbuffer, endbuffer, duration, effort, daily
      hideresource 0
    }

## startcredit <`amount`>

startcredit <`amount`>
`Description` | Specifies an amount that is credited to the account specified by the account property at the moment the tasks starts.
`Attributes` | `Name` | `Type` | `Description`
`amount` | REAL |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | endcredit

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26 {
      currency "USD"
    }

    account project_cost "Project Costs" cost
    account payments "Customer Payments" revenue {
      credit 2005-06-08 "Customer down payment" 500.0
    }

    resource tux "Tux" {
      rate 300
    }

    task items "Project breakdown" {
      start 2005-06-06
      # The default account for all tasks
      account project_cost

      task plan "Plan work" {
        # Some upfront material cost
        startcredit 500.0
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
        account payments
        # Customer pays at end of acceptance
        endcredit 2000.0
      }
    }

    htmlaccountreport "PAndL.html" {
      timeformat "%d-%M-%y"
      accumulate
      columns index, name, weekly
    }

## statusnote <`text`>

statusnote <`text`>
`Description` | A note that describes the current status of the task.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | task,
`Inheritable` | No | `Scenario Spec.` | Yes
`See also` | journalentry, note

## strict

strict

`Description`

Puts the scenario in strict bookings mode. This mode makes only sense when you also use projection mode for this scenario. In strict mode, no bookings will be filled in for any task prior to the current (or now) date. In sloppy mode all task that don't have any bookings provided will be filled with bookings according to the original schedule. TaskJuggler will generate a warning for each task where the booked effort excedes the specified effort.

`Context` | projection,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | booking, sloppy, projection

## subtitle <`text`>

subtitle <`text`>
`Description` | Specifies an alternative subtitle for a report column.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | subtitleurl

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## subtitleurl <`url`>

subtitleurl <`url`>
`Description` | Specifies an URL that is attached to the column subtitle of HTML reports.
`Attributes` | `Name` | `Type` | `Description`
`url` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | subtitle

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## supplement <`type`>

supplement <`type`>

`Description`

The supplement keyword provides a mechanism to add more attributes to already defined tasks or resources. The additional attributes must obey the same rules as in regular task or resource definitions and must be enclosed by curly braces.

This construct is primarily meant for situations where the information about a task or resource is split over several files. E. g. the vacation dates for the resources may be in a separate file that was generated by some other tool.

`Attributes` | `Name` | `Type` | `Description`
`type` | ID | Possible values are `resource` or `task`.
`Context` | The TJP File, task,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | resource, task

    project test "Test Project" "$Id" 2000-01-01 2000-01-04

    flags important

    resource joe "Joe"

    task top "Top Task" {
      start 2000-01-01

      task sub "Sub Task" {
      }
      supplement task sub {
        length 1d
      }
    }

    supplement resource joe {
      vacation 2000-02-10 - 2000-02-20
    }

    supplement task top {
      flags important
    }

## task <`id`> <`name`>

task <`id`> <`name`>
`Description` | Tasks are the central elements of a project plan. Use a task to specify which resource should be allocated for how long to what task.
`Attributes` | `Name` | `Type` | `Description`
`id` | ID |
`name` | STRING |
`Optional Attributes` | account, allocate, complete, depends, duration, effort, endbuffer, endcredit, end, flags, journalentry, length, maxend, maxstart, milestone, minend, minstart, note, period, precedes, priority, projectid, purge, reference, responsible, scheduled, scheduling, shift, startbuffer, startcredit, start, statusnote, supplement, `task`
`Context` | The TJP File, `task`,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | resource

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "My Tasks"

## taskattributes <`attribute`> [, <`attribute`> ... ]

taskattributes <`attribute`> [, <`attribute`> ... ]

`Description`

The list of attribute names specifies which task attributes should be listed in the report in addition to the ones exported by default. The following values are supported. They correspond to the respective attributes of a task.

`complete`, `depends`, `flags`, `maxend`, `maxstart`, `minend`, `minstart`, `note`, `priority`, `responsible`

By specifying the ID of a user-defined attribute, these can be included as well.

A special case the is `all` keyword. If this is part of the list, all supported task attributes will be included in the report. This includes all user-defined task attributes.

`Attributes` | `Name` | `Type` | `Description`
`attribute` | ID |
`Context` | export,
`Inheritable` | No | `Scenario Spec.` | No

    project prj  "Project" "1.0" 2000-01-01 2000-03-01

    resource r "Resource"

    task t "Task" {
      start 2000-01-01
      effort 10d
      allocate r
    }

    # Export the project as fully scheduled project.
    export "FullProject.tjp" {
      taskattributes all
      hideresource 0
    }

    # Export only bookings for 1st week as resource supplements
    export "Week1Bookings.tji" {
      start 2000-01-01
      end 2000-01-08
      properties bookings
      hideresource 0
    }

## taskprefix <`prefix`>

taskprefix <`prefix`>
`Description` | All tasks in the included file are added as sub-tasks of the task specified by `taskprefix`. The `taskprefix` must be a valid absolute ID of an already defined task.
`Attributes` | `Name` | `Type` | `Description`
`prefix` | ID |
`Context` | include,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | task

    project yourId "Your Project" "1.0" 2005-04-05 2005-05-01

    task main "Main task" {
    }

    include "Include2.tji" { taskprefix main }

## taskreport <`file`>

taskreport <`file`>
`Description` | This report is intended for the TaskJuggler graphical user interface. The report lists all tasks and their respective values as a HTML page. The resources that are allocated to the tasks can be listed as well.
`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | caption, columns, end, headline, hideresource, hidetask, loadunit, period, rollupresource, rolluptask, scenario, shorttimeformat, showprojectids, sortresources, sorttasks, start, taskroot, timeformat
`Context` |
`Inheritable` | No | `Scenario Spec.` | No
`See also` | csvtaskreport, htmlaccountreport, htmlresourcereport, resourcereport

    project simple "Simple Project" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"
    resource tuxia "Tuxia"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        task phase1 "Phase 1" {
          effort 5d
          allocate tuxia
        }
        task phase2 "Phase 2" {
          effort 2d
          allocate tux
        }
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "Project Breakdown" {
      columns start, end, effort
      # Open only the first level of tasks
      rolluptask treelevel() > 1
    }

    resourcereport "Resource Allocations" {
      columns id, effort
      # We only want to see the tasks with real work (without parents),
      # sorted by name
      sorttasks nameup
      hidetask ~isleaf()
    }

## taskroot <`root`>

taskroot <`root`>
`Description` | Only tasks below the specified root-level tasks are exported. The exported tasks will have the id of the root-level task stripped from their ID, so that the sub-tasks of the root-level task become top-level tasks in the exported file.
`Attributes` | `Name` | `Type` | `Description`
`root` | ID | ID of a task that specifies the new root level
`Context` | export, htmlmonthlycalendar, htmlresourcereport, htmltaskreport, htmlweeklycalendar, taskreport,
`Inheritable` | No | `Scenario Spec.` | No

    project prj "Taskroot Example" "1.0" 2005-07-22 2005-08-26

    task items "Project breakdown" {
      start 2005-07-22

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        task phase1 "Phase 1" {
          length 5d
          depends !!plan
        }
        task phase2 "Phase 2" {
          length 3d
          depends !phase1
        }
        task phase3 "Phase 3" {
          length 4d
          depends !phase2
        }
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    taskreport "My Tasks" {
      taskroot items.implementation
    }

## timezone <`zone`>

timezone <`zone`>

`Description`

Sets the default timezone of the project. All times that have no time zones specified will be assumed to be in this timezone. The value must be a string just like those used for the TZ environment variable. Most Linux systems have a command line utility called `tzselect` to lookup possible values.

The project start and end time are not affected by this setting. You have to explicitly state the timezone for those dates or the system defaults are assumed.

`Attributes` | `Name` | `Type` | `Description`
`zone` | STRING |
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No

    project tz "Timezone" "1.0" 2005-06-06-0:00-UTC 2005-06-07-0:00-UTC {
      timezone "Europe/Athens"
    }

    task item "Project" {
      start 2005-06-06-12:00
    }

## timeformat <`format`>

timeformat <`format`>
`Description` | Determines how time specifications in reports look like.
`Attributes` | `Name` | `Type` | `Description`
`format` | STRING | See table below for possible values.
`Context` | htmlaccountreport, htmlmonthlycalendar, htmlresourcereport, htmlstatusreport, htmltaskreport, htmlweeklycalendar, project, resourcereport, taskreport,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | shorttimeformat

Ordinary characters placed in the format string are copied to s without conversion. Conversion specifiers are introduced by a `%' character, and are replaced in s as follows:

- %a
- The abbreviated weekday name according to the current locale.
- %A
- The full weekday name according to the current locale.
- %b
- The abbreviated month name according to the current locale.
- %B
- The full month name according to the current locale.
- %c
- The preferred date and time representation for the current locale.
- %C
- The century number (year/100) as a 2-digit integer. (SU)
- %d
- The day of the month as a decimal number (range 01 to 31).
- %D
- Equivalent to %m/%d/%y. (Yecch - for Americans only. Americans should note that in other countries %d/%m/%y is rather common. This means that in international context this format is ambiguous and should not be used.) (SU)
- %e
- Like %d, the day of the month as a decimal number, but a leading zero is replaced by a space. (SU)
- %E
- Modifier: use alternative format, see below. (SU)
- %F
- Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99)
- %G
- The ISO 8601 year with century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %y, except that if the ISO week number belongs to the previous or next year, that year is used instead. (TZ)
- %g
- Like %G, but without century, i.e., with a 2-digit year (00-99). (TZ)
- %h
- Equivalent to %b. (SU)
- %H
- The hour as a decimal number using a 24-hour clock (range 00 to 23).
- %I
- The hour as a decimal number using a 12-hour clock (range 01 to 12).
- %j
- The day of the year as a decimal number (range 001 to 366).
- %k
- The hour (24-hour clock) as a decimal number (range 0 to 23); single digits are preceded by a blank. (See also %H.) (TZ)
- %l
- The hour (12-hour clock) as a decimal number (range 1 to 12); single digits are preceded by a blank. (See also %I.) (TZ)
- %m
- The month as a decimal number (range 01 to 12).
- %M
- The minute as a decimal number (range 00 to 59).
- %n
- A newline character. (SU)
- %O
- Modifier: use alternative format, see below. (SU)
- %p
- Either 'AM' or 'PM' according to the given time value, or the corresponding strings for the current locale. Noon is treated as `pm' and midnight as 'am'.
- %P
- Like %p but in lowercase: 'am' or 'pm' or %a corresponding string for the current locale. (GNU)
- %r
- The time in a.m. or p.m. notation. In the POSIX locale this is equivalent to '%I:%M:%S %p'. (SU)
- %R
- The time in 24-hour notation (%H:%M). (SU) For a version including the seconds, see %T below.
- %s
- The number of seconds since the Epoch, i.e., since 1970-01-01 00:00:00 UTC. (TZ)
- %S
- The second as a decimal number (range 00 to 61).
- %t
- A tab character. (SU)
- %T
- The time in 24-hour notation (%H:%M:%S). (SU)
- %u
- The day of the week as a decimal, range 1 to 7, Monday being 1. See also %w. (SU)
- %U
- The week number of the current year as a decimal number, range 00 to 53, starting with the first Sunday as the first day of week 01. See also %V and %W.
- %V
- The ISO 8601:1988 week number of the current year as a decimal number, range 01 to 53, where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week. See also %U %and %W. %(SU)
- %w
- The day of the week as a decimal, range 0 to 6, Sunday being 0. See also %u.
- %W
- The week number of the current %year as a decimal number, range 00 to 53, starting with the first Monday as the first day of week 01.
- %x
- The preferred date representation for the current locale without the time.
- %X
- The preferred time representation for the current locale without the date.
- %y
- The year as a decimal number without a century (range 00 to 99).
- %Y
- The year as a decimal number including the century.
- %z
- The time zone as hour offset from GMT. Required to emit RFC822-conformant dates (using "%a, %d %%b %Y %H:%M:%S %%z"). (GNU)
- %Z
- The time zone or name or abbreviation.
- %+
- The date and time in date(1) format. (TZ)
- %%
- A literal '%' character.

Some conversion specifiers can be modified by preceding them by the E or O modifier to indicate that an alternative format should be used. If the alternative format or specification does not exist for the current locale, the behavior will be as if the unmodified conversion specification were used. (SU) The Single Unix Specification mentions %Ec, %EC, %Ex, %%EX, %Ry, %EY, %Od, %Oe, %OH, %OI, %Om, %OM, %OS, %Ou, %OU, %OV, %Ow, %OW, %Oy, where the effect of the O modifier is to use alternative numeric symbols (say, Roman numerals), and that of the E modifier is to use a locale-dependent alternative representation.

The documentation of the `timeformat` attribute has been taken from the man page of the GNU `strftime` function.

## timingresolution <`value`> <`unit`>

timingresolution <`value`> <`unit`>

`Description`

Sets the minimum timing resolution. The smaller the value, the longer the scheduling process lasts and the more memory the application needs. The default and maximum value is 1 hour. The smallest value is 5 min.

This value is a pretty fundamental setting of TaskJuggler. It has a severe impact on memory usage and scheduling performance. You should set this value to the minimum required resolution. Make sure that all values that you specify are aligned with the resolution.

`Attributes` | `Name` | `Type` | `Description`
`value` | INTEGER |
`unit` | UNIT |
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No

## title <`text`>

title <`text`>
`Description` | Specifies an alternative title for a report column.
`Attributes` | `Name` | `Type` | `Description`
`text` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | titleurl

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## titleurl <`url`>

titleurl <`url`>
`Description` | Specifies an URL that is attached to the column title of HTML reports.
`Attributes` | `Name` | `Type` | `Description`
`url` | STRING |
`Context` | columns,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | title

    project prj  "Project" "1.0" 2005-01-01 2005-03-01

    resource r "Resource"

    task t "Task" {
      task s "SubTask" {
        start 2005-01-01
        effort 5d
        allocate r
      }
    }

    # Just a very basic report with some standard columns
    htmltaskreport "SimpleReport.html" {
      columns hierarchindex, name, start, end, weekly
    }

    # Report with custom colum title
    htmltaskreport "CustomTitle.html" {
      columns hierarchindex, name { title "Work Item" }, effort
    }

    # Report with custom colum title and subtitle
    htmltaskreport "CustomSubTitle.html" {
      columns hierarchindex, name,
              monthly { title " " subtitle "$${month} $${year}" }
      loadunit days
    }

    # Report with efforts only for leaf tasks
    htmltaskreport "LeafEfforts.html" {
      columns hierarchindex, name,
              effort { hidecelltext ~isLeaf() }
    }

    # Report with link in title of calendar
    htmltaskreport "LinkURL.html" {
      columns hierarchindex, name,
              monthly { subtitleurl "Monthly-Detail-$${month}.html" }
    }

    # Report with link to page with furter task details
    htmltaskreport "LinkToTaskDetails.html" {
      columns hierarchindex,
              name { cellurl "TaskDetails-$${taskid}.html"
                     hidecellurl ~isLeaf() }, start, end
    }

    # Report with index and task name combined in one single column
    htmltaskreport "CombinedColumn.html" {
      columns name { celltext "$${hierarchno} $${0}"}, start, end, weekly
    }

## vacation <`name`> <`interval`>

vacation <`name`> <`interval`>
`Description` | Specify a global vacation day. This vacation is respected by all resources that are defined hereafter.
`Attributes` | `Name` | `Type` | `Description`
`name` | STRING |
`interval` | DATEINTERVAL |
`Context` | The TJP File,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | vacation

    project prj "Vacation Examples" "1.0" 2005-07-22 2006-01-01

    # Labor Day
    vacation "Labor Day" 2005-09-05
    # 2 days Christmas break (27th not included!)
    vacation "Christmas" 2005-12-25 - 2005-12-27

    resource team "A team" {
      # 2 days of team vacation
      vacation 2005-10-07 +2d
      resource tux2 "Tux2"
      resource tux3 "Tux3" {
        # And one extra day
        vacation 2005-08-10
      }
    }

    # The vacation property is also usefull when new employees start
    # working in the course of a project or if someone quits.
    resource tuxia "Tuxia" {
      # Tuxia is a new employee as of August 1st 2005
      vacation 1971-01-01 - 2005-08-01
    }

    resource tuxus "Tuxus" {
      # Tuxus quits his job on September 1st 2005
      vacation 2005-09-01 - 2030-01-01
    }

    task t "An important date" {
      start 2005-07-22
    }

## vacation <`interval`>

vacation <`interval`>
`Description` | Specify a vacation period for the resource. It can also be used to block out the time before a resource joint or after it left. For employees changing their work schedule from full-time to part-time, or vice versa, please refer to the 'Shift' property.
`Attributes` | `Name` | `Type` | `Description`
`interval` | DATEINTERVAL |
`Context` | resource,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | vacation, shift

    project prj "Vacation Examples" "1.0" 2005-07-22 2006-01-01

    # Labor Day
    vacation "Labor Day" 2005-09-05
    # 2 days Christmas break (27th not included!)
    vacation "Christmas" 2005-12-25 - 2005-12-27

    resource team "A team" {
      # 2 days of team vacation
      vacation 2005-10-07 +2d
      resource tux2 "Tux2"
      resource tux3 "Tux3" {
        # And one extra day
        vacation 2005-08-10
      }
    }

    # The vacation property is also usefull when new employees start
    # working in the course of a project or if someone quits.
    resource tuxia "Tuxia" {
      # Tuxia is a new employee as of August 1st 2005
      vacation 1971-01-01 - 2005-08-01
    }

    resource tuxus "Tuxus" {
      # Tuxus quits his job on September 1st 2005
      vacation 2005-09-01 - 2030-01-01
    }

    task t "An important date" {
      start 2005-07-22
    }

## version <`number`>

version <`number`>
`Description` | Specifies which XML format should be generated. Currently version 2 is highly recommended.
`Attributes` | `Name` | `Type` | `Description`
`number` | INTEGER |
`Context` | xmlreport,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "XML Report Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    # This is the format that e. g. tjx2gantt can read
    xmlreport "Version1.tjx" {
      version 1
    }

    # This is the format that taskjuggler can read and write
    xmlreport "Version2.tjx" {
      version 2
    }

## weekdays <`weekday`> [, <`weekday`> ... ]

weekdays <`weekday`> [, <`weekday`> ... ]
`Description` | This attribute specifies a list of weekdays that are shown in the report.
`Attributes` | `Name` | `Type` | `Description`
`weekday` | WEEKDAY |
`Context` | htmlmonthlycalendar, htmlweeklycalendar,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | workinghours

## weeklymax <`value`> <`unit`>

weeklymax <`value`> <`unit`>
`Description` | Sets the weekly limit of a resource usage or a resource allocation to a task.
`Attributes` | `Name` | `Type` | `Description`
`value` | REAL |
`unit` | UNIT |
`Context` | limits,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | dailymax, monthlymax

    project limits "Limits" "1.0" 2004-03-01 2004-05-01

    # Default limit that affects all subsequently defined resources
    limits {
      weeklymax 4d
    }

    resource r1 "R1" {
      # Limit the usage of this resource to a maximum of 2 hours per day,
      # 6 hours per week and 2.5 days per month.
      limits { dailymax 2h weeklymax 6h monthlymax 2.5d }
    }

    resource r2 "R2"

    task t1 "Task 1" {
      start 2004-03-01
      duration 60d
      # allocation is subject to resource limits
      allocate r1
    }

    task t2 "Task 2" {
      start 2004-03-01
      duration 60d
      # limits can also be specified per allocation
      allocate r2 {
        limits { dailymax 4h weeklymax 3d monthlymax 2w }
      }
    }

## weekstartsmonday

weekstartsmonday
`Description` | Specify that you want to base all week calculation on weeks starting on Monday. This is common in many European countries.
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | weekstartssunday

## weekstartssunday

weekstartssunday
`Description` | Specify that you want to base all week calculation on weeks starting on Sunday. This is common in the United States of America.
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | weekstartsmonday

## workinghours <`weekday`> [, <`weekday`> ... ] <`interval`> [, <`interval`> ... ]

workinghours <`weekday`> [, <`weekday`> ... ] <`interval`> [, <`interval`> ... ]
`Description` | The working hours specification limits the availability of resources to certain time slots of week days.
`Attributes` | `Name` | `Type` | `Description`
`weekday` | WEEKDAY |
`interval` | TIMEINTERVAL |
`Context` | project, resource, shift,
`Inheritable` | Yes | `Scenario Spec.` | No
`See also` | dailyworkinghours, yearlyworkingdays

    project prj "Example Project" "1.0" 2000-01-01 2000-03-09 {
      # The following attributes are all optional. They illustrate the
      # default values. These attributes are only needed if you want to
      # specify different values than those listed below.
      dailyworkinghours 8
      yearlyworkingdays 260.714
      timingresolution 60min
      timeformat "%Y-%m-%d %H:%M"
      shorttimeformat "%H:%M"
      currencyformat "(" ")" "," "." 0
      weekstartsmonday
        workinghours mon - fri 9:00 - 12:00, 13:00 - 18:00
        workinghours sat, sun off
      scenario plan "Plan" {
      }
    }

    task t "Task" {
      start 2000-01-01
    }

## xmlreport <`file`>

xmlreport <`file`>

`Description`

Generates a XML report. TaskJuggler 2.x has a much improved XML format. This is not yet the default, but will be in later versions. So you should always specify which version of the XML format should be generated. The file name should have a `.tjx` extension. Version 2 files are gzip compressed XML Files. The DTD for the version 2 file format can be found on the TaskJuggler Web Site.

`Attributes` | `Name` | `Type` | `Description`
`file` | STRING |
`Optional Attributes` | hideresource, hidetask, rollupresource, rolluptask, scenarios, version
`Context` | The TJP File,
`Inheritable` | No | `Scenario Spec.` | No

    project simple "XML Report Example" "1.0" 2005-06-06 2005-06-26

    resource tux "Tux"

    task items "Project breakdown" {
      start 2005-06-06

      task plan "Plan work" {
        length 3d
      }

      task implementation "Implement work" {
        effort 5d
        allocate tux
        depends !plan
      }

      task acceptance "Customer acceptance" {
        duration 5d
        depends !implementation
      }
    }

    # This is the format that e. g. tjx2gantt can read
    xmlreport "Version1.tjx" {
      version 1
    }

    # This is the format that taskjuggler can read and write
    xmlreport "Version2.tjx" {
      version 2
    }

## yearlyworkingdays <`days`>

yearlyworkingdays <`days`>

`Description`

Specifies the number of average working days per year. This should correlate to the specified workinghours and vacation. It affects the conversion of working hours, working days, working weeks, working months and working years into each other.

When public holidays and vacations are disregarded, this value should be equal to the number of working days per week times 52.1428 (the average number of weeks per year). E. g. for a culture with 5 working days it is 260.714 (the default), for 6 working days it is 312.8568 and for 7 working days it is 365.

`Attributes` | `Name` | `Type` | `Description`
`days` | REAL |
`Context` | project,
`Inheritable` | No | `Scenario Spec.` | No
`See also` | dailyworkinghours, loadunit, vacation, workinghours

    project prj "Example Project" "1.0" 2000-01-01 2000-03-09 {
      # The following attributes are all optional. They illustrate the
      # default values. These attributes are only needed if you want to
      # specify different values than those listed below.
      dailyworkinghours 8
      yearlyworkingdays 260.714
      timingresolution 60min
      timeformat "%Y-%m-%d %H:%M"
      shorttimeformat "%H:%M"
      currencyformat "(" ")" "," "." 0
      weekstartsmonday
        workinghours mon - fri 9:00 - 12:00, 13:00 - 18:00
        workinghours sat, sun off
      scenario plan "Plan" {
      }
    }

    task t "Task" {
      start 2000-01-01
    }