MRO Material Management

2026-06-17T14:23:58Z

LMA:

2026-06-16T12:18:40Z

LMA:

MROMaintenancePlans

2026-06-16T07:30:36Z

LMA:

{{UnderConstructionStart}}
= MRO Maintenance Planning =

<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>

== Overview ==

A maintenance plan defines the rules for creating work packages. These rules include:

* 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, 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.

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.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' 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.
</div>

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:

{| class="wikitable" style="width: 100%;"
! Part
! Description
|-
| MaintenancePlan
| Defines the rules for creating generated work packages.
|-
| Template work package
| Defines what the generated work package should look like.
|-
| Replication configuration
| Defines how the template work package is copied.
|-
| Generated work package
| The actual work package created by the maintenance plan.
|}

=== 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.

It is the source work package that is copied when the maintenance plan creates a new work package.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Rule:''' Only work packages with ISTEMPLATE set can be used as template work packages.
</div>

=== 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
* 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 link 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 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.

=== Base Class Properties ===

{| class="wikitable" style="width: 100%;"
! Property
! Purpose
! Notes
|-
| LK_ASSET
| Links the maintenance plan to the asset that requires maintenance.
| Required for a valid cyclic maintenance plan.
|-
| LK_WP_TMPL
| Links the maintenance plan to the template work package.
| The linked work package must have ISTEMPLATE set.
|-
| LK_REPLICATION_CONFIG
| Links the maintenance plan to the replication configuration.
| Required for work package generation.
|-
| NEXT_DATE
| Defines the planned execution date of the next maintenance activity.
| Used as PLANNED_START on generated work packages.
|-
| LEAD_DAYS
| Defines how many days before NEXT_DATE the system may create the work package.
| Does not define the recurrence interval.
|-
| EARLIEST_GENERATION_DATE
| Defines the earliest date on which the maintenance plan may create a work package.
| Calculated by the system.
|-
| PLAN_STATUS
| Defines whether the maintenance plan is active or inactive.
| Only active plans are considered for automatic generation.
|-
| AUTO_CREATE
| Defines whether the system is allowed to automatically create work packages.
| If disabled, the plan does not automatically create work packages.
|-
| LAST_DATE
| Stores the most recent completion date of a generated work package linked to the maintenance plan.
| Especially relevant for completion-based scheduling.
|-
| PRIORITY
| Numeric value that can be used to sort maintenance plans.
| For round maintenance plans, see also PLAN_SELECTION_RULE.
|}

=== 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.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Requirement:''' A cyclic maintenance plan requires LK_ASSET to be assigned in order to be valid.
</div>

=== 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.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Requirement:''' LK_WP_TMPL must be configured before the maintenance plan can create a work package.
</div>

=== 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

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Requirement:''' LK_REPLICATION_CONFIG must be configured before the maintenance plan can create a work package.
</div>

=== 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.

