Difference between revisions of "MROMaintenancePlans"
(Created page with "{{UnderConstructionStart}} == MRO Maintenance Planning == The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work p...") |
|||
| Line 1: | Line 1: | ||
{{UnderConstructionStart}} | {{UnderConstructionStart}} | ||
| − | + | = MRO Maintenance Planning = | |
| − | The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans. | + | <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: | |
| − | 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 | + | * 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. | ||
The fully implemented maintenance plan types in standard MRO are: | The fully implemented maintenance plan types in standard MRO are: | ||
| − | * CyclicMaintenancePlan | + | * <code>CyclicMaintenancePlan</code> |
| − | * RoundMaintenancePlan | + | * <code>RoundMaintenancePlan</code> |
| − | 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. | + | 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. |
| − | 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 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> | ||
| − | 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. | + | <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 | + | == Basic Concept == |
The maintenance planning feature is built around four main parts: | The maintenance planning feature is built around four main parts: | ||
| − | + | {| class="wikitable" style="width: 100%;" | |
| − | + | ! Part | |
| − | + | ! Description | |
| − | + | |- | |
| + | | <code>MaintenancePlan</code> | ||
| + | | 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 | + | === Maintenance Plan === |
The maintenance plan defines the rules for creating work packages. | The maintenance plan defines the rules for creating work packages. | ||
| Line 43: | Line 68: | ||
* whether future dates are calculated calendar-based or completion-based | * whether future dates are calculated calendar-based or completion-based | ||
| − | === Template | + | === Template Work Package === |
The template work package defines what the generated work package should look like. | 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. | |
| − | Only work packages with ISTEMPLATE set can be used as template work packages. | + | <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 | + | === Replication Configuration === |
The replication configuration defines how the template work package is copied. | The replication configuration defines how the template work package is copied. | ||
| − | This includes, for example | + | This includes, for example: |
| − | === Generated | + | * 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. | The generated work package is the actual result created by the maintenance plan. | ||
| Line 63: | Line 94: | ||
Example: | Example: | ||
| − | A pump has to be inspected every month. | + | # 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>. | ||
| − | + | This link allows the maintenance plan to react when the generated work package is planned or completed. | |
| − | + | == MaintenancePlan Base Class == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | == MaintenancePlan | + | |
=== Purpose === | === Purpose === | ||
| − | MaintenancePlan is the abstract base class for maintenance planning in MRO. | + | <code>MaintenancePlan</code> is the abstract base class for maintenance planning in MRO. |
| − | It provides the common properties and logic | + | 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. | + | 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: |
| − | + | * <code>CyclicMaintenancePlan</code> | |
| − | + | * <code>RoundMaintenancePlan</code> | |
| − | * 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. | Developers can derive from the abstract base class if a project requires a custom maintenance plan type. In that case, the custom implementation must provide the missing plan-specific behavior. | ||
| − | === LK_ASSET === | + | === 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> === | ||
| − | LK_ASSET is the link to the asset that requires maintenance. | + | <code>LK_ASSET</code> is the link to the asset that requires maintenance. |
This can be, for example: | This can be, for example: | ||
| Line 96: | Line 173: | ||
* equipment | * equipment | ||
* a functional location | * a functional location | ||
| − | * another customized maintainable object deriving from Asset | + | * another customized maintainable object deriving from <code>Asset</code> |
The generated work package is linked to the same asset. | The generated work package is linked to the same asset. | ||
| − | A cyclic maintenance plan requires LK_ASSET to be assigned in order to be valid. | + | <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> | ||
| − | === LK_WP_TMPL === | + | === <code>LK_WP_TMPL</code> === |
| − | LK_WP_TMPL is the link to the template work package. | + | <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. | 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. | + | 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 ISTEMPLATE property must be set. | + | The linked work package must be a template work package. This means its <code>ISTEMPLATE</code> property must be set. |
| − | If LK_WP_TMPL is not configured, the maintenance plan cannot create a work package. | + | <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> | ||
| − | === LK_REPLICATION_CONFIG === | + | === <code>LK_REPLICATION_CONFIG</code> === |
| − | LK_REPLICATION_CONFIG is the link to the replication configuration. | + | <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. | The replication configuration defines how the template work package is copied into a generated work package. | ||
| Line 126: | Line 207: | ||
* what the target meta class of the generated work package should be | * what the target meta class of the generated work package should be | ||
| − | If LK_REPLICATION_CONFIG is not configured, the maintenance plan cannot create a work package. | + | <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> | ||
| − | === NEXT_DATE === | + | === <code>NEXT_DATE</code> === |
| − | NEXT_DATE defines the planned execution date of the next maintenance activity. | + | <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? | + | 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. | + | <code>NEXT_DATE</code> is not necessarily the date on which the work package is created. |
| − | Example | + | {| class="wikitable" |
| − | + | ! Value | |
| − | NEXT_DATE | + | ! Example |
| − | LEAD_DAYS | + | |- |
| − | EARLIEST_GENERATION_DATE | + | | <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. | 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. | + | 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>. |
| − | === LEAD_DAYS === | + | === <code>LEAD_DAYS</code> === |
| − | LEAD_DAYS defines how many days before NEXT_DATE the system may create the work package. | + | <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. | This is used to create work packages before the actual planned execution date. | ||
| − | Example | + | {| class="wikitable" |
| + | ! Value | ||
| + | ! Example | ||
| + | |- | ||
| + | | <code>NEXT_DATE</code> | ||
| + | | 15 March | ||
| + | |- | ||
| + | | <code>LEAD_DAYS</code> | ||
| + | | 3 | ||
| + | |- | ||
| + | | Resulting <code>EARLIEST_GENERATION_DATE</code> | ||
| + | | 12 March | ||
| + | |} | ||
| − | + | <div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;"> | |
| − | + | '''Note:''' <code>LEAD_DAYS</code> does not define the recurrence interval. It only defines how early the work package may be generated before the planned execution date. | |
| + | </div> | ||
| − | + | === <code>EARLIEST_GENERATION_DATE</code> === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === EARLIEST_GENERATION_DATE === | + | |
| − | EARLIEST_GENERATION_DATE is calculated by the system. | + | <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. | It defines the earliest date on which the maintenance plan may create a work package. | ||
| − | + | <pre> | |
| − | + | ||
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | ||
| + | </pre> | ||
Example: | Example: | ||
| − | NEXT_DATE | + | {| class="wikitable" |
| − | LEAD_DAYS | + | ! Value |
| − | EARLIEST_GENERATION_DATE | + | ! 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 EARLIEST_GENERATION_DATE has been reached. | + | 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: | A plan can be considered for automatic work package generation when: | ||
| + | <pre> | ||
EARLIEST_GENERATION_DATE <= current date | EARLIEST_GENERATION_DATE <= current date | ||
| + | </pre> | ||
| − | If EARLIEST_GENERATION_DATE has not yet been reached, no work package is created. | + | If <code>EARLIEST_GENERATION_DATE</code> has not yet been reached, no work package is created. |
| − | === PLAN_STATUS === | + | === <code>PLAN_STATUS</code> === |
| − | PLAN_STATUS defines whether the maintenance plan is active or inactive. | + | <code>PLAN_STATUS</code> defines whether the maintenance plan is active or inactive. |
| − | Only active plans are considered for automatic work package generation. | + | Only active plans are considered for automatic work package generation. Inactive plans are ignored by the maintenance planning process. |
| − | + | Typical values are: | |
| + | |||
| + | * <code>Inactive</code> | ||
| + | * <code>Active</code> | ||
This allows users to temporarily disable a maintenance plan without deleting it. | This allows users to temporarily disable a maintenance plan without deleting it. | ||
| − | + | === <code>AUTO_CREATE</code> === | |
| − | + | <code>AUTO_CREATE</code> defines whether the system is allowed to automatically create work packages from the maintenance plan. | |
| − | + | ||
| − | + | If <code>AUTO_CREATE</code> is enabled, the maintenance planning orchestrator can create work packages once the plan is due. | |
| − | AUTO_CREATE | + | If <code>AUTO_CREATE</code> is disabled, the plan does not automatically create work packages. |
| − | + | === <code>LAST_DATE</code> === | |
| − | + | <code>LAST_DATE</code> stores the date when the most recent generated work package linked to the maintenance plan was completed. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | 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. | This property is especially important for completion-based scheduling. | ||
| − | + | {| class="wikitable" | |
| + | ! Value | ||
| + | ! Example | ||
| + | |- | ||
| + | | Previous generated work package completed | ||
| + | | 20 March | ||
| + | |- | ||
| + | | <code>SCHEDULING_MODE</code> | ||
| + | | Completion-Based | ||
| + | |- | ||
| + | | Next date is calculated from | ||
| + | | 20 March | ||
| + | |} | ||
| − | + | The system updates <code>LAST_DATE</code> when a generated work package is completed. | |
| − | + | === <code>PRIORITY</code> === | |
| − | + | ||
| − | + | ||
| − | + | <code>PRIORITY</code> is a numeric value that can be used to sort maintenance plans. | |
| − | + | For round maintenance plans, there is also a property called <code>PLAN_SELECTION_RULE</code>. | |
| − | + | <div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;"> | |
| + | '''Open point:''' The exact effect of <code>PLAN_SELECTION_RULE</code> 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 | ||
| + | |- | ||
| + | | <code>LK_MAINTENANCE_PLAN</code> | ||
| + | | Generated work package | ||
| + | | Links the generated work package back to the maintenance 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. | ||
| + | |} | ||
| − | === LK_MAINTENANCE_PLAN === | + | === <code>LK_MAINTENANCE_PLAN</code> === |
| − | LK_MAINTENANCE_PLAN is set on generated work packages. | + | <code>LK_MAINTENANCE_PLAN</code> is set on generated work packages. |
It stores the maintenance plan that triggered the creation of the work package. | 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 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. | 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 === | + | === <code>LK_WP_TMPL</code> === |
| − | On a generated work package, LK_WP_TMPL stores the template work package that was used to create the generated work package. | + | 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. | This allows users and the system to see which template was used as the source. | ||
| − | === LK_ASSET === | + | === <code>LK_ASSET</code> === |
| − | On a generated work package, LK_ASSET stores the asset for which the work package was created. | + | 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 LK_ASSET. | + | This is usually copied or assigned based on the maintenance plan’s <code>LK_ASSET</code>. |
| − | === PLANNED_START === | + | === <code>PLANNED_START</code> === |
| − | PLANNED_START stores the planned start date of the generated work package. | + | <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: | When a maintenance plan generates a work package, the system sets: | ||
| + | <pre> | ||
generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE | generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE | ||
| + | </pre> | ||
| − | === ORGA_STATUS === | + | === <code>ORGA_STATUS</code> === |
| − | ORGA_STATUS is used to determine whether a generated work package is finished. | + | <code>ORGA_STATUS</code> is used to determine whether a generated work package is finished. |
A work package is considered finished when: | A work package is considered finished when: | ||
| + | <pre> | ||
ORGA_STATUS == 100 | ORGA_STATUS == 100 | ||
| + | </pre> | ||
| + | |||
| + | Open work packages are generated work packages linked to the maintenance plan where: | ||
| − | + | <pre> | |
| + | ORGA_STATUS != 100 | ||
| + | </pre> | ||
| − | A maintenance plan does not create another work package while it still has an open generated work package. | + | <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> | ||
| − | === TASK_OWNER === | + | === <code>TASK_OWNER</code> === |
| − | TASK_OWNER is used in round maintenance scenarios. | + | <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 TASK_OWNER. | + | 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>. |
| − | === ORDERID and GROUPID === | + | === <code>ORDERID</code> and <code>GROUPID</code> === |
| − | ORDERID and GROUPID can be copied from the SYSREL_ROUND_RELATION relation to generated work packages in a round maintenance scenario. | + | <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. | They can be used to order or group the additional work packages that belong to the generated round work package. | ||
| Line 294: | Line 458: | ||
=== Purpose === | === Purpose === | ||
| − | A CyclicMaintenancePlan is used for recurring maintenance work on an asset. | + | 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. | It is the standard maintenance plan type for maintenance activities that repeat according to a defined recurrence pattern. | ||
| Line 306: | Line 470: | ||
* perform annual maintenance on a functional location | * 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. | + | 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. |
| − | SCHEDULING_MODE | + | <div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;"> |
| + | '''Key concept:''' <code>SCHEDULING_MODE</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: | The supported scheduling modes are: | ||
| Line 315: | Line 481: | ||
* Completion-Based | * Completion-Based | ||
| − | == CyclicMaintenancePlan | + | == CyclicMaintenancePlan 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. | ||
| + | |} | ||
| − | RRULE defines the recurrence pattern of a cyclic maintenance plan. | + | === <code>RRULE</code> === |
| + | |||
| + | <code>RRULE</code> defines the recurrence pattern of a cyclic maintenance plan. | ||
It describes how often the maintenance should occur. | It describes how often the maintenance should occur. | ||
| Line 325: | Line 517: | ||
Examples: | Examples: | ||
| + | <pre> | ||
FREQ=DAILY | FREQ=DAILY | ||
| − | |||
FREQ=WEEKLY;BYDAY=MO,WE,FR | FREQ=WEEKLY;BYDAY=MO,WE,FR | ||
| − | |||
FREQ=MONTHLY;BYMONTHDAY=15 | FREQ=MONTHLY;BYMONTHDAY=15 | ||
| + | </pre> | ||
| − | The system uses RRULE to calculate future planned execution dates. | + | The system uses <code>RRULE</code> to calculate future planned execution dates. |
| − | If RRULE is invalid and cannot be parsed, the cyclic maintenance plan is not valid and cannot create work packages. | + | <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> | ||
| − | === RRULE_START_DATE === | + | === <code>RRULE_START_DATE</code> === |
| − | RRULE_START_DATE defines when the recurrence pattern starts. | + | <code>RRULE_START_DATE</code> defines when the recurrence pattern starts. |
The recurrence rule is calculated from this date forward. | The recurrence rule is calculated from this date forward. | ||
| Line 343: | Line 537: | ||
Example: | Example: | ||
| − | RRULE_START_DATE | + | {| class="wikitable" |
| − | RRULE | + | ! Setting |
| + | ! Value | ||
| + | |- | ||
| + | | <code>RRULE_START_DATE</code> | ||
| + | | 01 January | ||
| + | |- | ||
| + | | <code>RRULE</code> | ||
| + | | Monthly on the 15th | ||
| + | |} | ||
The system uses these values to determine valid planned execution dates. | The system uses these values to determine valid planned execution dates. | ||
| − | === RRULE_UNTIL_DATE === | + | === <code>RRULE_UNTIL_DATE</code> === |
| − | RRULE_UNTIL_DATE is an optional end date for the recurrence. | + | <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. | If this date is configured, no further occurrences are generated after this date. | ||
| Line 356: | Line 558: | ||
This can be used for maintenance plans that should only run until a certain date. | This can be used for maintenance plans that should only run until a certain date. | ||
| − | === RRULE_COUNT === | + | === <code>RRULE_COUNT</code> === |
| − | RRULE_COUNT limits how many work packages can be created from the plan. | + | <code>RRULE_COUNT</code> limits how many work packages can be created from the plan. |
Example: | Example: | ||
| − | RRULE_COUNT | + | {| class="wikitable" |
| + | ! Setting | ||
| + | ! Value | ||
| + | |- | ||
| + | | <code>RRULE_COUNT</code> | ||
| + | | 10 | ||
| + | |} | ||
| − | When the number of related generated work packages reaches RRULE_COUNT, the system no longer calculates new occurrences for the plan. | + | When the number of related generated work packages reaches <code>RRULE_COUNT</code>, the system no longer calculates new occurrences for the plan. |
| − | === SCHEDULING_MODE === | + | === <code>SCHEDULING_MODE</code> === |
| − | SCHEDULING_MODE defines how NEXT_DATE is calculated for a cyclic maintenance plan. | + | <code>SCHEDULING_MODE</code> defines how <code>NEXT_DATE</code> 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. | + | <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: | The supported scheduling modes are: | ||
| − | + | {| class="wikitable" | |
| − | + | ! Scheduling mode | |
| + | ! Description | ||
| + | |- | ||
| + | | Calendar-Based | ||
| + | | Future dates follow the recurrence pattern defined by <code>RRULE</code>. | ||
| + | |- | ||
| + | | 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. | 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- | + | == Calendar-Based Scheduling == |
=== Purpose === | === Purpose === | ||
| Line 385: | Line 601: | ||
Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences. | 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. | + | 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. | This means that delays in completing a work package do not automatically shift the whole future schedule. | ||
| Line 398: | Line 614: | ||
* quarterly maintenance in fixed maintenance windows | * quarterly maintenance in fixed maintenance windows | ||
| − | === How | + | === 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. | + | 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. | + | 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. |
| − | + | ||
| − | 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. | This means the schedule continues according to the recurrence pattern. | ||
| Line 410: | Line 624: | ||
If a work package is completed later than planned, the future schedule does not necessarily move with that completion date. | If a work package is completed later than planned, the future schedule does not necessarily move with that completion date. | ||
| − | === Example: | + | === Example: Calendar-Based Scheduling === |
A pump must be inspected on the 15th of every month. | A pump must be inspected on the 15th of every month. | ||
| − | Configuration | + | ==== Configuration ==== |
| − | + | {| class="wikitable" style="width: 100%;" | |
| − | LK_ASSET | + | ! Setting |
| − | LK_WP_TMPL | + | ! Value |
| − | LK_REPLICATION_CONFIG | + | |- |
| − | SCHEDULING_MODE | + | | Plan type |
| − | RRULE | + | | <code>CyclicMaintenancePlan</code> |
| − | RRULE_START_DATE | + | |- |
| − | NEXT_DATE | + | | <code>LK_ASSET</code> |
| − | LEAD_DAYS | + | | Pump 1 |
| − | PLAN_STATUS | + | |- |
| − | AUTO_CREATE | + | | <code>LK_WP_TMPL</code> |
| + | | Pump Inspection Template | ||
| + | |- | ||
| + | | <code>LK_REPLICATION_CONFIG</code> | ||
| + | | Pump Inspection Replication | ||
| + | |- | ||
| + | | <code>SCHEDULING_MODE</code> | ||
| + | | Calendar-Based | ||
| + | |- | ||
| + | | <code>RRULE</code> | ||
| + | | Monthly on the 15th | ||
| + | |- | ||
| + | | <code>RRULE_START_DATE</code> | ||
| + | | 01 January | ||
| + | |- | ||
| + | | <code>NEXT_DATE</code> | ||
| + | | 15 March | ||
| + | |- | ||
| + | | <code>LEAD_DAYS</code> | ||
| + | | 3 | ||
| + | |- | ||
| + | | <code>PLAN_STATUS</code> | ||
| + | | Active | ||
| + | |- | ||
| + | | <code>AUTO_CREATE</code> | ||
| + | | Enabled | ||
| + | |} | ||
| + | |||
| + | ==== Result ==== | ||
The system calculates: | The system calculates: | ||
| − | EARLIEST_GENERATION_DATE | + | <pre> |
| + | EARLIEST_GENERATION_DATE = 12 March | ||
| + | </pre> | ||
On or after 12 March, the system can create the work package. | On or after 12 March, the system can create the work package. | ||
| Line 436: | Line 680: | ||
Generated work package: | Generated work package: | ||
| − | PLANNED_START | + | {| class="wikitable" |
| + | ! Property | ||
| + | ! Value | ||
| + | |- | ||
| + | | <code>PLANNED_START</code> | ||
| + | | 15 March | ||
| + | |} | ||
| − | After the work package is planned, the system can calculate the next occurrence | + | After the work package is planned, the system can calculate the next occurrence: |
| − | NEXT_DATE | + | <pre> |
| + | NEXT_DATE = 15 April | ||
| + | </pre> | ||
| − | If the March work package is completed on 20 March, the next date still follows the monthly recurrence. | + | If the March work package is completed on 20 March, the next date still follows the monthly recurrence. The next planned execution date remains 15 April. |
| − | The | + | <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 == | |
| − | + | ||
| − | == Completion- | + | |
=== Purpose === | === Purpose === | ||
| Line 465: | Line 717: | ||
* maintenance where a delay should also delay the next cycle | * maintenance where a delay should also delay the next cycle | ||
| − | === How | + | === How Completion-Based Scheduling Works === |
| − | In completion-based scheduling, the system recalculates NEXT_DATE after a generated work package is completed. | + | 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. | The completion date becomes the basis for the next occurrence. | ||
| Line 473: | Line 725: | ||
Planning changes alone do not define the next recurrence in the same way as calendar-based scheduling. | 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 === | |
| − | + | ||
| − | === Example: | + | |
A machine must be serviced every 30 days after the previous service was completed. | A machine must be serviced every 30 days after the previous service was completed. | ||
| − | Configuration: | + | ==== 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 | ||
| + | |} | ||
| − | + | ==== Result ==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The system calculates: | The system calculates: | ||
| − | EARLIEST_GENERATION_DATE | + | <pre> |
| + | EARLIEST_GENERATION_DATE = 12 March | ||
| + | </pre> | ||
On or after 12 March, the system can create the work package. | On or after 12 March, the system can create the work package. | ||
| Line 503: | Line 785: | ||
Generated work package: | Generated work package: | ||
| − | PLANNED_START | + | {| class="wikitable" |
| + | ! Property | ||
| + | ! Value | ||
| + | |- | ||
| + | | <code>PLANNED_START</code> | ||
| + | | 15 March | ||
| + | |} | ||
The work package is completed on 20 March. | The work package is completed on 20 March. | ||
| Line 511: | Line 799: | ||
If the recurrence is every 30 days: | If the recurrence is every 30 days: | ||
| − | NEXT_DATE | + | {| class="wikitable" |
| − | LEAD_DAYS | + | ! Value |
| − | EARLIEST_GENERATION_DATE | + | ! Example |
| + | |- | ||
| + | | <code>NEXT_DATE</code> | ||
| + | | around 19 April | ||
| + | |- | ||
| + | | <code>LEAD_DAYS</code> | ||
| + | | 3 | ||
| + | |- | ||
| + | | <code>EARLIEST_GENERATION_DATE</code> | ||
| + | | around 16 April | ||
| + | |} | ||
| − | In this mode, the delay from 15 March to 20 March shifts the future schedule. | + | <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. | + | The difference is the date that is used as the basis for calculating <code>NEXT_DATE</code>. |
| − | Calendar- | + | {| class="wikitable" style="width: 100%;" |
| + | ! Aspect | ||
| + | ! Calendar-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 === | |
| − | + | ||
| − | === Calendar- | + | |
Calendar-based scheduling should be used when the maintenance must follow fixed planned dates. | Calendar-based scheduling should be used when the maintenance must follow fixed planned dates. | ||
| Line 531: | Line 849: | ||
Characteristics: | Characteristics: | ||
| − | * The plan follows the RRULE calendar pattern. | + | * The plan follows the <code>RRULE</code> calendar pattern. |
* Future dates are not automatically shifted just because a work package was completed late. | * Future dates are not automatically shifted just because a work package was completed late. | ||
| − | * NEXT_DATE can be recalculated after planning updates. | + | * <code>NEXT_DATE</code> can be recalculated after planning updates. |
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates. | * It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates. | ||
Example: | Example: | ||
| − | Planned inspection | + | {| class="wikitable" |
| − | Completed | + | ! Event |
| − | Next date | + | ! Date |
| + | |- | ||
| + | | Planned inspection | ||
| + | | 15 March | ||
| + | |- | ||
| + | | Completed | ||
| + | | 20 March | ||
| + | |- | ||
| + | | Next date | ||
| + | | 15 April | ||
| + | |} | ||
The future date stays aligned with the calendar recurrence. | The future date stays aligned with the calendar recurrence. | ||
| − | === Completion- | + | === Completion-Based === |
Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed. | Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed. | ||
| Line 551: | Line 879: | ||
* The plan waits for completion. | * The plan waits for completion. | ||
| − | * The completion date is used as the basis for NEXT_DATE. | + | * The completion date is used as the basis for <code>NEXT_DATE</code>. |
* If the work is completed late, the future schedule moves. | * If the work is completed late, the future schedule moves. | ||
* It is useful for service intervals that depend on the actual last maintenance. | * It is useful for service intervals that depend on the actual last maintenance. | ||
| Line 557: | Line 885: | ||
Example: | Example: | ||
| − | Planned service | + | {| class="wikitable" |
| − | Completed | + | ! Event |
| − | Interval | + | ! Date |
| − | Next 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. | The future date shifts because the work was completed later. | ||
| Line 568: | Line 908: | ||
=== Purpose === | === Purpose === | ||
| − | A RoundMaintenancePlan is used for recurring maintenance rounds. | + | 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 RRULE and SCHEDULING_MODE. | + | 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 SYSREL_ROUND_RELATION. | + | 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. | + | 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>. |
| − | + | <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 <code>RRULE</code>. 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 === | |
| − | + | ||
| − | === Generated | + | |
Example: | Example: | ||
| − | + | {| class="wikitable" style="width: 100%;" | |
| − | + | ! Element | |
| − | Linked child | + | ! 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: | Generated main work package: | ||
| Line 606: | Line 955: | ||
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. | 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 | + | == RoundMaintenancePlan Properties and 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. | ||
| + | |} | ||
| − | SYSREL_ROUND_RELATION links the round maintenance plan to its child maintenance plans. | + | === <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. | The linked child plans define which additional work packages should be generated when the round maintenance plan is due. | ||
| Line 616: | Line 987: | ||
When the round plan generates work packages, the system creates: | When the round plan generates work packages, the system creates: | ||
| − | * one main work package from the round plan’s own LK_WP_TMPL | + | * 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 SYSREL_ROUND_RELATION | + | * 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. | 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 === | + | === <code>PLAN_SELECTION_RULE</code> === |
| − | + | ||
| − | + | ||
| − | + | <code>PLAN_SELECTION_RULE</code> exists on <code>RoundMaintenancePlan</code>. | |
| − | Until that behavior is confirmed, the wiki should not claim that PLAN_SELECTION_RULE filters child plans by due date, asset, or priority. | + | <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> | ||
| − | === ORDERID and GROUPID === | + | === <code>ORDERID</code> and <code>GROUPID</code> === |
| − | The relation between the round maintenance plan and a linked child maintenance plan can contain ORDERID and GROUPID. | + | 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. | When the system creates an additional work package from a linked child maintenance plan, these values can be copied to the generated work package. | ||
| Line 637: | Line 1,008: | ||
This can be used to structure, order, or group the additional work packages in the generated round. | This can be used to structure, order, or group the additional work packages in the generated round. | ||
| − | == Properties | + | == Properties Calculated or Updated by the 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. | ||
| + | |} | ||
| − | EARLIEST_GENERATION_DATE | + | === <code>EARLIEST_GENERATION_DATE</code> === |
| − | + | <code>EARLIEST_GENERATION_DATE</code> is calculated by the system from <code>NEXT_DATE</code> and <code>LEAD_DAYS</code>. | |
| + | <pre> | ||
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | ||
| + | </pre> | ||
This value is recalculated when: | This value is recalculated when: | ||
| − | * NEXT_DATE changes | + | * <code>NEXT_DATE</code> changes |
| − | * LEAD_DAYS changes | + | * <code>LEAD_DAYS</code> changes |
| − | * NEXT_DATE is recalculated after planning or completion | + | * <code>NEXT_DATE</code> is recalculated after planning or completion |
| − | * recurrence settings cause a new NEXT_DATE to be calculated | + | * recurrence settings cause a new <code>NEXT_DATE</code> to be calculated |
| − | === NEXT_DATE === | + | === <code>NEXT_DATE</code> === |
| − | For CyclicMaintenancePlan and RoundMaintenancePlan, NEXT_DATE can be calculated or recalculated by the system. | + | For <code>CyclicMaintenancePlan</code> and <code>RoundMaintenancePlan</code>, <code>NEXT_DATE</code> can be calculated or recalculated by the system. |
The calculation depends on: | The calculation depends on: | ||
| − | * RRULE | + | * <code>RRULE</code> |
| − | * RRULE_START_DATE | + | * <code>RRULE_START_DATE</code> |
| − | * RRULE_UNTIL_DATE | + | * <code>RRULE_UNTIL_DATE</code> |
| − | * RRULE_COUNT | + | * <code>RRULE_COUNT</code> |
| − | * SCHEDULING_MODE | + | * <code>SCHEDULING_MODE</code> |
* related generated work packages | * related generated work packages | ||
* planning events | * planning events | ||
* completion 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 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, NEXT_DATE is calculated from the completion date of the previous generated work package. | + | For completion-based scheduling, <code>NEXT_DATE</code> is calculated from the completion date of the previous generated work package. |
| − | === LAST_DATE === | + | === <code>LAST_DATE</code> === |
| − | LAST_DATE is updated by the system when a generated work package is completed. | + | <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. | It stores the latest completion date of a generated work package related to the maintenance plan. | ||
| Line 681: | Line 1,072: | ||
This value is especially relevant for completion-based scheduling. | This value is especially relevant for completion-based scheduling. | ||
| − | === PLANNED_START on | + | === <code>PLANNED_START</code> 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. | + | 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: | Example: | ||
| + | <pre> | ||
MaintenancePlan.NEXT_DATE: 15 March | MaintenancePlan.NEXT_DATE: 15 March | ||
Generated WorkPackage.PLANNED_START: 15 March | Generated WorkPackage.PLANNED_START: 15 March | ||
| + | </pre> | ||
| − | === Links on | + | === Links on Generated Work Packages === |
When the system generates a work package, it automatically sets the required links on the generated work package. | When the system generates a work package, it automatically sets the required links on the generated work package. | ||
| Line 696: | Line 1,089: | ||
The generated work package is linked to: | The generated work package is linked to: | ||
| − | * the source maintenance plan via LK_MAINTENANCE_PLAN | + | * the source maintenance plan via <code>LK_MAINTENANCE_PLAN</code> |
| − | * the template work package via LK_WP_TMPL | + | * the template work package via <code>LK_WP_TMPL</code> |
| − | * the assigned asset via LK_ASSET | + | * 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 TASK_OWNER. | + | 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 | + | == Properties and 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>. | ||
| + | |} | ||
| − | + | === <code>NEXT_DATE</code> Changed === | |
| − | + | When <code>NEXT_DATE</code> changes, the system recalculates <code>EARLIEST_GENERATION_DATE</code>. | |
| + | <pre> | ||
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | ||
| + | </pre> | ||
| − | === LEAD_DAYS | + | === <code>LEAD_DAYS</code> Changed === |
| − | When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE. | + | When <code>LEAD_DAYS</code> changes, the system recalculates <code>EARLIEST_GENERATION_DATE</code>. |
| − | + | ||
| − | + | ||
| + | <pre> | ||
EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS | ||
| + | </pre> | ||
| − | === RRULE | + | === <code>RRULE</code> Changed === |
| − | When RRULE changes, the recurrence pattern changes. | + | When <code>RRULE</code> changes, the recurrence pattern changes. |
| − | The system recalculates NEXT_DATE based on the new recurrence rule and the selected SCHEDULING_MODE. | + | The system recalculates <code>NEXT_DATE</code> based on the new recurrence rule and the selected <code>SCHEDULING_MODE</code>. |
| − | After NEXT_DATE is recalculated, EARLIEST_GENERATION_DATE is recalculated as well. | + | After <code>NEXT_DATE</code> is recalculated, <code>EARLIEST_GENERATION_DATE</code> is recalculated as well. |
| − | === RRULE_START_DATE | + | === <code>RRULE_START_DATE</code> Changed === |
| − | When RRULE_START_DATE changes, the start point of the recurrence changes. | + | When <code>RRULE_START_DATE</code> changes, the start point of the recurrence changes. |
| − | The system recalculates the schedule. | + | The system recalculates the schedule. This can change <code>NEXT_DATE</code>. |
| − | + | If <code>NEXT_DATE</code> changes, <code>EARLIEST_GENERATION_DATE</code> is recalculated as well. | |
| − | + | === <code>RRULE_UNTIL_DATE</code> Changed === | |
| − | + | When <code>RRULE_UNTIL_DATE</code> changes, the end boundary of the recurrence changes. | |
| − | + | ||
| − | When RRULE_UNTIL_DATE changes, the end boundary of the recurrence changes. | + | |
The system checks whether future occurrences are still available. | 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. | + | If no further occurrence is possible because of <code>RRULE_UNTIL_DATE</code>, the system cannot calculate a new <code>NEXT_DATE</code>. |
| − | === RRULE_COUNT | + | === <code>RRULE_COUNT</code> Changed === |
| − | When RRULE_COUNT changes, the system checks whether the maximum number of generated work packages has already been reached. | + | 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 RRULE_COUNT, the system does not calculate further occurrences. | + | 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. |
| − | === SCHEDULING_MODE | + | === <code>SCHEDULING_MODE</code> Changed === |
| − | When SCHEDULING_MODE changes, the logic for calculating future dates changes. | + | 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 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. | + | 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 NEXT_DATE according to the selected SCHEDULING_MODE. | + | Because this changes the calculation logic, the system recalculates <code>NEXT_DATE</code> according to the selected <code>SCHEDULING_MODE</code>. |
| − | If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well. | + | If <code>NEXT_DATE</code> changes, <code>EARLIEST_GENERATION_DATE</code> is recalculated as well. |
| − | === Generated | + | === Generated Work Package <code>PLANNED_START</code> Changed === |
| − | When PLANNED_START of a generated work package is set or changed, the work package notifies the linked maintenance plan. | + | 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 NEXT_DATE. | + | 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. |
| − | + | For completion-based cyclic maintenance plans, a <code>PLANNED_START</code> change does not drive the recurrence in the same way. <code>NEXT_DATE</code> is mainly calculated after the work package is completed. | |
| − | + | === Generated Work Package Completed === | |
| − | + | ||
| − | === Generated | + | |
When a generated work package is completed, the work package notifies the linked maintenance plan. | When a generated work package is completed, the work package notifies the linked maintenance plan. | ||
| Line 780: | Line 1,201: | ||
A work package is considered completed when: | A work package is considered completed when: | ||
| + | <pre> | ||
ORGA_STATUS == 100 | ORGA_STATUS == 100 | ||
| + | </pre> | ||
| − | The system updates LAST_DATE. | + | The system updates <code>LAST_DATE</code>. Then the system recalculates <code>NEXT_DATE</code> according to <code>SCHEDULING_MODE</code>. |
| − | + | ||
| − | Then the system recalculates NEXT_DATE according to SCHEDULING_MODE. | + | |
For calendar-based scheduling: | For calendar-based scheduling: | ||
* the system continues according to the calendar recurrence | * the system continues according to the calendar recurrence | ||
| − | * NEXT_DATE is calculated from the recurrence pattern and relevant planned or finished dates | + | * <code>NEXT_DATE</code> is calculated from the recurrence pattern and relevant planned or finished dates |
For completion-based scheduling: | For completion-based scheduling: | ||
* the completion date becomes the basis for the next occurrence | * the completion date becomes the basis for the next occurrence | ||
| − | * NEXT_DATE is calculated from the completion date | + | * <code>NEXT_DATE</code> is calculated from the completion date |
| − | After NEXT_DATE is updated, EARLIEST_GENERATION_DATE is recalculated. | + | After <code>NEXT_DATE</code> is updated, <code>EARLIEST_GENERATION_DATE</code> is recalculated. |
| − | == Work | + | == Work Package Generation Logic == |
| − | === When | + | === 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. | A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled. | ||
| − | The plan must be valid. | + | {| class="wikitable" style="width: 100%;" |
| − | + | ! Requirement | |
| − | For cyclic maintenance plans, this | + | ! Condition |
| − | + | ! Notes | |
| − | + | |- | |
| − | + | | Plan validity | |
| − | + | | The plan must be valid. | |
| − | + | | For cyclic maintenance plans, this requires a valid <code>RRULE</code>, assigned <code>LK_ASSET</code>, and available <code>NEXT_DATE</code>. | |
| − | + | |- | |
| − | + | | Plan status | |
| − | PLAN_STATUS == Active | + | | <code>PLAN_STATUS == Active</code> |
| − | + | | Inactive plans are ignored. | |
| − | AUTO_CREATE must be enabled. | + | |- |
| − | + | | Automatic generation | |
| − | + | | <code>AUTO_CREATE</code> must be enabled. | |
| − | + | | If disabled, the plan does not automatically create work packages. | |
| − | LK_WP_TMPL must be set. | + | |- |
| − | + | | Template work package | |
| − | + | | <code>LK_WP_TMPL</code> must be set. | |
| − | + | | The linked work package must be a template work package. | |
| − | LK_REPLICATION_CONFIG must be set. | + | |- |
| − | + | | Replication configuration | |
| − | + | | <code>LK_REPLICATION_CONFIG</code> must be set. | |
| − | + | | Required to copy the template work package. | |
| − | EARLIEST_GENERATION_DATE <= current date | + | |- |
| − | + | | Earliest generation date | |
| − | + | | <code>EARLIEST_GENERATION_DATE <= current date</code> | |
| − | + | | 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 <code>LK_MAINTENANCE_PLAN</code> where <code>ORGA_STATUS != 100</code>. | ||
| + | |} | ||
| − | + | <div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;"> | |
| + | '''Important:''' The open work package check prevents the system from creating multiple open work packages for the same maintenance plan. | ||
| + | </div> | ||
| − | == Round | + | == Round Work Package Generation == |
A round maintenance plan creates a main work package for the round. | 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. | + | 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. | 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. | + | 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: | For child plans used in a round, the system does not care whether the child plan: | ||
| − | * has PLAN_STATUS == Active | + | * has <code>PLAN_STATUS == Active</code> |
| − | * has AUTO_CREATE == true | + | * has <code>AUTO_CREATE == true</code> |
| − | * has a valid RRULE | + | * has a valid <code>RRULE</code> |
| − | * has a valid NEXT_DATE | + | * has a valid <code>NEXT_DATE</code> |
| − | * is due based on its own EARLIEST_GENERATION_DATE | + | * is due based on its own <code>EARLIEST_GENERATION_DATE</code> |
| − | The round plan controls the timing. The child plans define what additional work packages should be created as part of the round. | + | <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}} | {{UnderConstructionEnd}} | ||
Revision as of 05:45, 15 June 2026
Contents
- 1 MRO Maintenance Planning
- 1.1 Overview
- 1.2 Basic Concept
- 1.3 MaintenancePlan Base Class
- 1.4 Work Package Properties Used by Maintenance Planning
- 1.5 CyclicMaintenancePlan
- 1.6 CyclicMaintenancePlan Properties
- 1.7 Calendar-Based Scheduling
- 1.8 Completion-Based Scheduling
- 1.9 Calendar-Based vs Completion-Based Scheduling
- 1.10 RoundMaintenancePlan
- 1.11 RoundMaintenancePlan Properties and Relations
- 1.12 Properties Calculated or Updated by the System
- 1.13 Properties and Events That Trigger Recalculation
- 1.14 Work Package Generation Logic
- 1.15 Round Work Package Generation
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.
Validation: 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.
Validation: If LK_WP_TMPL is not configured, the maintenance plan cannot create a work package.
LK_REPLICATION_CONFIG
LK_REPLICATION_CONFIG is the link to the replication configuration.
The replication configuration defines how the template work package is copied into a generated work package.
It can define, for example:
- which properties are copied
- how references are copied
- what the target meta class of the generated work package should be
Validation: If LK_REPLICATION_CONFIG is not configured, the maintenance plan cannot create a work package.
NEXT_DATE
NEXT_DATE defines the planned execution date of the next maintenance activity.
It answers the question: When should the next maintenance work be performed?
NEXT_DATE is not necessarily the date on which the work package is created.
| 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.
Validation: 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
RRULEcalendar pattern. - Future dates are not automatically shifted just because a work package was completed late.
-
NEXT_DATEcan 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_DATEchanges -
LEAD_DAYSchanges -
NEXT_DATEis recalculated after planning or completion - recurrence settings cause a new
NEXT_DATEto 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_DATEis 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_DATEis 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.
|
Important: 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.
