Changes
{{UnderConstructionStart}}
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Summary:''' The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans.The maintenance plan defines the rules. The generated work package is used by users to execute and complete the actual maintenance work.</div>
* when a work package should be created* which asset the work package belongs to* which template work package is used* how the template work package is copied* how many days before the planned execution date the work package may be generated* 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 maintenance work. In MRO, <code>MaintenancePlan </code> 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:
* <code>CyclicMaintenancePlan</code>* <code>RoundMaintenancePlan</code>
Custom maintenance plan types can be implemented by deriving from the abstract <code>MaintenancePlan </code> base class. However, the standard MRO maintenance planning feature is based on cyclic maintenance plans and round maintenance plans.
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Important:''' <code>CyclicMaintenancePlan </code> and <code>RoundMaintenancePlan </code> 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.</div>
<code>RoundMaintenancePlan </code> 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 <code>SYSREL_ROUND_RELATION</code>. These additional work packages are assigned to the main round work package.
== Basic concept Concept ==
The maintenance planning feature is built around four main parts:
=== Maintenance plan Plan ===
The maintenance plan defines the rules for creating work packages.
* whether future dates are calculated calendar-based or completion-based
=== Template work package Work Package ===
The template work package defines what the generated work package should look like.
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Rule:''' Only work packages with <code>ISTEMPLATE </code> set can be used as template work packages.</div>
=== Replication configuration 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.:
* which properties are copied* how referenced objects are handled* what the target meta class of the generated work package should be === Generated work package 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 <code>LK_MAINTENANCE_PLAN</code>.
=== Purpose ===
<code>MaintenancePlan </code> 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 <code>MaintenancePlan </code> 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:
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.
=== Base Class Properties === {| class="wikitable" style="width: 100%;"! Property! Purpose! Notes|-| <code>LK_ASSET </code>| Links the maintenance plan to the asset that requires maintenance.| Required for a valid cyclic maintenance plan.|-| <code>LK_WP_TMPL</code>| Links the maintenance plan to the template work package.| The linked work package must have <code>ISTEMPLATE</code> set.|-| <code>LK_REPLICATION_CONFIG</code>| Links the maintenance plan to the replication configuration.| Required for work package generation.|-| <code>NEXT_DATE</code>| Defines the planned execution date of the next maintenance activity.| Used as <code>PLANNED_START</code> on generated work packages.|-| <code>LEAD_DAYS</code>| Defines how many days before <code>NEXT_DATE</code> the system may create the work package.| Does not define the recurrence interval.|-| <code>EARLIEST_GENERATION_DATE</code>| Defines the earliest date on which the maintenance plan may create a work package.| Calculated by the system.|-| <code>PLAN_STATUS</code>| Defines whether the maintenance plan is active or inactive.| Only active plans are considered for automatic generation.|-| <code>AUTO_CREATE</code>| Defines whether the system is allowed to automatically create work packages.| If disabled, the plan does not automatically create work packages.|-| <code>LAST_DATE</code>| Stores the most recent completion date of a generated work package linked to the maintenance plan.| Especially relevant for completion-based scheduling.|-| <code>PRIORITY</code>| Numeric value that can be used to sort maintenance plans.| For round maintenance plans, see also <code>PLAN_SELECTION_RULE</code>.|} === <code>LK_ASSET</code> ===
<code>LK_ASSET </code> is the link to the asset that requires maintenance.
This can be, for example:
* equipment
* a functional location
* another customized maintainable object deriving from <code>Asset</code>
The generated work package is linked to the same asset.
<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">'''Validation:''' A cyclic maintenance plan requires <code>LK_ASSET </code> to be assigned in order to be valid.</div>
=== <code>LK_WP_TMPL </code> ===
<code>LK_WP_TMPL </code> 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 <code>LK_WP_TMPL</code>.
The linked work package must be a template work package. This means its <code>ISTEMPLATE </code> property must be set.
<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">'''Validation:''' If <code>LK_WP_TMPL </code> is not configured, the maintenance plan cannot create a work package.</div>
=== <code>LK_REPLICATION_CONFIG </code> ===
<code>LK_REPLICATION_CONFIG </code> is the link to the replication configuration.
The replication configuration defines how the template work package is copied into a generated work package.
* what the target meta class of the generated work package should be
<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">'''Validation:''' If <code>LK_REPLICATION_CONFIG </code> is not configured, the maintenance plan cannot create a work package.</div>
=== <code>NEXT_DATE </code> ===
<code>NEXT_DATE </code> defines the planned execution date of the next maintenance activity.
It answers the question: '''When should the next maintenance work be performed?'''
<code>NEXT_DATE </code> is not necessarily the date on which the work package is created.
{| class="wikitable"! Value! Example:|-| <code>NEXT_DATE: </code>| 15 March|-| <code>LEAD_DAYS: </code>| 3|-| <code>EARLIEST_GENERATION_DATE: </code>| 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 <code>NEXT_DATE </code> as its <code>PLANNED_START</code>.
=== <code>LEAD_DAYS </code> ===
<code>LEAD_DAYS </code> defines how many days before <code>NEXT_DATE </code> the system may create the work package.
This is used to create work packages before the actual planned execution date.
{| class="wikitable"! Value! Example:|-| <code>NEXT_DATE</code>| 15 March|-| <code>LEAD_DAYS</code>| 3|-| Resulting <code>EARLIEST_GENERATION_DATE</code>| 12 March|}
<code>EARLIEST_GENERATION_DATE </code> is calculated by the system.
It defines the earliest date on which the maintenance plan may create a work package.
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>
Example:
{| class="wikitable"! Value! Example|-| <code>NEXT_DATE: </code>| 15 March|-| <code>LEAD_DAYS: </code>| 3|-| <code>EARLIEST_GENERATION_DATE: </code>| 12 March|}
The maintenance planning orchestrator searches for active plans where <code>EARLIEST_GENERATION_DATE </code> has been reached.
A plan can be considered for automatic work package generation when:
<pre>
EARLIEST_GENERATION_DATE <= current date
</pre>
If <code>EARLIEST_GENERATION_DATE </code> has not yet been reached, no work package is created.
=== <code>PLAN_STATUS </code> ===
<code>PLAN_STATUS </code> 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.
If <code>AUTO_CREATE defines whether </code> is disabled, the system is allowed to plan does not automatically create work packages from the maintenance plan.
This property is especially important for completion-based scheduling.
{| class="wikitable" style= Work "width: 100%;"! Property! Used on! Purpose|-| <code>LK_MAINTENANCE_PLAN</code>| Generated work package properties used by | Links the generated work package back to the maintenance planning ==plan that triggered its creation.|-| <code>LK_WP_TMPL</code>| Generated work package| Stores the template work package that was used to create the generated work package.|-| <code>LK_ASSET</code>| Generated work package| Stores the asset for which the work package was created.|-| <code>PLANNED_START</code>| Generated work package| Stores the planned start date of the generated work package.|-| <code>ORGA_STATUS</code>| Generated work package| Used to determine whether a generated work package is finished.|-| <code>TASK_OWNER</code>| Additional round work package| Assigns additional generated work packages to the main round work package.|-| <code>ORDERID</code>| Additional round work package| Can be copied from <code>SYSREL_ROUND_RELATION</code> to structure or order round work packages.|-| <code>GROUPID</code>| Additional round work package| Can be copied from <code>SYSREL_ROUND_RELATION</code> to group round work packages.|}
=== <code>LK_MAINTENANCE_PLAN </code> ===
<code>LK_MAINTENANCE_PLAN </code> 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 <code>LK_MAINTENANCE_PLAN</code>.
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.
=== <code>LK_WP_TMPL </code> ===
On a generated work package, <code>LK_WP_TMPL </code> 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.
=== <code>LK_ASSET </code> ===
On a generated work package, <code>LK_ASSET </code> stores the asset for which the work package was created.
This is usually copied or assigned based on the maintenance plan’s <code>LK_ASSET</code>.
=== <code>PLANNED_START </code> ===
<code>PLANNED_START </code> stores the planned start date of the generated work package.
When a maintenance plan generates a work package, the system sets:
<pre>
generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE
</pre>
=== <code>ORGA_STATUS </code> ===
<code>ORGA_STATUS </code> is used to determine whether a generated work package is finished.
A work package is considered finished when:
<pre>
ORGA_STATUS == 100
</pre>
Open work packages are generated work packages linked to the maintenance plan where:
<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">'''Generation rule:''' A maintenance plan does not create another work package while it still has an open generated work package.</div>
=== <code>TASK_OWNER </code> ===
<code>TASK_OWNER </code> 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 <code>TASK_OWNER</code>.
=== <code>ORDERID </code> and <code>GROUPID </code> ===
<code>ORDERID </code> and <code>GROUPID </code> can be copied from the <code>SYSREL_ROUND_RELATION </code> 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.
=== Purpose ===
A <code>CyclicMaintenancePlan </code> 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.
* perform annual maintenance on a functional location
A cyclic maintenance plan uses <code>RRULE </code> to define the recurrence. It also uses <code>SCHEDULING_MODE </code> to define how future dates are calculated.
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Key concept:''' <code>SCHEDULING_MODE is important because it </code> 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.</div>
The supported scheduling modes are:
* Completion-Based
== CyclicMaintenancePlan properties Properties ==
{| class="wikitable" style== "width: 100%;"! Property! Purpose! Notes|-| <code>RRULE ===</code>| Defines the recurrence pattern.| Must be valid and parseable.|-| <code>RRULE_START_DATE</code>| Defines when the recurrence pattern starts.| Used as the start point for recurrence calculation.|-| <code>RRULE_UNTIL_DATE</code>| Optional end date for the recurrence.| No further occurrences are generated after this date.|-| <code>RRULE_COUNT</code>| Limits how many work packages can be created from the plan.| Further occurrences stop once the count is reached.|-| <code>SCHEDULING_MODE</code>| Defines how <code>NEXT_DATE</code> is calculated.| Supports Calendar-Based and Completion-Based scheduling.|}
=== <code>RRULE </code> === <code>RRULE</code> defines the recurrence pattern of a cyclic maintenance plan.
It describes how often the maintenance should occur.
Examples:
<pre>
FREQ=DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR
FREQ=MONTHLY;BYMONTHDAY=15
</pre>
The system uses <code>RRULE </code> to calculate future planned execution dates.
<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">'''Validation:''' If <code>RRULE </code> is invalid and cannot be parsed, the cyclic maintenance plan is not valid and cannot create work packages.</div>
=== <code>RRULE_START_DATE </code> ===
<code>RRULE_START_DATE </code> defines when the recurrence pattern starts.
The recurrence rule is calculated from this date forward.
Example:
{| class="wikitable"! Setting! Value|-| <code>RRULE_START_DATE: </code>| 01 January|-| <code>RRULE: monthly </code>| Monthly on the 15th|}
The system uses these values to determine valid planned execution dates.
=== <code>RRULE_UNTIL_DATE </code> ===
<code>RRULE_UNTIL_DATE </code> 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.
=== <code>RRULE_COUNT </code> ===
<code>RRULE_COUNT </code> limits how many work packages can be created from the plan.
Example:
{| class="wikitable"! Setting! Value|-| <code>RRULE_COUNT: </code>| 10|}
When the number of related generated work packages reaches <code>RRULE_COUNT</code>, the system no longer calculates new occurrences for the plan.
=== <code>SCHEDULING_MODE </code> ===
<code>SCHEDULING_MODE </code> defines how <code>NEXT_DATE </code> is calculated for a cyclic maintenance plan.
<code>SCHEDULING_MODE </code> is only relevant for concrete maintenance plan types that use recurrence logic, such as <code>CyclicMaintenancePlan </code> and <code>RoundMaintenancePlan</code>.
The supported scheduling modes are:
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 Based Scheduling ==
=== Purpose ===
Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences.
The next planned execution date is calculated according to <code>RRULE </code> and the calendar recurrence.
This means that delays in completing a work package do not automatically shift the whole future schedule.
* quarterly maintenance in fixed maintenance windows
=== How calendarCalendar-based scheduling works Based Scheduling Works ===
In calendar-based scheduling, the system calculates <code>NEXT_DATE </code> 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: calendarCalendar-based scheduling Based Scheduling ===
A pump must be inspected on the 15th of every month.
==== Configuration:====
The system calculates:
<pre>EARLIEST_GENERATION_DATE: = 12 March</pre>
On or after 12 March, the system can create the work package.
Generated work package:
{| class="wikitable"! Property! Value|-| <code>PLANNED_START: </code>| 15 March|}
After the work package is planned, the system can calculate the next occurrence.:
<pre>NEXT_DATE: = 15 April</pre>
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.
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Result:''' The next planned execution date remains 15 late completion does not shift the future schedule to 20 April.</div>
=== Purpose ===
* maintenance where a delay should also delay the next cycle
=== How completionCompletion-based scheduling works Based Scheduling Works ===
In completion-based scheduling, the system recalculates <code>NEXT_DATE </code> 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.
A machine must be serviced every 30 days after the previous service was completed.
==== Configuration==== {| class="wikitable" style="width:100%;"! Setting! Value|-| Plan type| <code>CyclicMaintenancePlan</code>|-| <code>LK_ASSET</code>| Machine 1|-| <code>LK_WP_TMPL</code>| Machine Service Template|-| <code>LK_REPLICATION_CONFIG</code>| Machine Service Replication|-| <code>SCHEDULING_MODE</code>| Completion-Based|-| <code>RRULE</code>| Every 30 days|-| <code>RRULE_START_DATE</code>| 01 March|-| <code>NEXT_DATE</code>| 15 March|-| <code>LEAD_DAYS</code>| 3|-| <code>PLAN_STATUS</code>| Active|-| <code>AUTO_CREATE</code>| Enabled|}
The system calculates:
<pre>EARLIEST_GENERATION_DATE: = 12 March</pre>
On or after 12 March, the system can create the work package.
Generated work package:
{| class="wikitable"! Property! Value|-| <code>PLANNED_START: </code>| 15 March|}
The work package is completed on 20 March.
If the recurrence is every 30 days:
{| class="wikitable"! Value! Example|-| <code>NEXT_DATE: </code>| around 19 April|-| <code>LEAD_DAYS: </code>| 3|-| <code>EARLIEST_GENERATION_DATE: </code>| around 16 April|}
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Result:''' In this mode, the delay from 15 March to 20 March shifts the future schedule.</div>
== Difference between calendarCalendar-based and completionBased vs Completion-based scheduling Based Scheduling ==
The difference is the date that is used as the basis for calculating <code>NEXT_DATE</code>.
{| class="wikitable" style="width: 100%;"! Aspect! Calendar-based scheduling follows the recurrence Based! Completion-Based|-| Basis for <code>NEXT_DATE</code>| Recurrence defined by <code>RRULE.</code>| Actual completion date of the previous generated work package|-| Effect of late completion| Future dates are not automatically shifted| Future dates move with the completion date|-| Typical use case| Fixed maintenance windows, fixed calendar intervals, legal or organizational inspection dates| Service intervals that depend on the actual last maintenance|-| Example| Planned: 15 March<br />Completed: 20 March<br />Next date: 15 April| Planned: 15 March<br />Completed: 20 March<br />Interval: 30 days<br />Next date: around 19 April|}
Calendar-based scheduling should be used when the maintenance must follow fixed planned dates.
Characteristics:
* The plan follows the <code>RRULE </code> calendar pattern.
* Future dates are not automatically shifted just because a work package was completed late.
* <code>NEXT_DATE </code> can be recalculated after planning updates.
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates.
Example:
{| class="wikitable"! Event! Date|-| Planned inspection: | 15 March|-| Completed: | 20 March|-| Next date: | 15 April|}
The future date stays aligned with the calendar recurrence.
=== Completion-based Based ===
Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed.
* The plan waits for completion.
* The completion date is used as the basis for <code>NEXT_DATE</code>.
* If the work is completed late, the future schedule moves.
* It is useful for service intervals that depend on the actual last maintenance.
Example:
{| class="wikitable"! Event! Date|-| 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.
=== Purpose ===
A <code>RoundMaintenancePlan </code> is used for recurring maintenance rounds.
It is a specialized type of cyclic maintenance plan. This means that it also uses <code>RRULE </code> and <code>SCHEDULING_MODE</code>.
In addition to the cyclic scheduling logic, a round maintenance plan includes child maintenance plans linked via <code>SYSREL_ROUND_RELATION</code>.
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 <code>SYSREL_ROUND_RELATION</code>.
Example:
Generated main work package:
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 Properties and relations Relations ==
{| class="wikitable" style== "width: 100%;"! Property / relation! Purpose! Notes|-| <code>SYSREL_ROUND_RELATION ===</code>| Links the round maintenance plan to its child maintenance plans.| Child plans define additional work packages created as part of the round.|-| <code>PLAN_SELECTION_RULE</code>| Exists on <code>RoundMaintenancePlan</code>.| Runtime behavior must be verified before documenting further effects.|-| <code>ORDERID</code>| Can exist on the relation between the round plan and a child plan.| Can be copied to generated work packages.|-| <code>GROUPID</code>| Can exist on the relation between the round plan and a child plan.| Can be copied to generated work packages.|}
=== <code>SYSREL_ROUND_RELATION </code> === <code>SYSREL_ROUND_RELATION</code> 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 <code>LK_WP_TMPL</code>* one additional work package for each child maintenance plan linked via <code>SYSREL_ROUND_RELATION</code>
The child maintenance plans do not need to be due themselves for the round maintenance plan to use them during round generation.
=== <code>PLAN_SELECTION_RULE </code> === PLAN_SELECTION_RULE exists on RoundMaintenancePlan.
<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">'''Open point:''' The exact runtime effect of <code>PLAN_SELECTION_RULE</code> should be documented after the implementation behavior has been verified. Until that behavior is confirmed, the wiki should not claim that <code>PLAN_SELECTION_RULE </code> filters child plans by due date, asset, or priority.</div>
=== <code>ORDERID </code> and <code>GROUPID </code> ===
The relation between the round maintenance plan and a linked child maintenance plan can contain <code>ORDERID </code> and <code>GROUPID</code>.
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 Calculated or updated Updated by the system System ==
{| class="wikitable" style== "width: 100%;"! Property / link! System behavior|-| <code>EARLIEST_GENERATION_DATE ===</code>| Calculated from <code>NEXT_DATE</code> and <code>LEAD_DAYS</code>.|-| <code>NEXT_DATE</code>| Calculated or recalculated for <code>CyclicMaintenancePlan</code> and <code>RoundMaintenancePlan</code>.|-| <code>LAST_DATE</code>| Updated when a generated work package is completed.|-| <code>PLANNED_START</code>| Set on generated work packages from the maintenance plan’s <code>NEXT_DATE</code>.|-| Links on generated work packages| Required links are set automatically during generation.|}
=== <code>EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.</code> ===
<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>
This value is recalculated when:
* <code>NEXT_DATE </code> changes* <code>LEAD_DAYS </code> changes* <code>NEXT_DATE </code> is recalculated after planning or completion* recurrence settings cause a new <code>NEXT_DATE </code> to be calculated
=== <code>NEXT_DATE </code> ===
For <code>CyclicMaintenancePlan </code> and <code>RoundMaintenancePlan</code>, <code>NEXT_DATE </code> can be calculated or recalculated by the system.
The calculation depends on:
* <code>RRULE</code>* <code>RRULE_START_DATE</code>* <code>RRULE_UNTIL_DATE</code>* <code>RRULE_COUNT</code>* <code>SCHEDULING_MODE</code>
* related generated work packages
* planning events
* completion events
For calendar-based scheduling, <code>NEXT_DATE </code> is calculated from the recurrence pattern and the highest relevant planned or finished date of related generated work packages.
For completion-based scheduling, <code>NEXT_DATE </code> is calculated from the completion date of the previous generated work package.
=== <code>LAST_DATE </code> ===
<code>LAST_DATE </code> 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.
=== <code>PLANNED_START </code> on generated work packages Generated Work Packages ===
When the system generates a work package from a maintenance plan, it sets the generated work package’s <code>PLANNED_START </code> to the maintenance plan’s <code>NEXT_DATE</code>.
Example:
<pre>
MaintenancePlan.NEXT_DATE: 15 March
Generated WorkPackage.PLANNED_START: 15 March
</pre>
=== Links on generated work packages 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 <code>LK_MAINTENANCE_PLAN</code>* the template work package via <code>LK_WP_TMPL</code>* the assigned asset via <code>LK_ASSET</code>
For round maintenance plans, additional generated work packages from linked child maintenance plans are assigned to the main round work package via <code>TASK_OWNER</code>.
== Properties and events that trigger recalculation Events That Trigger Recalculation ==
{| class="wikitable" style== "width: 100%;"! Trigger! Recalculation behavior|-| <code>NEXT_DATE </code> changed ===| Recalculates <code>EARLIEST_GENERATION_DATE</code>.|-| <code>LEAD_DAYS</code> changed| Recalculates <code>EARLIEST_GENERATION_DATE</code>.|-| <code>RRULE</code> changed| Recalculates <code>NEXT_DATE</code> based on the new recurrence rule and selected <code>SCHEDULING_MODE</code>.|-| <code>RRULE_START_DATE</code> changed| Recalculates the schedule and may change <code>NEXT_DATE</code>.|-| <code>RRULE_UNTIL_DATE</code> changed| Checks whether future occurrences are still available.|-| <code>RRULE_COUNT</code> changed| Checks whether the maximum number of generated work packages has already been reached.|-| <code>SCHEDULING_MODE</code> changed| Recalculates <code>NEXT_DATE</code> according to the selected scheduling mode.|-| Generated work package <code>PLANNED_START</code> changed| Notifies the linked maintenance plan and may trigger date recalculation.|-| Generated work package completed| Updates <code>LAST_DATE</code> and recalculates <code>NEXT_DATE</code> according to <code>SCHEDULING_MODE</code>.|}
<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>
=== <code>LEAD_DAYS changed </code> Changed ===
When <code>LEAD_DAYS </code> changes, the system recalculates <code>EARLIEST_GENERATION_DATE</code>. Formula:
<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>
=== <code>RRULE changed </code> Changed ===
When <code>RRULE </code> changes, the recurrence pattern changes.
The system recalculates <code>NEXT_DATE </code> based on the new recurrence rule and the selected <code>SCHEDULING_MODE</code>.
After <code>NEXT_DATE </code> is recalculated, <code>EARLIEST_GENERATION_DATE </code> is recalculated as well.
=== <code>RRULE_START_DATE changed </code> Changed ===
When <code>RRULE_START_DATE </code> changes, the start point of the recurrence changes.
The system recalculates the schedule. This can change <code>NEXT_DATE</code>.
The system checks whether future occurrences are still available.
If no further occurrence is possible because of <code>RRULE_UNTIL_DATE</code>, the system cannot calculate a new <code>NEXT_DATE</code>.
=== <code>RRULE_COUNT changed </code> Changed ===
When <code>RRULE_COUNT </code> 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 <code>RRULE_COUNT</code>, the system does not calculate further occurrences.
=== <code>SCHEDULING_MODE changed </code> Changed ===
When <code>SCHEDULING_MODE </code> 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 <code>NEXT_DATE </code> from the completion of the previous generated work package.
Because this changes the calculation logic, the system recalculates <code>NEXT_DATE </code> according to the selected <code>SCHEDULING_MODE</code>.
If <code>NEXT_DATE </code> changes, <code>EARLIEST_GENERATION_DATE </code> is recalculated as well.
=== Generated work package Work Package <code>PLANNED_START changed </code> Changed ===
When <code>PLANNED_START </code> 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 <code>NEXT_DATE</code>. The system uses the planning information to continue the calendar-based recurrence.
When a generated work package is completed, the work package notifies the linked maintenance plan.
A work package is considered completed when:
<pre>
ORGA_STATUS == 100
</pre>
The system updates <code>LAST_DATE</code>. Then the system recalculates <code>NEXT_DATE </code> according to <code>SCHEDULING_MODE</code>.
For calendar-based scheduling:
* the system continues according to the calendar recurrence
* <code>NEXT_DATE </code> 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
* <code>NEXT_DATE </code> is calculated from the completion date
After <code>NEXT_DATE </code> is updated, <code>EARLIEST_GENERATION_DATE </code> is recalculated.
== Work package generation logic Package Generation Logic ==
=== When is Is a plan ready Plan Ready to create Create a work packageWork Package? ===
A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled.
{| class="wikitable" style="width: 100%;"! Requirement! Condition! Notes|-| Plan validity| The plan must be valid. | For cyclic maintenance plans, this means: * RRULE is requires a valid* LK_ASSET is <code>RRULE</code>, assigned* NEXT_DATE is <code>LK_ASSET</code>, and available<code>NEXT_DATE</code>.|-The plan must be active:| Plan status| <code>PLAN_STATUS == Active</code>| Inactive plans are ignored.|-| Automatic generation| <code>AUTO_CREATE </code> must be enabled.| If disabled, the plan does not automatically create work packages.A template |-| Template work package must be assigned: | <code>LK_WP_TMPL </code> must be set. A replication configuration | The linked work package must be assigned:a template work package.|-| Replication configuration| <code>LK_REPLICATION_CONFIG </code> must be set.| Required to copy the template work package.The earliest |-| Earliest generation date must be reached: | <code>EARLIEST_GENERATION_DATE <= current date</code>| The plan may only generate once the earliest generation date has been reached.There must be no |-| Open work packages| No open generated work package may exist for the plan. This means there | There must be no generated work package linked via <code>LK_MAINTENANCE_PLAN </code> where <code>ORGA_STATUS != 100</code>.|}
== Round work package generation 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 <code>SYSREL_ROUND_RELATION</code>.
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 <code>TASK_OWNER</code>.
For child plans used in a round, the system does not care whether the child plan:
* has <code>PLAN_STATUS == Active</code>* has <code>AUTO_CREATE == true</code>* has a valid <code>RRULE</code>* has a valid <code>NEXT_DATE</code>* is due based on its own <code>EARLIEST_GENERATION_DATE</code>
<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">'''Rule:''' The round plan controls the timing. The child plans define what additional work packages should be created as part of the round.</div>
{{UnderConstructionEnd}}