{| class="wikitable"
! Value
! 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.

{| class="wikitable"
! Value
! Example
|-
| NEXT_DATE
| 15 March
|-
| LEAD_DAYS
| 3
|-
| Resulting EARLIEST_GENERATION_DATE
| 12 March
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Note:''' LEAD_DAYS does not define the recurrence interval. It only defines how early the work package may be generated before the planned execution date.
</div>

=== 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.

<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>

Example:

{| class="wikitable"
! Value
! 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:

<pre>
EARLIEST_GENERATION_DATE <= current date
</pre>

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.

Typical values are:

* Inactive
* Active

This allows users to temporarily disable a maintenance plan without deleting it.

=== 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.

{| class="wikitable"
! Value
! 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.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The exact effect of PLAN_SELECTION_RULE should only be documented after the implementation behavior has been verified.
</div>

== Work Package Properties Used by Maintenance Planning ==

{| class="wikitable" style="width: 100%;"
! Property
! Used on
! Purpose
|-
| LK_MAINTENANCE_PLAN
| Generated work package
| Links the generated work package back to the maintenance plan that triggered its creation.
|-
| LK_WP_TMPL
| Generated work package
| Stores the template work package that was used to create the generated work package.
|-
| LK_ASSET
| Generated work package
| Stores the asset for which the work package was created.
|-
| PLANNED_START
| Generated work package
| Stores the planned start date of the generated work package.
|-
| ORGA_STATUS
| Generated work package
| Used to determine whether a generated work package is finished.
|-
| TASK_OWNER
| Additional round work package
| Assigns additional generated work packages to the main round work package.
|-
| ORDERID
| Additional round work package
| Can be copied from SYSREL_ROUND_RELATION to structure or order round work packages.
|-
| GROUPID
| Additional round work package
| Can be copied from SYSREL_ROUND_RELATION to group round work packages.
|}

=== 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:

<pre>
generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE
</pre>

=== ORGA_STATUS ===

ORGA_STATUS 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:

<pre>
ORGA_STATUS != 100
</pre>

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; 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>

=== 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.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Key concept:''' SCHEDULING_MODE 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:

* Calendar-Based
* Completion-Based

== CyclicMaintenancePlan Properties ==

{| class="wikitable" style="width: 100%;"
! Property
! Purpose
! Notes
|-
| RRULE
| Defines the recurrence pattern.
| Must be valid and parseable.
|-
| RRULE_START_DATE
| Defines when the recurrence pattern starts.
| Used as the start point for recurrence calculation.
|-
| RRULE_UNTIL_DATE
| Optional end date for the recurrence.
| No further occurrences are generated after this date.
|-
| RRULE_COUNT
| Limits how many work packages can be created from the plan.
| Further occurrences stop once the count is reached.
|-
| SCHEDULING_MODE
| Defines how NEXT_DATE is calculated.
| Supports Calendar-Based and Completion-Based scheduling.
|}

=== RRULE ===

RRULE 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 RRULE to calculate future planned execution dates.

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Problem:''' If RRULE is invalid and cannot be parsed, the cyclic maintenance plan is not valid and cannot create work packages.
</div>

=== RRULE_START_DATE ===

RRULE_START_DATE defines when the recurrence pattern starts.

The recurrence rule is calculated from this date forward.

Example:

{| class="wikitable"
! Setting
! Value
|-
| 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:

{| class="wikitable"
! Setting
! Value
|-
| 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:

{| class="wikitable"
! Scheduling mode
! Description
|-
| Calendar-Based
| Future dates follow the recurrence pattern defined by RRULE.
|-
| Completion-Based
| Future dates are calculated from the actual completion date of the previous generated work package.
|}

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 ====

{| class="wikitable" style="width: 100%;"
! Setting
! Value
|-
| 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
|}

==== Result ====

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
|-
| PLANNED_START
| 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 late completion does not shift the future schedule to 20 April.
</div>

== 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.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' The plan waits for the generated work package to be completed. Then the system calculates the next date from the completion date.
</div>

=== Example: Completion-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
| 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
|}

==== Result ====

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
|-
| 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:

{| class="wikitable"
! Value
! Example
|-
| NEXT_DATE
| around 19 April
|-
| LEAD_DAYS
| 3
|-
| EARLIEST_GENERATION_DATE
| 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>

== Calendar-Based vs Completion-Based Scheduling ==

The difference is the date that is used as the basis for calculating NEXT_DATE.

{| class="wikitable" style="width: 100%;"
! Aspect
! Calendar-Based
! Completion-Based
|-
| Basis for NEXT_DATE
| Recurrence defined by RRULE
| 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 Completed: 20 March Next date: 15 April
| Planned: 15 March Completed: 20 March Interval: 30 days Next date: around 19 April
|}

=== 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:

{| 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 ===

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:

{| 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.

== 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.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Important for child plans:''' 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.
</div>

The important configuration on the child plans is their work package generation setup, especially the configured template work package and replication setup.

=== Generated Result ===

Example:

{| class="wikitable" style="width: 100%;"
! Element
! Example
|-
| Round maintenance plan
| Machine Room Round
|-
| Linked child plan 1
| Pump 1 Inspection
|-
| Linked child plan 2
| Pump 2 Inspection
|-
| Linked child plan 3
| 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 ==

{| class="wikitable" style="width: 100%;"
! Property / relation
! Purpose
! Notes
|-
| SYSREL_ROUND_RELATION
| Links the round maintenance plan to its child maintenance plans.
| Child plans define additional work packages created as part of the round.
|-
| PLAN_SELECTION_RULE
| Exists on RoundMaintenancePlan.
| Runtime behavior must be verified before documenting further effects.
|-
| ORDERID
| Can exist on the relation between the round plan and a child plan.
| Can be copied to generated work packages.
|-
| GROUPID
| Can exist on the relation between the round plan and a child plan.
| Can be copied to generated work packages.
|}

=== 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.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The exact runtime effect of PLAN_SELECTION_RULE 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.
</div>

=== 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 ==

{| class="wikitable" style="width: 100%;"
! Property / link
! System behavior
|-
| EARLIEST_GENERATION_DATE
| Calculated from NEXT_DATE and LEAD_DAYS.
|-
| NEXT_DATE
| Calculated or recalculated for CyclicMaintenancePlan and RoundMaintenancePlan.
|-
| LAST_DATE
| Updated when a generated work package is completed.
|-
| PLANNED_START
| Set on generated work packages from the maintenance plan’s NEXT_DATE.
|-
| Links on generated work packages
| Required links are set automatically during generation.
|}

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.

<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>

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:

<pre>
MaintenancePlan.NEXT_DATE: 15 March
Generated WorkPackage.PLANNED_START: 15 March
</pre>

=== 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 ==

{| class="wikitable" style="width: 100%;"
! Trigger
! Recalculation behavior
|-
| NEXT_DATE changed
| Recalculates EARLIEST_GENERATION_DATE.
|-
| LEAD_DAYS changed
| Recalculates EARLIEST_GENERATION_DATE.
|-
| RRULE changed
| Recalculates NEXT_DATE based on the new recurrence rule and selected SCHEDULING_MODE.
|-
| RRULE_START_DATE changed
| Recalculates the schedule and may change NEXT_DATE.
|-
| RRULE_UNTIL_DATE changed
| Checks whether future occurrences are still available.
|-
| RRULE_COUNT changed
| Checks whether the maximum number of generated work packages has already been reached.
|-
| SCHEDULING_MODE changed
| Recalculates NEXT_DATE according to the selected scheduling mode.
|-
| Generated work package PLANNED_START changed
| Notifies the linked maintenance plan and may trigger date recalculation.
|-
| Generated work package completed
| Updates LAST_DATE and recalculates NEXT_DATE according to SCHEDULING_MODE.
|}

=== NEXT_DATE Changed ===

When NEXT_DATE changes, the system recalculates EARLIEST_GENERATION_DATE.

<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>

=== LEAD_DAYS Changed ===

When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.

<pre>
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS
</pre>

=== 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:

<pre>
ORGA_STATUS == 100
</pre>

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.

{| class="wikitable" style="width: 100%;"
! Requirement
! Condition
! Notes
|-
| Plan validity
| The plan must be valid.
| For cyclic maintenance plans, this requires a valid RRULE, assigned LK_ASSET, and available NEXT_DATE.
|-
| Plan status
| PLAN_STATUS == Active
| Inactive plans are ignored.
|-
| Automatic generation
| AUTO_CREATE must be enabled.
| If disabled, the plan does not automatically create work packages.
|-
| Template work package
| LK_WP_TMPL must be set.
| The linked work package must be a template work package.
|-
| Replication configuration
| LK_REPLICATION_CONFIG must be set.
| Required to copy the template work package.
|-
| Earliest generation date
| EARLIEST_GENERATION_DATE <= current date
| The plan may only generate once the earliest generation date has been reached.
|-
| Open work packages
| No open generated work package may exist for the plan.
| There must be no generated work package linked via LK_MAINTENANCE_PLAN where ORGA_STATUS != 100.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Generation rule:''' The open work package check prevents the system from creating multiple open work packages for the same maintenance plan.
</div>

== 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

<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>

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]

{{UnderConstructionEnd}}

MROMaintenancePlans

2026-06-15T05:47:20Z

LMA: /* See also */