29,619 bytes added,
7 June {{UnderConstructionStart}}
== MRO Maintenance Planning ==
The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans.
A maintenance plan defines the rules for creating work packages. These rules include when a work package should be created, which asset it belongs to, which template work package should be used, how the template work package should be copied, how early before the planned execution date the work package may be generated, and how future planning dates are calculated.
The actual maintenance work is not executed by the maintenance plan itself. The maintenance plan creates work packages. These generated work packages are then used by users to execute and complete the actual maintenance work.
In MRO, MaintenancePlan is the abstract base class for maintenance planning. It provides the common foundation for maintenance plans, but it is not intended to be used directly because it is abstract.
The fully implemented maintenance plan types in standard MRO are:
* CyclicMaintenancePlan
* RoundMaintenancePlan
Custom maintenance plan types can be implemented by deriving from the abstract MaintenancePlan base class. However, the standard MRO maintenance planning feature is based on cyclic maintenance plans and round maintenance plans.
CyclicMaintenancePlan and RoundMaintenancePlan support recurrence-based scheduling. This includes planned execution dates, automatic work package generation, calendar-based scheduling, completion-based scheduling, automatic recalculation of scheduling dates, and generation based on due dates.
RoundMaintenancePlan additionally supports maintenance rounds. A round maintenance plan creates one main work package for the round. It can also create additional work packages from child maintenance plans linked via SYSREL_ROUND_RELATION. These additional work packages are assigned to the main round work package.
== Basic concept ==
The maintenance planning feature is built around four main parts:
* the maintenance plan
* the template work package
* the replication configuration
* the generated work package
=== Maintenance plan ===
The maintenance plan defines the rules for creating work packages.
This includes, for example:
* when a work package should be created
* which asset the work package should belong to
* how many days before the planned execution date the work package may be created
* which template work package should be used
* which recurrence pattern should be used
* whether future dates are calculated calendar-based or completion-based
=== Template work package ===
The template work package defines what the generated work package should look like.
This means the template work package is the source work package that is copied when the maintenance plan creates a new work package.
Only work packages with ISTEMPLATE set can be used as template work packages.
=== Replication configuration ===
The replication configuration defines how the template work package is copied.
This includes, for example, which properties are copied, how referenced objects are handled, and what the target meta class of the generated work package should be.
=== Generated work package ===
The generated work package is the actual result created by the maintenance plan.
Example:
A pump has to be inspected every month.
A cyclic maintenance plan is created for this pump. The plan is configured with a monthly recurrence, an assigned asset, a template work package, and a replication configuration.
When the plan becomes due, the system uses a replication job to create a new work package from the configured template work package.
The generated work package is linked back to the maintenance plan via LK_MAINTENANCE_PLAN. This allows the maintenance plan to react when the generated work package is planned or completed.
== MaintenancePlan base class ==
=== Purpose ===
MaintenancePlan is the abstract base class for maintenance planning in MRO.
It provides the common properties and logic that are required by maintenance plan implementations.
Because MaintenancePlan is abstract, users do not create or use this base class directly in the standard MRO feature.
Instead, the concrete maintenance plan types are used:
* CyclicMaintenancePlan
* RoundMaintenancePlan
Developers can derive from the abstract base class if a project requires a custom maintenance plan type. In that case, the custom implementation must provide the missing plan-specific behavior.
=== LK_ASSET ===
LK_ASSET is the link to the asset that requires maintenance.
This can be, for example:
* equipment
* a functional location
* another customized maintainable object deriving from Asset
The generated work package is linked to the same asset.
A cyclic maintenance plan requires LK_ASSET to be assigned in order to be valid.
=== LK_WP_TMPL ===
LK_WP_TMPL is the link to the template work package.
The template work package defines what the generated work package should look like.
When the maintenance plan creates a work package, the system copies the work package referenced by LK_WP_TMPL.
The linked work package must be a template work package. This means its ISTEMPLATE property must be set.
If LK_WP_TMPL is not configured, the maintenance plan cannot create a work package.
=== LK_REPLICATION_CONFIG ===
LK_REPLICATION_CONFIG is the link to the replication configuration.
The replication configuration defines how the template work package is copied into a generated work package.
It can define, for example:
* which properties are copied
* how references are copied
* what the target meta class of the generated work package should be
If LK_REPLICATION_CONFIG is not configured, the maintenance plan cannot create a work package.
=== NEXT_DATE ===
NEXT_DATE defines the planned execution date of the next maintenance activity.
It answers the question: When should the next maintenance work be performed?
NEXT_DATE is not necessarily the date on which the work package is created.
Example:
NEXT_DATE: 15 March
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: 12 March
In this example, the system may create the work package on 12 March, but the generated work package is planned for 15 March.
When a work package is generated, the generated work package receives the maintenance plan’s NEXT_DATE as its PLANNED_START.
=== LEAD_DAYS ===
LEAD_DAYS defines how many days before NEXT_DATE the system may create the work package.
This is used to create work packages before the actual planned execution date.
Example:
NEXT_DATE: 15 March
LEAD_DAYS: 3
The system calculates:
EARLIEST_GENERATION_DATE: 12 March
This means that the work package can be created from 12 March onward.
LEAD_DAYS does not define the recurrence interval. It only defines how early the work package may be generated before the planned execution date.
=== EARLIEST_GENERATION_DATE ===
EARLIEST_GENERATION_DATE is calculated by the system.
It defines the earliest date on which the maintenance plan may create a work package.
The system calculates it like this:
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
Example:
NEXT_DATE: 15 March
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: 12 March
The maintenance planning orchestrator searches for active plans where EARLIEST_GENERATION_DATE has been reached.
A plan can be considered for automatic work package generation when:
EARLIEST_GENERATION_DATE <= current date
If EARLIEST_GENERATION_DATE has not yet been reached, no work package is created.
=== PLAN_STATUS ===
PLAN_STATUS defines whether the maintenance plan is active or inactive.
Only active plans are considered for automatic work package generation.
Inactive plans are ignored by the maintenance planning process.
This allows users to temporarily disable a maintenance plan without deleting it.
Typical values are:
* Inactive
* Active
=== AUTO_CREATE ===
AUTO_CREATE defines whether the system is allowed to automatically create work packages from the maintenance plan.
If AUTO_CREATE is enabled, the maintenance planning orchestrator can create work packages once the plan is due.
If AUTO_CREATE is disabled, the plan does not automatically create work packages.
=== LAST_DATE ===
LAST_DATE stores the date when the most recent generated work package linked to the maintenance plan was completed.
This property is especially important for completion-based scheduling.
In completion-based scheduling, the completion date of the previous generated work package is used to calculate the next planned execution date.
Example:
Previous generated work package completed: 20 March
SCHEDULING_MODE: Completion-Based
Next date is calculated from: 20 March
The system updates LAST_DATE when a generated work package is completed.
=== PRIORITY ===
PRIORITY is a numeric value that can be used to sort maintenance plans.
For round maintenance plans, there is also a property called PLAN_SELECTION_RULE. The exact effect of this property should be documented only after the implementation behavior has been verified.
== Work package properties used by maintenance planning ==
=== LK_MAINTENANCE_PLAN ===
LK_MAINTENANCE_PLAN is set on generated work packages.
It stores the maintenance plan that triggered the creation of the work package.
This is important because the maintenance plan itself does not directly store a list of generated work packages. Instead, generated work packages reference their source maintenance plan via LK_MAINTENANCE_PLAN.
This link allows the system to find work packages created from a maintenance plan and to update the maintenance plan when a generated work package is planned or completed.
=== LK_WP_TMPL ===
On a generated work package, LK_WP_TMPL stores the template work package that was used to create the generated work package.
This allows users and the system to see which template was used as the source.
=== LK_ASSET ===
On a generated work package, LK_ASSET stores the asset for which the work package was created.
This is usually copied or assigned based on the maintenance plan’s LK_ASSET.
=== PLANNED_START ===
PLANNED_START stores the planned start date of the generated work package.
When a maintenance plan generates a work package, the system sets:
generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE
=== ORGA_STATUS ===
ORGA_STATUS is used to determine whether a generated work package is finished.
A work package is considered finished when:
ORGA_STATUS == 100
Open work packages are generated work packages linked to the maintenance plan where ORGA_STATUS != 100.
A maintenance plan does not create another work package while it still has an open generated work package.
=== TASK_OWNER ===
TASK_OWNER is used in round maintenance scenarios.
When a round maintenance plan creates a main work package and additional work packages from linked child plans, the additional work packages are assigned to the main round work package via TASK_OWNER.
=== ORDERID and GROUPID ===
ORDERID and GROUPID can be copied from the SYSREL_ROUND_RELATION relation to generated work packages in a round maintenance scenario.
They can be used to order or group the additional work packages that belong to the generated round work package.
== CyclicMaintenancePlan ==
=== Purpose ===
A CyclicMaintenancePlan is used for recurring maintenance work on an asset.
It is the standard maintenance plan type for maintenance activities that repeat according to a defined recurrence pattern.
Examples:
* inspect a pump every month
* service a machine every 6 months
* check safety equipment every Monday
* replace a filter every 30 days
* perform annual maintenance on a functional location
A cyclic maintenance plan uses RRULE to define the recurrence. It also uses SCHEDULING_MODE to define how future dates are calculated.
SCHEDULING_MODE is important because it defines whether the plan follows fixed calendar dates or whether the next date depends on the actual completion date of the previous generated work package.
The supported scheduling modes are:
* Calendar-Based
* Completion-Based
== CyclicMaintenancePlan properties ==
=== RRULE ===
RRULE defines the recurrence pattern of a cyclic maintenance plan.
It describes how often the maintenance should occur.
Examples:
FREQ=DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR
FREQ=MONTHLY;BYMONTHDAY=15
The system uses RRULE to calculate future planned execution dates.
If RRULE is invalid and cannot be parsed, the cyclic maintenance plan is not valid and cannot create work packages.
=== RRULE_START_DATE ===
RRULE_START_DATE defines when the recurrence pattern starts.
The recurrence rule is calculated from this date forward.
Example:
RRULE_START_DATE: 01 January
RRULE: monthly on the 15th
The system uses these values to determine valid planned execution dates.
=== RRULE_UNTIL_DATE ===
RRULE_UNTIL_DATE is an optional end date for the recurrence.
If this date is configured, no further occurrences are generated after this date.
This can be used for maintenance plans that should only run until a certain date.
=== RRULE_COUNT ===
RRULE_COUNT limits how many work packages can be created from the plan.
Example:
RRULE_COUNT: 10
When the number of related generated work packages reaches RRULE_COUNT, the system no longer calculates new occurrences for the plan.
=== SCHEDULING_MODE ===
SCHEDULING_MODE defines how NEXT_DATE is calculated for a cyclic maintenance plan.
SCHEDULING_MODE is only relevant for concrete maintenance plan types that use recurrence logic, such as CyclicMaintenancePlan and RoundMaintenancePlan.
The supported scheduling modes are:
* Calendar-Based
* Completion-Based
This property is one of the most important settings because it defines whether future dates follow the calendar or depend on the actual completion of the previous generated work package.
== Calendar-based scheduling ==
=== Purpose ===
Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences.
The next planned execution date is calculated according to RRULE and the calendar recurrence.
This means that delays in completing a work package do not automatically shift the whole future schedule.
Use calendar-based scheduling when the maintenance should happen on fixed dates or fixed calendar intervals.
Examples:
* inspection every 15th day of the month
* safety check every Monday
* yearly inspection every January
* quarterly maintenance in fixed maintenance windows
=== How calendar-based scheduling works ===
In calendar-based scheduling, the system calculates NEXT_DATE based on the recurrence rule and the relevant dates of existing generated work packages.
The system determines the highest relevant planned or finished date of generated work packages linked to the maintenance plan.
Then it uses the recurrence rule to calculate the next valid occurrence after that date.
This means the schedule continues according to the recurrence pattern.
If a work package is completed later than planned, the future schedule does not necessarily move with that completion date.
=== Example: calendar-based scheduling ===
A pump must be inspected on the 15th of every month.
Configuration:
Plan Type: CyclicMaintenancePlan
LK_ASSET: Pump 1
LK_WP_TMPL: Pump Inspection Template
LK_REPLICATION_CONFIG: Pump Inspection Replication
SCHEDULING_MODE: Calendar-Based
RRULE: monthly on the 15th
RRULE_START_DATE: 01 January
NEXT_DATE: 15 March
LEAD_DAYS: 3
PLAN_STATUS: Active
AUTO_CREATE: enabled
The system calculates:
EARLIEST_GENERATION_DATE: 12 March
On or after 12 March, the system can create the work package.
Generated work package:
PLANNED_START: 15 March
After the work package is planned, the system can calculate the next occurrence.
NEXT_DATE: 15 April
If the March work package is completed on 20 March, the next date still follows the monthly recurrence.
The next planned execution date remains 15 April.
The late completion does not shift the future schedule to 20 April.
== Completion-based scheduling ==
=== Purpose ===
Completion-based scheduling is used when the next maintenance date should depend on the actual completion date of the previous generated work package.
This means that the interval starts after the work has actually been completed.
Use completion-based scheduling when the maintenance should repeat based on the time since the last completed maintenance activity.
Examples:
* service every 30 days after the last service
* inspection 6 months after the previous inspection was completed
* replacement 90 days after the previous replacement
* maintenance where a delay should also delay the next cycle
=== How completion-based scheduling works ===
In completion-based scheduling, the system recalculates NEXT_DATE after a generated work package is completed.
The completion date becomes the basis for the next occurrence.
Planning changes alone do not define the next recurrence in the same way as calendar-based scheduling.
The important point is:
The plan waits for the generated work package to be completed. Then the system calculates the next date from the completion date.
=== Example: completion-based scheduling ===
A machine must be serviced every 30 days after the previous service was completed.
Configuration:
Plan Type: CyclicMaintenancePlan
LK_ASSET: Machine 1
LK_WP_TMPL: Machine Service Template
LK_REPLICATION_CONFIG: Machine Service Replication
SCHEDULING_MODE: Completion-Based
RRULE: every 30 days
RRULE_START_DATE: 01 March
NEXT_DATE: 15 March
LEAD_DAYS: 3
PLAN_STATUS: Active
AUTO_CREATE: enabled
The system calculates:
EARLIEST_GENERATION_DATE: 12 March
On or after 12 March, the system can create the work package.
Generated work package:
PLANNED_START: 15 March
The work package is completed on 20 March.
Because the plan is completion-based, the system calculates the next date from 20 March.
If the recurrence is every 30 days:
NEXT_DATE: around 19 April
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: around 16 April
In this mode, the delay from 15 March to 20 March shifts the future schedule.
== Difference between calendar-based and completion-based scheduling ==
The difference is the date that is used as the basis for calculating NEXT_DATE.
Calendar-based scheduling follows the recurrence defined by RRULE.
Completion-based scheduling follows the actual completion of the previous generated work package.
=== Calendar-based ===
Calendar-based scheduling should be used when the maintenance must follow fixed planned dates.
Characteristics:
* The plan follows the RRULE calendar pattern.
* Future dates are not automatically shifted just because a work package was completed late.
* NEXT_DATE can be recalculated after planning updates.
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates.
Example:
Planned inspection: 15 March
Completed: 20 March
Next date: 15 April
The future date stays aligned with the calendar recurrence.
=== Completion-based ===
Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed.
Characteristics:
* The plan waits for completion.
* The completion date is used as the basis for NEXT_DATE.
* If the work is completed late, the future schedule moves.
* It is useful for service intervals that depend on the actual last maintenance.
Example:
Planned service: 15 March
Completed: 20 March
Interval: 30 days
Next date: around 19 April
The future date shifts because the work was completed later.
== RoundMaintenancePlan ==
=== Purpose ===
A RoundMaintenancePlan is used for recurring maintenance rounds.
It is a specialized type of cyclic maintenance plan. This means that it also uses RRULE and SCHEDULING_MODE.
In addition to the cyclic scheduling logic, a round maintenance plan includes child maintenance plans linked via SYSREL_ROUND_RELATION.
When the round maintenance plan is due, the system creates the main work package for the round.
Then it creates additional work packages from the child maintenance plans linked via SYSREL_ROUND_RELATION.
For the child plans, the system does not care whether they are due, active, auto-created, or whether they have a valid RRULE. The round maintenance plan uses the child plans as configuration for the additional work packages that should be created as part of the round.
The important configuration on the child plans is therefore their work package generation setup, especially the configured template work package and replication setup.
=== Generated result ===
Example:
Round Maintenance Plan: Machine Room Round
Linked child plans under SYSREL_ROUND_RELATION:
* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection
Generated main work package:
* Machine Room Round
Additional generated work packages inside the main round work package:
* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection
The additional work packages are assigned to the main round work package. This allows the result of the round maintenance plan to be structured as one complete maintenance round.
== RoundMaintenancePlan properties and relations ==
=== SYSREL_ROUND_RELATION ===
SYSREL_ROUND_RELATION links the round maintenance plan to its child maintenance plans.
The linked child plans define which additional work packages should be generated when the round maintenance plan is due.
When the round plan generates work packages, the system creates:
* one main work package from the round plan’s own LK_WP_TMPL
* one additional work package for each child maintenance plan linked via SYSREL_ROUND_RELATION
The child maintenance plans do not need to be due themselves for the round maintenance plan to use them during round generation.
=== PLAN_SELECTION_RULE ===
PLAN_SELECTION_RULE exists on RoundMaintenancePlan.
The exact runtime effect of this property should be documented after the implementation behavior has been verified.
Until that behavior is confirmed, the wiki should not claim that PLAN_SELECTION_RULE filters child plans by due date, asset, or priority.
=== ORDERID and GROUPID ===
The relation between the round maintenance plan and a linked child maintenance plan can contain ORDERID and GROUPID.
When the system creates an additional work package from a linked child maintenance plan, these values can be copied to the generated work package.
This can be used to structure, order, or group the additional work packages in the generated round.
== Properties calculated or updated by the system ==
=== EARLIEST_GENERATION_DATE ===
EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.
Formula:
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
This value is recalculated when:
* NEXT_DATE changes
* LEAD_DAYS changes
* NEXT_DATE is recalculated after planning or completion
* recurrence settings cause a new NEXT_DATE to be calculated
=== NEXT_DATE ===
For CyclicMaintenancePlan and RoundMaintenancePlan, NEXT_DATE can be calculated or recalculated by the system.
The calculation depends on:
* RRULE
* RRULE_START_DATE
* RRULE_UNTIL_DATE
* RRULE_COUNT
* SCHEDULING_MODE
* related generated work packages
* planning events
* completion events
For calendar-based scheduling, NEXT_DATE is calculated from the recurrence pattern and the highest relevant planned or finished date of related generated work packages.
For completion-based scheduling, NEXT_DATE is calculated from the completion date of the previous generated work package.
=== LAST_DATE ===
LAST_DATE is updated by the system when a generated work package is completed.
It stores the latest completion date of a generated work package related to the maintenance plan.
This value is especially relevant for completion-based scheduling.
=== PLANNED_START on generated work packages ===
When the system generates a work package from a maintenance plan, it sets the generated work package’s PLANNED_START to the maintenance plan’s NEXT_DATE.
Example:
MaintenancePlan.NEXT_DATE: 15 March
Generated WorkPackage.PLANNED_START: 15 March
=== Links on generated work packages ===
When the system generates a work package, it automatically sets the required links on the generated work package.
The generated work package is linked to:
* the source maintenance plan via LK_MAINTENANCE_PLAN
* the template work package via LK_WP_TMPL
* the assigned asset via LK_ASSET
For round maintenance plans, additional generated work packages from linked child maintenance plans are assigned to the main round work package via TASK_OWNER.
== Properties and events that trigger recalculation ==
=== NEXT_DATE changed ===
When NEXT_DATE changes, the system recalculates EARLIEST_GENERATION_DATE.
Formula:
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
=== LEAD_DAYS changed ===
When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.
Formula:
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
=== RRULE changed ===
When RRULE changes, the recurrence pattern changes.
The system recalculates NEXT_DATE based on the new recurrence rule and the selected SCHEDULING_MODE.
After NEXT_DATE is recalculated, EARLIEST_GENERATION_DATE is recalculated as well.
=== RRULE_START_DATE changed ===
When RRULE_START_DATE changes, the start point of the recurrence changes.
The system recalculates the schedule.
This can change NEXT_DATE.
If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.
=== RRULE_UNTIL_DATE changed ===
When RRULE_UNTIL_DATE changes, the end boundary of the recurrence changes.
The system checks whether future occurrences are still available.
If no further occurrence is possible because of RRULE_UNTIL_DATE, the system cannot calculate a new NEXT_DATE.
=== RRULE_COUNT changed ===
When RRULE_COUNT changes, the system checks whether the maximum number of generated work packages has already been reached.
If the number of related generated work packages is greater than or equal to RRULE_COUNT, the system does not calculate further occurrences.
=== SCHEDULING_MODE changed ===
When SCHEDULING_MODE changes, the logic for calculating future dates changes.
Changing to Calendar-Based means that the plan follows the calendar recurrence.
Changing to Completion-Based means that the plan calculates NEXT_DATE from the completion of the previous generated work package.
Because this changes the calculation logic, the system recalculates NEXT_DATE according to the selected SCHEDULING_MODE.
If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.
=== Generated work package PLANNED_START changed ===
When PLANNED_START of a generated work package is set or changed, the work package notifies the linked maintenance plan.
For calendar-based cyclic maintenance plans, this can trigger recalculation of NEXT_DATE.
The system uses the planning information to continue the calendar-based recurrence.
For completion-based cyclic maintenance plans, a PLANNED_START change does not drive the recurrence in the same way. NEXT_DATE is mainly calculated after the work package is completed.
=== Generated work package completed ===
When a generated work package is completed, the work package notifies the linked maintenance plan.
A work package is considered completed when:
ORGA_STATUS == 100
The system updates LAST_DATE.
Then the system recalculates NEXT_DATE according to SCHEDULING_MODE.
For calendar-based scheduling:
* the system continues according to the calendar recurrence
* NEXT_DATE is calculated from the recurrence pattern and relevant planned or finished dates
For completion-based scheduling:
* the completion date becomes the basis for the next occurrence
* NEXT_DATE is calculated from the completion date
After NEXT_DATE is updated, EARLIEST_GENERATION_DATE is recalculated.
== Work package generation logic ==
=== When is a plan ready to create a work package? ===
A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled.
The plan must be valid.
For cyclic maintenance plans, this means:
* RRULE is valid
* LK_ASSET is assigned
* NEXT_DATE is available
The plan must be active:
PLAN_STATUS == Active
AUTO_CREATE must be enabled.
A template work package must be assigned:
LK_WP_TMPL must be set.
A replication configuration must be assigned:
LK_REPLICATION_CONFIG must be set.
The earliest generation date must be reached:
EARLIEST_GENERATION_DATE <= current date
There must be no open work package for the plan.
This means there must be no generated work package linked via LK_MAINTENANCE_PLAN where ORGA_STATUS != 100.
This prevents the system from creating multiple open work packages for the same maintenance plan.
== Round work package generation ==
A round maintenance plan creates a main work package for the round.
After the main work package has been created, the system processes the maintenance plans linked via SYSREL_ROUND_RELATION.
For each linked child maintenance plan, the system creates an additional work package.
These additional generated work packages are assigned to the main round work package via TASK_OWNER.
For child plans used in a round, the system does not care whether the child plan:
* has PLAN_STATUS == Active
* has AUTO_CREATE == true
* has a valid RRULE
* has a valid NEXT_DATE
* is due based on its own EARLIEST_GENERATION_DATE
The round plan controls the timing. The child plans define what additional work packages should be created as part of the round.
{{UnderConstructionEnd}}