MRO Maintenance Planning

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.

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.

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.

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:

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.

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

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.

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

Requirement: LK_WP_TMPL must be configured before the maintenance plan can 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

Requirement: LK_REPLICATION_CONFIG must be configured before the maintenance plan can 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.

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.

Value	Example
NEXT_DATE	15 March
LEAD_DAYS	3
Resulting EARLIEST_GENERATION_DATE	12 March

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.

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.

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

Example:

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:

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.

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.

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.

Open point: The exact effect of PLAN_SELECTION_RULE should only be documented after the implementation behavior has been verified.

Work Package Properties Used by Maintenance Planning

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:

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

Generation rule: 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.

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.

The supported scheduling modes are:

Calendar-Based
Completion-Based

CyclicMaintenancePlan Properties

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:

FREQ=DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR
FREQ=MONTHLY;BYMONTHDAY=15

The system uses RRULE to calculate future planned execution dates.

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

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:

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:

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

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:

EARLIEST_GENERATION_DATE = 12 March

On or after 12 March, the system can create the work package.

Generated work package:

Property	Value
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.

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

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

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:

EARLIEST_GENERATION_DATE = 12 March

On or after 12 March, the system can create the work package.

Generated work package:

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:

Value	Example
NEXT_DATE	around 19 April
LEAD_DAYS	3
EARLIEST_GENERATION_DATE	around 16 April

Result: In this mode, the delay from 15 March to 20 March shifts the future schedule.

Calendar-Based vs Completion-Based Scheduling

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

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:

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:

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.

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.

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:

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

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.

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.

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

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.

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

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.

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

LEAD_DAYS Changed

When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.

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.

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.

Generation rule: The open work package check 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

Rule: The round plan controls the timing. The child plans define what additional work packages should be created as part of the round.

MROMaintenancePlans

Contents

MRO Maintenance Planning

Overview

Basic Concept

Maintenance Plan

Template Work Package

Replication Configuration

Generated Work Package

MaintenancePlan Base Class

Purpose

Base Class Properties

LK_ASSET

LK_WP_TMPL

LK_REPLICATION_CONFIG

NEXT_DATE

LEAD_DAYS

EARLIEST_GENERATION_DATE

PLAN_STATUS

AUTO_CREATE

LAST_DATE

PRIORITY

Work Package Properties Used by Maintenance Planning

LK_MAINTENANCE_PLAN

LK_WP_TMPL

LK_ASSET

PLANNED_START

ORGA_STATUS

TASK_OWNER

ORDERID and GROUPID

CyclicMaintenancePlan

Purpose

CyclicMaintenancePlan Properties

RRULE

RRULE_START_DATE

RRULE_UNTIL_DATE

RRULE_COUNT

SCHEDULING_MODE

Calendar-Based Scheduling

Purpose

How Calendar-Based Scheduling Works

Example: Calendar-Based Scheduling

Configuration

Result

Completion-Based Scheduling

Purpose

How Completion-Based Scheduling Works

Example: Completion-Based Scheduling

Configuration

Result

Calendar-Based vs Completion-Based Scheduling

Calendar-Based

Completion-Based

RoundMaintenancePlan

Purpose

Generated Result

RoundMaintenancePlan Properties and Relations

SYSREL_ROUND_RELATION

PLAN_SELECTION_RULE

ORDERID and GROUPID

Properties Calculated or Updated by the System

EARLIEST_GENERATION_DATE

NEXT_DATE

LAST_DATE

PLANNED_START on Generated Work Packages

Links on Generated Work Packages

Properties and Events That Trigger Recalculation

NEXT_DATE Changed

LEAD_DAYS Changed

RRULE Changed

RRULE_START_DATE Changed

RRULE_UNTIL_DATE Changed

RRULE_COUNT Changed

SCHEDULING_MODE Changed

Generated Work Package PLANNED_START Changed

Generated Work Package Completed

Work Package Generation Logic

When Is a Plan Ready to Create a Work Package?

Round Work Package Generation

See also