UBIK Wiki / Augmensys - User contributions [en]

MRO Material Management

2026-06-23T13:42:35Z

LMA:

== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
|}

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

MRO Material Management

2026-06-23T09:27:08Z

LMA: /* Validation and business rules */

MRO Material Management

2026-06-23T09:19:18Z

LMA: /* Finishing a task */

MRO Material Management

2026-06-23T09:17:06Z

LMA: /* Delete behavior */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MRO Material Management

2026-06-23T09:14:50Z

LMA: /* Object overview */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MROMaintenancePlans

2026-06-19T06:42:49Z

LMA: /* See also */

= MRO Maintenance Planning =

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans. The maintenance plan defines the rules. The generated work package is used by users to execute and complete the actual maintenance work.
</div>

== Overview ==

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

* when a work package should be created
* which asset the work package belongs to
* which template work package is used
* how the template work package is copied
* how many days before the planned execution date the work package may be generated
* how future planning dates are calculated

The actual maintenance work is not executed by the maintenance plan itself. The maintenance plan creates work packages. These generated work packages are then used by users to execute and complete the maintenance work.

In MRO, MaintenancePlan is the abstract base class for maintenance planning. It provides the common foundation for maintenance plans, but it is not intended to be used directly.

The fully implemented maintenance plan types in standard MRO are:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Custom maintenance plan types can be implemented by deriving from the abstract MaintenancePlan base class. However, the standard MRO maintenance planning feature is based on cyclic maintenance plans and round maintenance plans.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' CyclicMaintenancePlan and RoundMaintenancePlan support recurrence-based scheduling. This includes planned execution dates, automatic work package generation, calendar-based scheduling, completion-based scheduling, automatic recalculation of scheduling dates, and generation based on due dates.
</div>

RoundMaintenancePlan additionally supports maintenance rounds. A round maintenance plan creates one main work package for the round. It can also create additional work packages from child maintenance plans linked via SYSREL_ROUND_RELATION. These additional work packages are assigned to the main round work package.

== Basic Concept ==

The maintenance planning feature is built around four main parts:

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

=== Maintenance Plan ===

The maintenance plan defines the rules for creating work packages.

This includes, for example:

* when a work package should be created
* which asset the work package should belong to
* how many days before the planned execution date the work package may be created
* which template work package should be used
* which recurrence pattern should be used
* whether future dates are calculated calendar-based or completion-based

=== Template Work Package ===

The template work package defines what the generated work package should look like.

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

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

=== Replication Configuration ===

The replication configuration defines how the template work package is copied.

This includes, for example:

* which properties are copied
* how referenced objects are handled
* what the target meta class of the generated work package should be

=== Generated Work Package ===

The generated work package is the actual result created by the maintenance plan.

Example:

# A pump has to be inspected every month.
# A cyclic maintenance plan is created for this pump.
# The plan is configured with a monthly recurrence, an assigned asset, a template work package, and a replication configuration.
# When the plan becomes due, the system uses a replication job to create a new work package from the configured template work package.
# The generated work package is linked back to the maintenance plan via LK_MAINTENANCE_PLAN.

This link allows the maintenance plan to react when the generated work package is planned or completed.

== MaintenancePlan Base Class ==

=== Purpose ===

MaintenancePlan is the abstract base class for maintenance planning in MRO.

It provides the common properties and logic required by maintenance plan implementations.

Because MaintenancePlan is abstract, users do not create or use this base class directly in the standard MRO feature. Instead, the concrete maintenance plan types are used:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Developers can derive from the abstract base class if a project requires a custom maintenance plan type. In that case, the custom implementation must provide the missing plan-specific behavior.

=== Base Class Properties ===

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

=== LK_ASSET ===

LK_ASSET is the link to the asset that requires maintenance.

This can be, for example:

* equipment
* a functional location
* another customized maintainable object deriving from Asset

The generated work package is linked to the same asset.

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

=== LK_WP_TMPL ===

LK_WP_TMPL is the link to the template work package.

The template work package defines what the generated work package should look like.

When the maintenance plan creates a work package, the system copies the work package referenced by LK_WP_TMPL.

The linked work package must be a template work package. This means its ISTEMPLATE property must be set.

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

=== LK_REPLICATION_CONFIG ===

LK_REPLICATION_CONFIG is the link to the replication configuration.

The replication configuration defines how the template work package is copied into a generated work package.

It can define, for example:

* which properties are copied
* how references are copied
* what the target meta class of the generated work package should be

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

=== NEXT_DATE ===

NEXT_DATE defines the planned execution date of the next maintenance activity.

It answers the question: '''When should the next maintenance work be performed?'''

NEXT_DATE is not necessarily the date on which the work package is created.

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

In this example, the system may create the work package on 12 March, but the generated work package is planned for 15 March.

When a work package is generated, the generated work package receives the maintenance plan’s NEXT_DATE as its PLANNED_START.

=== LEAD_DAYS ===

LEAD_DAYS defines how many days before NEXT_DATE the system may create the work package.

This is used to create work packages before the actual planned execution date.

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

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

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system.

It defines the earliest date on which the maintenance plan may create a work package.

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

Example:

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

The maintenance planning orchestrator searches for active plans where EARLIEST_GENERATION_DATE has been reached.

A plan can be considered for automatic work package generation when:

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

If EARLIEST_GENERATION_DATE has not yet been reached, no work package is created.

=== PLAN_STATUS ===

PLAN_STATUS defines whether the maintenance plan is active or inactive.

Only active plans are considered for automatic work package generation. Inactive plans are ignored by the maintenance planning process.

Typical values are:

* Inactive
* Active

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

=== AUTO_CREATE ===

AUTO_CREATE defines whether the system is allowed to automatically create work packages from the maintenance plan.

If AUTO_CREATE is enabled, the maintenance planning orchestrator can create work packages once the plan is due.

If AUTO_CREATE is disabled, the plan does not automatically create work packages.

=== LAST_DATE ===

LAST_DATE stores the date when the most recent generated work package linked to the maintenance plan was completed.

This property is especially important for completion-based scheduling.

{| class="wikitable"
! Value
! Example
|-
| Previous generated work package completed
| 20 March
|-
| SCHEDULING_MODE
| Completion-Based
|-
| Next date is calculated from
| 20 March
|}

The system updates LAST_DATE when a generated work package is completed.

=== PRIORITY ===

PRIORITY is a numeric value that can be used to sort maintenance plans.

For round maintenance plans, there is also a property called PLAN_SELECTION_RULE.

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

== Work Package Properties Used by Maintenance Planning ==

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

=== LK_MAINTENANCE_PLAN ===

LK_MAINTENANCE_PLAN is set on generated work packages.

It stores the maintenance plan that triggered the creation of the work package.

This is important because the maintenance plan itself does not directly store a list of generated work packages. Instead, generated work packages reference their source maintenance plan via LK_MAINTENANCE_PLAN.

This link allows the system to find work packages created from a maintenance plan and to update the maintenance plan when a generated work package is planned or completed.

=== LK_WP_TMPL ===

On a generated work package, LK_WP_TMPL stores the template work package that was used to create the generated work package.

This allows users and the system to see which template was used as the source.

=== LK_ASSET ===

On a generated work package, LK_ASSET stores the asset for which the work package was created.

This is usually copied or assigned based on the maintenance plan’s LK_ASSET.

=== PLANNED_START ===

PLANNED_START stores the planned start date of the generated work package.

When a maintenance plan generates a work package, the system sets:

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

=== ORGA_STATUS ===

ORGA_STATUS is used to determine whether a generated work package is finished.

A work package is considered finished when:

<pre>
ORGA_STATUS == 100
</pre>

Open work packages are generated work packages linked to the maintenance plan where:

<pre>
ORGA_STATUS != 100
</pre>

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Generation rule:''' A maintenance plan does not create another work package while it still has an open generated work package.
</div>

=== TASK_OWNER ===

TASK_OWNER is used in round maintenance scenarios.

When a round maintenance plan creates a main work package and additional work packages from linked child plans, the additional work packages are assigned to the main round work package via TASK_OWNER.

=== ORDERID and GROUPID ===

ORDERID and GROUPID can be copied from the SYSREL_ROUND_RELATION relation to generated work packages in a round maintenance scenario.

They can be used to order or group the additional work packages that belong to the generated round work package.

== CyclicMaintenancePlan ==

=== Purpose ===

A CyclicMaintenancePlan is used for recurring maintenance work on an asset.

It is the standard maintenance plan type for maintenance activities that repeat according to a defined recurrence pattern.

Examples:

* inspect a pump every month
* service a machine every 6 months
* check safety equipment every Monday
* replace a filter every 30 days
* perform annual maintenance on a functional location

A cyclic maintenance plan uses RRULE to define the recurrence. It also uses SCHEDULING_MODE to define how future dates are calculated.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Key concept:''' SCHEDULING_MODE defines whether the plan follows fixed calendar dates or whether the next date depends on the actual completion date of the previous generated work package.
</div>

The supported scheduling modes are:

* Calendar-Based
* Completion-Based

== CyclicMaintenancePlan Properties ==

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

=== RRULE ===

RRULE defines the recurrence pattern of a cyclic maintenance plan.

It describes how often the maintenance should occur.

Examples:

<pre>
FREQ=DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR
FREQ=MONTHLY;BYMONTHDAY=15
</pre>

The system uses RRULE to calculate future planned execution dates.

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

=== RRULE_START_DATE ===

RRULE_START_DATE defines when the recurrence pattern starts.

The recurrence rule is calculated from this date forward.

Example:

{| class="wikitable"
! Setting
! Value
|-
| RRULE_START_DATE
| 01 January
|-
| RRULE
| Monthly on the 15th
|}

The system uses these values to determine valid planned execution dates.

=== RRULE_UNTIL_DATE ===

RRULE_UNTIL_DATE is an optional end date for the recurrence.

If this date is configured, no further occurrences are generated after this date.

This can be used for maintenance plans that should only run until a certain date.

=== RRULE_COUNT ===

RRULE_COUNT limits how many work packages can be created from the plan.

Example:

{| class="wikitable"
! Setting
! Value
|-
| RRULE_COUNT
| 10
|}

When the number of related generated work packages reaches RRULE_COUNT, the system no longer calculates new occurrences for the plan.

=== SCHEDULING_MODE ===

SCHEDULING_MODE defines how NEXT_DATE is calculated for a cyclic maintenance plan.

SCHEDULING_MODE is only relevant for concrete maintenance plan types that use recurrence logic, such as CyclicMaintenancePlan and RoundMaintenancePlan.

The supported scheduling modes are:

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

This property is one of the most important settings because it defines whether future dates follow the calendar or depend on the actual completion of the previous generated work package.

== Calendar-Based Scheduling ==

=== Purpose ===

Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences.

The next planned execution date is calculated according to RRULE and the calendar recurrence.

This means that delays in completing a work package do not automatically shift the whole future schedule.

Use calendar-based scheduling when the maintenance should happen on fixed dates or fixed calendar intervals.

Examples:

* inspection every 15th day of the month
* safety check every Monday
* yearly inspection every January
* quarterly maintenance in fixed maintenance windows

=== How Calendar-Based Scheduling Works ===

In calendar-based scheduling, the system calculates NEXT_DATE based on the recurrence rule and the relevant dates of existing generated work packages.

The system determines the highest relevant planned or finished date of generated work packages linked to the maintenance plan. Then it uses the recurrence rule to calculate the next valid occurrence after that date.

This means the schedule continues according to the recurrence pattern.

If a work package is completed later than planned, the future schedule does not necessarily move with that completion date.

=== Example: Calendar-Based Scheduling ===

A pump must be inspected on the 15th of every month.

==== Configuration ====

{| class="wikitable" style="width: 100%;"
! Setting
! Value
|-
| Plan type
| CyclicMaintenancePlan
|-
| LK_ASSET
| Pump 1
|-
| LK_WP_TMPL
| Pump Inspection Template
|-
| LK_REPLICATION_CONFIG
| Pump Inspection Replication
|-
| SCHEDULING_MODE
| Calendar-Based
|-
| RRULE
| Monthly on the 15th
|-
| RRULE_START_DATE
| 01 January
|-
| NEXT_DATE
| 15 March
|-
| LEAD_DAYS
| 3
|-
| PLAN_STATUS
| Active
|-
| AUTO_CREATE
| Enabled
|}

==== Result ====

The system calculates:

<pre>
EARLIEST_GENERATION_DATE = 12 March
</pre>

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

Generated work package:

{| class="wikitable"
! Property
! Value
|-
| PLANNED_START
| 15 March
|}

After the work package is planned, the system can calculate the next occurrence:

<pre>
NEXT_DATE = 15 April
</pre>

If the March work package is completed on 20 March, the next date still follows the monthly recurrence. The next planned execution date remains 15 April.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Result:''' The late completion does not shift the future schedule to 20 April.
</div>

== Completion-Based Scheduling ==

=== Purpose ===

Completion-based scheduling is used when the next maintenance date should depend on the actual completion date of the previous generated work package.

This means that the interval starts after the work has actually been completed.

Use completion-based scheduling when the maintenance should repeat based on the time since the last completed maintenance activity.

Examples:

* service every 30 days after the last service
* inspection 6 months after the previous inspection was completed
* replacement 90 days after the previous replacement
* maintenance where a delay should also delay the next cycle

=== How Completion-Based Scheduling Works ===

In completion-based scheduling, the system recalculates NEXT_DATE after a generated work package is completed.

The completion date becomes the basis for the next occurrence.

Planning changes alone do not define the next recurrence in the same way as calendar-based scheduling.

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

=== Example: Completion-Based Scheduling ===

A machine must be serviced every 30 days after the previous service was completed.

==== Configuration ====

{| class="wikitable" style="width: 100%;"
! Setting
! Value
|-
| Plan type
| CyclicMaintenancePlan
|-
| LK_ASSET
| Machine 1
|-
| LK_WP_TMPL
| Machine Service Template
|-
| LK_REPLICATION_CONFIG
| Machine Service Replication
|-
| SCHEDULING_MODE
| Completion-Based
|-
| RRULE
| Every 30 days
|-
| RRULE_START_DATE
| 01 March
|-
| NEXT_DATE
| 15 March
|-
| LEAD_DAYS
| 3
|-
| PLAN_STATUS
| Active
|-
| AUTO_CREATE
| Enabled
|}

==== Result ====

The system calculates:

<pre>
EARLIEST_GENERATION_DATE = 12 March
</pre>

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

Generated work package:

{| class="wikitable"
! Property
! Value
|-
| PLANNED_START
| 15 March
|}

The work package is completed on 20 March.

Because the plan is completion-based, the system calculates the next date from 20 March.

If the recurrence is every 30 days:

{| class="wikitable"
! Value
! Example
|-
| NEXT_DATE
| around 19 April
|-
| LEAD_DAYS
| 3
|-
| EARLIEST_GENERATION_DATE
| around 16 April
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Result:''' In this mode, the delay from 15 March to 20 March shifts the future schedule.
</div>

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

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

{| class="wikitable" style="width: 100%;"
! Aspect
! Calendar-Based
! Completion-Based
|-
| Basis for NEXT_DATE
| Recurrence defined by RRULE
| Actual completion date of the previous generated work package
|-
| Effect of late completion
| Future dates are not automatically shifted
| Future dates move with the completion date
|-
| Typical use case
| Fixed maintenance windows, fixed calendar intervals, legal or organizational inspection dates
| Service intervals that depend on the actual last maintenance
|-
| Example
| Planned: 15 March Completed: 20 March Next date: 15 April
| Planned: 15 March Completed: 20 March Interval: 30 days Next date: around 19 April
|}

=== Calendar-Based ===

Calendar-based scheduling should be used when the maintenance must follow fixed planned dates.

Characteristics:

* The plan follows the RRULE calendar pattern.
* Future dates are not automatically shifted just because a work package was completed late.
* NEXT_DATE can be recalculated after planning updates.
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates.

Example:

{| class="wikitable"
! Event
! Date
|-
| Planned inspection
| 15 March
|-
| Completed
| 20 March
|-
| Next date
| 15 April
|}

The future date stays aligned with the calendar recurrence.

=== Completion-Based ===

Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed.

Characteristics:

* The plan waits for completion.
* The completion date is used as the basis for NEXT_DATE.
* If the work is completed late, the future schedule moves.
* It is useful for service intervals that depend on the actual last maintenance.

Example:

{| class="wikitable"
! Event
! Date
|-
| Planned service
| 15 March
|-
| Completed
| 20 March
|-
| Interval
| 30 days
|-
| Next date
| around 19 April
|}

The future date shifts because the work was completed later.

== RoundMaintenancePlan ==

=== Purpose ===

A RoundMaintenancePlan is used for recurring maintenance rounds.

It is a specialized type of cyclic maintenance plan. This means that it also uses RRULE and SCHEDULING_MODE.

In addition to the cyclic scheduling logic, a round maintenance plan includes child maintenance plans linked via SYSREL_ROUND_RELATION.

When the round maintenance plan is due, the system creates the main work package for the round. Then it creates additional work packages from the child maintenance plans linked via SYSREL_ROUND_RELATION.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Important for child plans:''' For the child plans, the system does not care whether they are due, active, auto-created, or whether they have a valid RRULE. The round maintenance plan uses the child plans as configuration for the additional work packages that should be created as part of the round.
</div>

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

=== Generated Result ===

Example:

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

Generated main work package:

* Machine Room Round

Additional generated work packages inside the main round work package:

* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection

The additional work packages are assigned to the main round work package. This allows the result of the round maintenance plan to be structured as one complete maintenance round.

== RoundMaintenancePlan Properties and Relations ==

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

=== SYSREL_ROUND_RELATION ===

SYSREL_ROUND_RELATION links the round maintenance plan to its child maintenance plans.

The linked child plans define which additional work packages should be generated when the round maintenance plan is due.

When the round plan generates work packages, the system creates:

* one main work package from the round plan’s own LK_WP_TMPL
* one additional work package for each child maintenance plan linked via SYSREL_ROUND_RELATION

The child maintenance plans do not need to be due themselves for the round maintenance plan to use them during round generation.

=== PLAN_SELECTION_RULE ===

PLAN_SELECTION_RULE exists on RoundMaintenancePlan.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The exact runtime effect of PLAN_SELECTION_RULE should be documented after the implementation behavior has been verified. Until that behavior is confirmed, the wiki should not claim that PLAN_SELECTION_RULE filters child plans by due date, asset, or priority.
</div>

=== ORDERID and GROUPID ===

The relation between the round maintenance plan and a linked child maintenance plan can contain ORDERID and GROUPID.

When the system creates an additional work package from a linked child maintenance plan, these values can be copied to the generated work package.

This can be used to structure, order, or group the additional work packages in the generated round.

== Properties Calculated or Updated by the System ==

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

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.

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

This value is recalculated when:

* NEXT_DATE changes
* LEAD_DAYS changes
* NEXT_DATE is recalculated after planning or completion
* recurrence settings cause a new NEXT_DATE to be calculated

=== NEXT_DATE ===

For CyclicMaintenancePlan and RoundMaintenancePlan, NEXT_DATE can be calculated or recalculated by the system.

The calculation depends on:

* RRULE
* RRULE_START_DATE
* RRULE_UNTIL_DATE
* RRULE_COUNT
* SCHEDULING_MODE
* related generated work packages
* planning events
* completion events

For calendar-based scheduling, NEXT_DATE is calculated from the recurrence pattern and the highest relevant planned or finished date of related generated work packages.

For completion-based scheduling, NEXT_DATE is calculated from the completion date of the previous generated work package.

=== LAST_DATE ===

LAST_DATE is updated by the system when a generated work package is completed.

It stores the latest completion date of a generated work package related to the maintenance plan.

This value is especially relevant for completion-based scheduling.

=== PLANNED_START on Generated Work Packages ===

When the system generates a work package from a maintenance plan, it sets the generated work package’s PLANNED_START to the maintenance plan’s NEXT_DATE.

Example:

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

=== Links on Generated Work Packages ===

When the system generates a work package, it automatically sets the required links on the generated work package.

The generated work package is linked to:

* the source maintenance plan via LK_MAINTENANCE_PLAN
* the template work package via LK_WP_TMPL
* the assigned asset via LK_ASSET

For round maintenance plans, additional generated work packages from linked child maintenance plans are assigned to the main round work package via TASK_OWNER.

== Properties and Events That Trigger Recalculation ==

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

=== NEXT_DATE Changed ===

When NEXT_DATE changes, the system recalculates EARLIEST_GENERATION_DATE.

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

=== LEAD_DAYS Changed ===

When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.

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

=== RRULE Changed ===

When RRULE changes, the recurrence pattern changes.

The system recalculates NEXT_DATE based on the new recurrence rule and the selected SCHEDULING_MODE.

After NEXT_DATE is recalculated, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_START_DATE Changed ===

When RRULE_START_DATE changes, the start point of the recurrence changes.

The system recalculates the schedule. This can change NEXT_DATE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_UNTIL_DATE Changed ===

When RRULE_UNTIL_DATE changes, the end boundary of the recurrence changes.

The system checks whether future occurrences are still available.

If no further occurrence is possible because of RRULE_UNTIL_DATE, the system cannot calculate a new NEXT_DATE.

=== RRULE_COUNT Changed ===

When RRULE_COUNT changes, the system checks whether the maximum number of generated work packages has already been reached.

If the number of related generated work packages is greater than or equal to RRULE_COUNT, the system does not calculate further occurrences.

=== SCHEDULING_MODE Changed ===

When SCHEDULING_MODE changes, the logic for calculating future dates changes.

Changing to Calendar-Based means that the plan follows the calendar recurrence.

Changing to Completion-Based means that the plan calculates NEXT_DATE from the completion of the previous generated work package.

Because this changes the calculation logic, the system recalculates NEXT_DATE according to the selected SCHEDULING_MODE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== Generated Work Package PLANNED_START Changed ===

When PLANNED_START of a generated work package is set or changed, the work package notifies the linked maintenance plan.

For calendar-based cyclic maintenance plans, this can trigger recalculation of NEXT_DATE. The system uses the planning information to continue the calendar-based recurrence.

For completion-based cyclic maintenance plans, a PLANNED_START change does not drive the recurrence in the same way. NEXT_DATE is mainly calculated after the work package is completed.

=== Generated Work Package Completed ===

When a generated work package is completed, the work package notifies the linked maintenance plan.

A work package is considered completed when:

<pre>
ORGA_STATUS == 100
</pre>

The system updates LAST_DATE. Then the system recalculates NEXT_DATE according to SCHEDULING_MODE.

For calendar-based scheduling:

* the system continues according to the calendar recurrence
* NEXT_DATE is calculated from the recurrence pattern and relevant planned or finished dates

For completion-based scheduling:

* the completion date becomes the basis for the next occurrence
* NEXT_DATE is calculated from the completion date

After NEXT_DATE is updated, EARLIEST_GENERATION_DATE is recalculated.

== Work Package Generation Logic ==

=== When Is a Plan Ready to Create a Work Package? ===

A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled.

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

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

== Round Work Package Generation ==

A round maintenance plan creates a main work package for the round.

After the main work package has been created, the system processes the maintenance plans linked via SYSREL_ROUND_RELATION.

For each linked child maintenance plan, the system creates an additional work package.

These additional generated work packages are assigned to the main round work package via TASK_OWNER.

For child plans used in a round, the system does not care whether the child plan:

* has PLAN_STATUS == Active
* has AUTO_CREATE == true
* has a valid RRULE
* has a valid NEXT_DATE
* is due based on its own EARLIEST_GENERATION_DATE

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Rule:''' The round plan controls the timing. The child plans define what additional work packages should be created as part of the round.
</div>

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

MRO Material Management

2026-06-19T06:41:12Z

LMA: /* Relations */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Technical base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MRO Material Management

2026-06-19T06:40:02Z

LMA: /* Reservation status */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Technical base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Relations ==

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MRO Material Management

2026-06-19T06:38:54Z

LMA: /* Material type */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Technical base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Relations ==

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MRO Material Management

2026-06-19T06:37:42Z

LMA:

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, and Reservation. Materials are linked to master data and storage locations. Reservations are created manually by users and link materials to tasks.
</div>

MRO material management is used to support maintenance work with required spare parts, consumables, tools, or other material items.

Users can see which material is required for a task, where the material is stored, how much material is available, how much material is reserved, and which reservation status applies.

== Basic concept ==

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow object
| Represents a manually created material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Technical base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Related storage object
| Represents a physical storage location for materials.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Technical base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number.
|-
| PACKAGING_UNIT
| string
| Packaging unit.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure.
|-
| MATERIAL_TYPE / MaterialType
| int / enum
| Material type.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

Known values of MaterialType are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS / MaterialStatus
| int / enum
| Material status.
| User/admin managed property
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through MaterialStatus.

The property is managed by the user or administrator. The system does not change it automatically.

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive and should not be used for new reservations.
|-
| Active
| 20
| Material is active and can be used for reservations.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

=== Available quantity ===

The available material quantity is calculated by AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a manually created material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and the actually issued or consumed quantity in QUANTITY.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS / Status
| int / enum
| Reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actually issued or consumed quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

== StorageLocation ==

=== Purpose ===

StorageLocation is a related object used to represent a physical storage location.

A material can reference a storage location via LK_STORAGE_LOCATION.

=== Important properties and values ===

{| class="wikitable"
! Property
! Type
! Values / meaning
|-
| STORAGE_TYPE / StorageType
| int / enum
| Floor, Shelf, Rack, Bin, Pallet, Container
|-
| ACCESS_TYPE / AccessType
| int / enum
| Manual, Forklift, Crane, Automated
|-
| OCCUPANCY_STATUS / OccupancyStatus
| int / enum
| Empty, Partial, Full, Reserved, Blocked, OutOfService
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|}

== GoodsMovement ==

GoodsMovement is a technical base class.

It provides the common QUANTITY property for material-related objects such as Material and Reservation.

== Relations ==

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actually issued or consumed quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

Reservations are created manually by the user.

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK must point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material.

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the actually issued or consumed quantity through QUANTITY
* the reservation state through Status

This means that material usage is tracked at task level.

== Example workflow ==

=== Step 1: Material master exists ===

A spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A user manually creates a Reservation and links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Actual quantity is entered ===

The actually issued or consumed quantity is stored in Reservation.QUANTITY.

{| class="wikitable"
! Property
! Example
|-
| Reservation.QUANTITY
| 1
|}

=== Step 6: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual issued or consumed quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual issued or consumed quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

== See also ==
* [[MRO (Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MRO_Implemented_Objects]]
* [[MROMaintenancePlans]]
{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:48:44Z

LMA: /* Usage in tasks */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:48:34Z

LMA: /* Occupancy status */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information explicitly confirms the relation to tasks. Direct relations to work packages or work orders were not confirmed in the provided code analysis. If work packages or work orders use materials indirectly through tasks, that should be documented with the exact relation or navigation path.
</div>

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:48:18Z

LMA: /* Material status */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected StorageLocation information does not show automatic occupancy calculation. It is unclear from code whether OCCUPANCY_STATUS is updated manually, by workflow logic, or by another module.
</div>

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information explicitly confirms the relation to tasks. Direct relations to work packages or work orders were not confirmed in the provided code analysis. If work packages or work orders use materials indirectly through tasks, that should be documented with the exact relation or navigation path.
</div>

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:48:01Z

LMA: /* Material type */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected class information does not show specific methods that automatically change MaterialStatus. Status changes outside these classes are unclear from code.
</div>

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected StorageLocation information does not show automatic occupancy calculation. It is unclear from code whether OCCUPANCY_STATUS is updated manually, by workflow logic, or by another module.
</div>

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information explicitly confirms the relation to tasks. Direct relations to work packages or work orders were not confirmed in the provided code analysis. If work packages or work orders use materials indirectly through tasks, that should be documented with the exact relation or navigation path.
</div>

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:47:11Z

LMA: /* Goods movement usage */

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' No explicit SAP or ERP synchronization behavior was found in the inspected classes. ITEM_NUMBER may correspond to an external material number, but the exact SAP/ERP mapping is unclear from the available code information.
</div>

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected class information does not show specific methods that automatically change MaterialStatus. Status changes outside these classes are unclear from code.
</div>

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected StorageLocation information does not show automatic occupancy calculation. It is unclear from code whether OCCUPANCY_STATUS is updated manually, by workflow logic, or by another module.
</div>

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information explicitly confirms the relation to tasks. Direct relations to work packages or work orders were not confirmed in the provided code analysis. If work packages or work orders use materials indirectly through tasks, that should be documented with the exact relation or navigation path.
</div>

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T14:46:27Z

LMA:

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' No explicit SAP or ERP synchronization behavior was found in the inspected classes. ITEM_NUMBER may correspond to an external material number, but the exact SAP/ERP mapping is unclear from the available code information.
</div>

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected class information does not show specific methods that automatically change MaterialStatus. Status changes outside these classes are unclear from code.
</div>

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected StorageLocation information does not show automatic occupancy calculation. It is unclear from code whether OCCUPANCY_STATUS is updated manually, by workflow logic, or by another module.
</div>

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>

=== Finishing a task ===

When a task is finished, the task logic calls CloseReservations().

The method processes active reservations for the task:

* if a reservation has status Confirmed, it is set to Issued
* otherwise, it is set to Cancelled

The changed reservations are added to the unsaved children through AddToUnsavedChildren(reservation) so that the changes are persisted.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Workflow effect:''' Finishing a task closes its reservations. Confirmed reservations become Issued; other active reservations become Cancelled.
</div>

== Usage in tasks ==

Reservations are the central link between material handling and task execution.

A reservation connects:

* the required material through LK_MATERIAL
* the task through LK_TASK
* the planned quantity through QTY_PLANNED
* the reservation state through Status

This means that material usage is tracked at task level in the inspected implementation.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information explicitly confirms the relation to tasks. Direct relations to work packages or work orders were not confirmed in the provided code analysis. If work packages or work orders use materials indirectly through tasks, that should be documented with the exact relation or navigation path.
</div>

== Goods movement usage ==

GoodsMovement is the common base class for quantity-bearing material objects.

Both Material and Reservation inherit from it and expose QUANTITY.

In the inspected implementation:

* Material.QUANTITY represents the material quantity
* Reservation.QUANTITY represents the actual quantity for the reservation and applies reservation-specific validation
* Reservation.QTY_PLANNED represents the planned reserved quantity
* Material.RESERVED_QUANTITY is calculated from confirmed reservations

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected information describes GoodsMovement as a base class for quantity-bearing objects. It does not confirm separate movement types such as goods receipt, goods issue, transfer, correction, or consumption postings.
</div>

== Example workflow ==

=== Scenario ===

A task requires one spare part from stock.

=== Step 1: Material master exists ===

The spare part is defined as a MaterialMaster.

{| class="wikitable"
! Field
! Example
|-
| ITEM_NUMBER
| OF-10045
|-
| UNIT_OF_MEASURE
| Piece
|-
| MaterialType
| SpareParts
|}

=== Step 2: Material exists in a storage location ===

A Material object references the material master and a storage location.

{| class="wikitable"
! Property
! Example
|-
| LK_MATERIAL_MASTER
| Oil Filter Type A
|-
| LK_STORAGE_LOCATION
| Storage Shelf A
|-
| QUANTITY
| 10
|-
| RESERVED_QUANTITY
| 0
|-
| AvailableQuantity()
| 10
|}

=== Step 3: Reservation is created for a task ===

A Reservation links the material to the task.

{| class="wikitable"
! Property
! Example
|-
| LK_TASK
| Replace oil filter
|-
| LK_MATERIAL
| Oil Filter Type A
|-
| Status
| Planned
|-
| QTY_PLANNED
| 1
|}

The planned quantity is allowed because the material has enough available quantity.

=== Step 4: Reservation is confirmed ===

The reservation status is changed to Confirmed.

After confirmation, the material's reserved quantity includes the reservation's planned quantity.

{| class="wikitable"
! Quantity
! Value
|-
| Material.QUANTITY
| 10
|-
| Material.RESERVED_QUANTITY
| 1
|-
| Material.AvailableQuantity()
| 9
|}

=== Step 5: Task is finished ===

When the task is finished, CloseReservations() is called.

The confirmed reservation is changed to Issued.

== Validation and business rules ==

The following business rules are implemented in the inspected material management logic.

{| class="wikitable"
! Area
! Rule
! Implemented by
|-
| Planned reservation quantity
| QTY_PLANNED must be greater than 0.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED can only be changed while the reservation is Planned.
| AllowQuantityPlanned(double)
|-
| Planned reservation quantity
| QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().
| AllowQuantityPlanned(double)
|-
| Actual reservation quantity
| QUANTITY must be greater than 0.
| AllowQuantity(double)
|-
| Actual reservation quantity
| QUANTITY can only be changed while the reservation is Planned or Confirmed.
| AllowQuantity(double)
|-
| Reservation status
| Status cannot be changed once the reservation is Issued.
| AllowStatusChange(int newStatus)
|-
| Reservation status
| A reservation cannot be changed from Confirmed back to Planned.
| AllowStatusChange(int newStatus)
|-
| Reservation links
| LK_TASK and LK_MATERIAL cannot be changed when status is Issued or Confirmed.
| Property setters
|-
| Material deletion
| Material cannot be deleted while QUANTITY is greater than 0.
| InternalDeleteAllowed()
|-
| Material deletion
| Material cannot be deleted while active reservations exist.
| InternalDeleteAllowed() and HasActiveReservation()
|}

{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T09:04:40Z

LMA:

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management features provide the foundation for handling materials, material master data, reservations, storage locations, and goods movements in MRO workflows. The central objects are Material, MaterialMaster, Reservation, GoodsMovement, and StorageLocation. Materials are linked to master data and storage locations. Reservations link materials to tasks and define planned or actual quantities for maintenance work.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task
* which material master data belongs to a material
* where the material is stored
* how much material is available
* how much material is already reserved
* which reservations exist for a task
* whether a reservation is planned, confirmed, issued, cancelled, or expired

The material management implementation separates the general material catalogue from the actual material quantity and reservation handling.

== Basic concept ==

The material management implementation is built around the following main objects:

{| class="wikitable"
! Object
! Type
! Purpose
|-
| MaterialMaster
| Master data
| Defines the catalogue entry for a material, including item number, unit, packaging, manufacturer data, and material type.
|-
| Material
| Quantity-bearing MRO object
| Represents a material instance or stock entry in MRO. It links to a material master and a storage location and exposes quantity, reserved quantity, and available quantity logic.
|-
| Reservation
| Workflow / transaction object
| Represents a material reservation for a task. It links a material to a task and stores planned and actual quantities.
|-
| GoodsMovement
| Base class
| Provides the common QUANTITY property used by both materials and reservations.
|-
| StorageLocation
| Storage master / location object
| Represents a physical storage location and stores storage-related information such as storage type, dimensions, access type, and occupancy status.
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Core idea:''' MaterialMaster defines what the material is. Material represents the material in the MRO stock or material context. Reservation links a material to a task and reserves a planned quantity for maintenance execution.
</div>

== Object overview ==

{| class="wikitable"
! Object
! Class name
! Base / inheritance
! Main relations
|-
| Material
| UBIK.MRO.Material
| Inherits from GoodsMovement
| LK_MATERIAL_MASTER, LK_STORAGE_LOCATION
|-
| Material Master
| UBIK.MRO.MaterialMaster
| Master data class
| Referenced by Material via LK_MATERIAL_MASTER
|-
| Reservation
| UBIK.MRO.Reservation
| Inherits from GoodsMovement
| LK_TASK, LK_MATERIAL
|-
| Goods Movement
| UBIK.MRO.GoodsMovement
| Base class
| Provides QUANTITY to derived objects
|-
| Storage Location
| UBIK.MRO.StorageLocation
| Functional location specialization
| Referenced by Material via LK_STORAGE_LOCATION
|}

== GoodsMovement ==

=== Purpose ===

GoodsMovement is the base class for material-related quantity-bearing objects.

It defines the common quantity concept used by both:

* Material
* Reservation

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| QUANTITY
| double
| Quantity value for the goods movement. For Material, this is the material quantity. For Reservation, this is the actual reservation quantity and has reservation-specific validation.
|}

== MaterialMaster ==

=== Purpose ===

MaterialMaster represents the material master or catalogue entry.

It stores item-level master data that can be referenced by material instances in MRO.

A material master describes the material independently from a concrete reservation or task.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| ITEM_NUMBER
| string
| Item number or material number of the material master.
|-
| PACKAGING_UNIT
| string
| Packaging unit of the material.
|-
| PACKAGING_SIZE
| double
| Packaging size.
|-
| ACTIVE
| bool
| Defines whether the material master is active.
|-
| UNIT_OF_MEASURE
| string
| Unit of measure used for the material.
|-
| MATERIAL_TYPE
| int
| Underlying integer value for the material type.
|-
| MaterialType
| enum
| Typed accessor for MATERIAL_TYPE.
|-
| MANUFACTURER_COMPANY_NAME
| string
| Manufacturer company name.
|-
| MANUFACTURER_PRODUCT_TAG
| string
| Manufacturer product tag or product identifier.
|}

=== Material type ===

The typed material type accessor is MaterialType.

Known values are:

* SpareParts
* Consumables
* Tools

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' No explicit SAP or ERP synchronization behavior was found in the inspected classes. ITEM_NUMBER may correspond to an external material number, but the exact SAP/ERP mapping is unclear from the available code information.
</div>

== Material ==

=== Purpose ===

Material represents a material instance or stock entry in MRO.

It inherits from GoodsMovement and therefore uses the inherited QUANTITY property as its material quantity.

A material links to:

* a material master via LK_MATERIAL_MASTER
* a storage location via LK_STORAGE_LOCATION

It also exposes calculated reservation and availability logic.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Stored or calculated
|-
| LK_MATERIAL_MASTER
| MaterialMaster
| Link to the material master data.
| Stored link
|-
| LK_STORAGE_LOCATION
| StorageLocation
| Link to the storage location where the material is located.
| Stored link
|-
| QUANTITY
| double
| Material quantity. Inherited from GoodsMovement.
| Stored property
|-
| RESERVED_QUANTITY
| double
| Sum of planned quantities of confirmed reservations for this material.
| Calculated property
|-
| MATERIAL_STATUS
| int
| Underlying integer value for the material status.
| Stored property
|-
| MaterialStatus
| enum
| Typed accessor for MATERIAL_STATUS.
| Stored through MATERIAL_STATUS
|}

=== Material status ===

The material status is stored in MATERIAL_STATUS and exposed through the typed accessor MaterialStatus.

Known values are:

{| class="wikitable"
! Value
! Numeric value
! Meaning
|-
| Undefined
| 0
| No specific material status is defined.
|-
| Inactive
| 10
| Material is inactive.
|-
| Active
| 20
| Material is active.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected class information does not show specific methods that automatically change MaterialStatus. Status changes outside these classes are unclear from code.
</div>

=== Reserved quantity ===

RESERVED_QUANTITY is calculated at read time.

The calculation uses reservations where:

* LK_MATERIAL points to the current material
* STATUS is ReservationStatus.Confirmed

The calculated value is the sum of QTY_PLANNED of these confirmed reservations.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' RESERVED_QUANTITY is not treated as a normal stored quantity in the business logic. It is computed from confirmed Reservation objects.
</div>

=== Available quantity ===

The available material quantity is calculated by the method AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Active reservations ===

The method HasActiveReservation() checks whether active reservations exist for the material.

It queries reservations where:

* LK_MATERIAL points to the current material
* STATUS is lower than or equal to ReservationStatus.Confirmed

This means the method considers reservations up to the confirmed state as active.

=== Delete behavior ===

Material.InternalDeleteAllowed() prevents deleting a material if it still has quantity or active reservations.

Deletion is only allowed if the base delete conditions are fulfilled and:

* QUANTITY is lower than or equal to 0
* HasActiveReservation() returns false

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' A Material cannot be deleted while it has a quantity greater than 0 or active reservations.
</div>

== Reservation ==

=== Purpose ===

Reservation represents a material reservation for a task.

It links:

* a task via LK_TASK
* a material via LK_MATERIAL

It stores the planned reservation quantity in QTY_PLANNED and can also store an actual quantity through the overridden QUANTITY property.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
! Important behavior
|-
| LK_TASK
| Task
| Link to the task for which the material is reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| LK_MATERIAL
| Material
| Link to the material being reserved.
| Setter is blocked when status is Issued or Confirmed.
|-
| STATUS
| int
| Underlying integer value for the reservation status.
| Changes are validated by AllowStatusChange(int newStatus).
|-
| Status
| ReservationStatus
| Typed accessor for STATUS.
| Uses the ReservationStatus enum.
|-
| QTY_PLANNED
| double
| Planned quantity for the reservation.
| Setter validates through AllowQuantityPlanned(double).
|-
| QUANTITY
| double
| Actual reservation quantity. Overrides GoodsMovement.QUANTITY.
| Setter validates through AllowQuantity(double).
|}

=== Reservation status ===

The reservation status is stored in STATUS and exposed through the typed accessor Status.

Known values of ReservationStatus are:

{| class="wikitable"
! Status
! Numeric value
! Meaning
|-
| Planned
| 0
| Reservation is planned.
|-
| Confirmed
| 10
| Reservation is confirmed and contributes to the material's reserved quantity.
|-
| Issued
| 20
| Material has been physically issued.
|-
| Cancelled
| 30
| Reservation was cancelled. This is only allowed if the reservation has not been issued.
|-
| Expired
| 50
| Reservation has expired.
|}

=== Status change rules ===

Status changes are controlled by AllowStatusChange(int newStatus).

The following rules are applied:

* no status change is allowed when the current status is Issued
* changing from Confirmed back to Planned is not allowed
* other status changes are allowed by this method

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Restriction:''' Once a reservation has status Issued, its status can no longer be changed by the normal status setter logic.
</div>

=== Planned quantity validation ===

The setter of QTY_PLANNED validates changes through AllowQuantityPlanned(double).

A new planned quantity is only allowed if:

* Status is ReservationStatus.Planned
* LK_MATERIAL is assigned
* the new quantity is greater than 0
* the new quantity is lower than or equal to LK_MATERIAL.AvailableQuantity()

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Quantity rule:''' A planned reservation quantity can only be set while the reservation is still Planned and only if the selected material has enough available quantity.
</div>

=== Actual quantity validation ===

The overridden QUANTITY setter validates changes through AllowQuantity(double).

A new actual quantity is only allowed if:

* the new quantity is greater than 0
* the status is either Planned or Confirmed

=== Link editing rules ===

The setters of LK_TASK and LK_MATERIAL are guarded by reservation status.

The links cannot be changed when the reservation is:

* Issued
* Confirmed

This prevents changing the task or material after the reservation has reached a more binding status.

== StorageLocation ==

=== Purpose ===

StorageLocation represents a physical storage location.

It is a functional location specialization and can be linked from Material via LK_STORAGE_LOCATION.

A storage location stores information about storage type, dimensions, access type, label, level, position, and occupancy.

=== Important properties ===

{| class="wikitable"
! Property
! Type
! Meaning
|-
| STORAGE_TYPE
| int
| Underlying integer value for storage type.
|-
| StorageType
| enum
| Typed accessor for STORAGE_TYPE.
|-
| MAX_WEIGHT
| double
| Maximum allowed weight for the storage location.
|-
| MAX_VOLUME
| double
| Maximum allowed volume for the storage location.
|-
| LENGTH
| double
| Length of the storage location.
|-
| WIDTH
| double
| Width of the storage location.
|-
| HEIGHT
| double
| Height of the storage location.
|-
| ACCESS_TYPE
| int
| Underlying integer value for access type.
|-
| AccessType
| enum
| Typed accessor for ACCESS_TYPE.
|-
| STORAGE_LABEL
| string
| Label of the storage location.
|-
| LEVEL
| int
| Level of the storage location.
|-
| POSITION
| string
| Position identifier.
|-
| OCCUPANCY_STATUS
| int
| Underlying integer value for occupancy status.
|-
| OccupancyStatus
| enum
| Typed accessor for OCCUPANCY_STATUS.
|}

=== Storage type ===

Known values of StorageType are:

* Floor
* Shelf
* Rack
* Bin
* Pallet
* Container

=== Access type ===

Known values of AccessType are:

* Manual
* Forklift
* Crane
* Automated

=== Occupancy status ===

Known values of OccupancyStatus are:

* Empty
* Partial
* Full
* Reserved
* Blocked
* OutOfService

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The inspected StorageLocation information does not show automatic occupancy calculation. It is unclear from code whether OCCUPANCY_STATUS is updated manually, by workflow logic, or by another module.
</div>

== Relations ==

The following relations are relevant for material management.

{| class="wikitable"
! Relation
! Source
! Target
! Meaning
|-
| LK_MATERIAL_MASTER
| Material
| MaterialMaster
| Links a material instance to its master data.
|-
| LK_STORAGE_LOCATION
| Material
| StorageLocation
| Defines where the material is stored.
|-
| LK_MATERIAL
| Reservation
| Material
| Defines which material is reserved.
|-
| LK_TASK
| Reservation
| Task
| Defines the task for which the material is reserved.
|}

== Quantity concepts ==

=== Material quantity ===

The material quantity is stored in Material.QUANTITY.

Because Material inherits from GoodsMovement, the property is inherited from the base class.

=== Reserved quantity ===

The reserved quantity is exposed through Material.RESERVED_QUANTITY.

It is calculated by summing the QTY_PLANNED values of confirmed reservations for the material.

Only reservations with Status equal to ReservationStatus.Confirmed are included in this calculation.

=== Available quantity ===

Available quantity is calculated by Material.AvailableQuantity().

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - RESERVED_QUANTITY
</div>

=== Planned reservation quantity ===

The planned reservation quantity is stored in Reservation.QTY_PLANNED.

It can only be set if:

* the reservation is still Planned
* a material is assigned
* the quantity is greater than 0
* the quantity does not exceed the material's available quantity

=== Actual reservation quantity ===

The actual reservation quantity is stored in Reservation.QUANTITY.

This property overrides GoodsMovement.QUANTITY and can only be set if the status is Planned or Confirmed and the new quantity is greater than 0.

=== Quantity overview ===

{| class="wikitable"
! Quantity
! Property / method
! Object
! Stored or calculated
! Notes
|-
| Material quantity
| QUANTITY
| Material
| Stored
| Inherited from GoodsMovement.
|-
| Reserved quantity
| RESERVED_QUANTITY
| Material
| Calculated
| Sum of QTY_PLANNED of confirmed reservations for the material.
|-
| Available quantity
| AvailableQuantity()
| Material
| Calculated
| QUANTITY minus RESERVED_QUANTITY.
|-
| Planned reservation quantity
| QTY_PLANNED
| Reservation
| Stored
| Validated by AllowQuantityPlanned(double).
|-
| Actual reservation quantity
| QUANTITY
| Reservation
| Stored
| Overrides GoodsMovement.QUANTITY and is validated by AllowQuantity(double).
|}

== Reservation workflow ==

=== Creating or editing a reservation ===

A reservation links a material to a task.

For a reservation to define its planned quantity correctly:

# LK_MATERIAL must be set.
# LK_TASK should point to the task requiring the material.
# Status must still be Planned.
# QTY_PLANNED must be greater than 0.
# QTY_PLANNED must not exceed LK_MATERIAL.AvailableQuantity().

=== Confirmed reservations ===

When a reservation is confirmed, it contributes to the material's reserved quantity.

This affects the available quantity of the material because:

<div style="font-family: Consolas, 'Courier New', monospace; color: #202122; background-color: #f8f9fa; border: 1px solid #c8ccd1; border-radius: 3px; padding: 8px 10px; margin: 10px 0;">
AvailableQuantity = QUANTITY - sum(QTY_PLANNED of confirmed reservations)
</div>
{{UnderConstructionEnd}}

MRO Material Management

2026-06-18T09:02:41Z

LMA:

MRO Material Management

2026-06-17T14:23:58Z

LMA:

MRO Material Management

2026-06-17T10:02:10Z

LMA:

MRO Material Management

2026-06-16T12:37:59Z

LMA:

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management concept describes how materials are defined, requested, reserved, and used in maintenance workflows. It explains the relationship between material-related objects such as Material, Material Master, and Reservation, and how these objects are connected to tasks or work packages.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task or work package
* whether the required material is available
* how much material is required
* how much material has already been reserved
* whether the material can be used
* whether a reservation is still open, fulfilled, or no longer relevant

The material management concept separates the general definition of a material from its actual usage in maintenance work.

A material can be defined centrally as master data and then used in different tasks, work packages, or reservations.

{{UnderConstructionEnd}}

MRO Material Management

2026-06-16T12:28:34Z

LMA: Created page with "{{UnderConstructionStart}} == MRO Material Management == <div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;"> '''Summary:..."

{{UnderConstructionStart}}
== MRO Material Management ==

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The MRO material management concept describes how materials are defined, requested, reserved, and used in maintenance workflows. It explains the relationship between material-related objects such as Material, Material Master, and Reservation, and how these objects are connected to tasks or work packages.
</div>

MRO material management is used to support maintenance work with the required spare parts, consumables, tools, or other material items.

In a maintenance workflow, users may need to know:

* which material is required for a task or work package
* whether the required material is available
* how much material is required
* how much material has already been reserved
* whether the material can be used
* whether a reservation is still open, fulfilled, or no longer relevant

The material management concept separates the general definition of a material from its actual usage in maintenance work.

A material can be defined centrally as master data and then used in different tasks, work packages, or reservations.

== Basic concept ==

The material management feature is built around the following main concepts:

{| class="wikitable"
! Concept
! Purpose
! Typical usage
|-
| Material Master
| Defines the master data of a material.
| Used as the central reference for material identity, description, unit, and related master data.
|-
| Material
| Represents a material item used in the MRO context.
| Used to describe material that can be assigned, requested, or consumed in maintenance workflows.
|-
| Reservation
| Represents a request or reservation for a certain quantity of material.
| Used to reserve material for a task, operation, or work package.
|-
| Task or Work Package
| Represents the maintenance work that requires material.
| Material requirements and reservations are linked to the maintenance execution object.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Note:''' The exact object names, relation names, and property names may differ depending on the MRO configuration. This page describes the concept and should be aligned with the actual implementation before it is published as final technical documentation.
</div>

== Object overview ==

The following simplified overview shows how the material-related objects are typically connected.

{| class="wikitable"
! Object
! Related to
! Description
|-
| Material Master
| Material
| Provides the master data for a material.
|-
| Material
| Task or Work Package
| Describes which material is needed or used for the maintenance activity.
|-
| Reservation
| Material and Task or Work Package
| Reserves a specific quantity of material for a specific maintenance activity.
|}

== Material Master ==

=== Purpose ===

The Material Master represents the central master data record for a material.

It describes the material independently from a specific maintenance task or work package.

The Material Master is used to provide consistent information about materials across the MRO system.

This can include, for example:

* material number
* material name
* material description
* base unit of measure
* material group
* manufacturer information
* external ERP or SAP reference
* default storage or warehouse information
* default status information

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Concept:''' The Material Master should be understood as the reusable definition of a material. It does not by itself describe that material is required for a specific task. The concrete usage is handled by material assignments, requirements, or reservations.
</div>

=== Typical responsibilities ===

The Material Master is typically responsible for:

* identifying a material uniquely
* providing the default description of the material
* defining the base unit in which the material is handled
* providing references to external systems
* allowing users to select the correct material when planning maintenance work

=== Example ===

A maintenance team regularly needs a specific oil filter.

The oil filter is defined once as a Material Master.

{| class="wikitable"
! Field
! Example value
|-
| Material number
| OF-10045
|-
| Name
| Oil Filter Type A
|-
| Description
| Standard oil filter for Pump Series A
|-
| Base unit
| Piece
|-
| Material group
| Spare Parts
|}

When a task or work package requires this oil filter, the task does not define the oil filter again from scratch. Instead, it references the existing Material Master or a material object based on it.

== Material ==

=== Purpose ===

A Material represents a material item used in MRO workflows.

Depending on the implementation, the Material object may either represent:

* a concrete material based on a Material Master
* a material requirement assigned to a task or work package
* a material item available for planning, reservation, or consumption

The Material object is used to bring material information into the maintenance workflow.

=== Relationship to Material Master ===

A Material is typically based on or linked to a Material Master.

The Material Master provides the general definition.

The Material object provides the MRO-specific usage context.

{| class="wikitable"
! Aspect
! Material Master
! Material
|-
| Main purpose
| Defines the material as master data.
| Uses the material in an MRO context.
|-
| Scope
| General and reusable.
| Workflow-specific or MRO-specific.
|-
| Example
| Oil Filter Type A.
| Oil Filter Type A required for Work Package 4711.
|}

=== Typical material information ===

A Material object may contain or reference information such as:

* material master reference
* material number
* name or description
* required quantity
* available quantity
* reserved quantity
* unit of measure
* material status
* storage location or warehouse
* reference to a task or work package

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Implementation check required:''' This page should be aligned with the actual MRO data model to clarify whether quantity fields are stored directly on the Material object, calculated from related Reservation objects, or received from an external system.
</div>

== Reservation ==

=== Purpose ===

A Reservation represents a request to reserve a specific quantity of material for maintenance work.

It connects material demand with a task, operation, or work package.

A reservation is used when material should be set aside or requested before the maintenance work is executed.

=== Typical reservation information ===

A Reservation usually contains:

* reference to the material
* reference to the task or work package
* requested quantity
* reserved quantity
* open quantity
* unit of measure
* reservation status
* requested date or required date
* storage location or warehouse
* external reservation number, if synchronized with an external system

=== Relationship to tasks or work packages ===

Reservations are created for maintenance work.

Depending on the workflow, a reservation may be linked to:

* a task
* an operation
* a work package
* a work order
* a work package template, if material requirements are predefined

The reservation allows users to see which material has been requested or reserved for the maintenance activity.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Example:''' A work package for pump maintenance requires two oil filters. A reservation is created for quantity 2 of the oil filter material. The maintenance team can then see that the material is required and should be available for the work package.
</div>

== Material quantity concepts ==

=== Material quantity ===

Material quantity describes how much of a material is required, available, reserved, or consumed.

The meaning of a quantity depends on the context in which it is used.

{| class="wikitable"
! Quantity concept
! Meaning
! Example
|-
| Required quantity
| Quantity needed to execute the task or work package.
| 2 oil filters are needed for pump maintenance.
|-
| Reserved quantity
| Quantity that has already been reserved for the task or work package.
| 2 oil filters are reserved for the work package.
|-
| Available quantity
| Quantity currently available for use or reservation.
| 15 oil filters are available in the warehouse.
|-
| Consumed quantity
| Quantity actually used during execution.
| 1 oil filter was used during the maintenance work.
|-
| Open quantity
| Quantity still missing or not yet reserved.
| Required quantity 5, reserved quantity 3, open quantity 2.
|}

=== Reserved quantity ===

Reserved quantity describes the amount of material that has been reserved for a task, operation, or work package.

It answers the question:

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Question:''' How much of the required material has already been reserved for this maintenance work?
</div>

Example:

{| class="wikitable"
! Required quantity
! Reserved quantity
! Result
|-
| 5
| 0
| No material has been reserved yet.
|-
| 5
| 3
| The reservation is partially fulfilled.
|-
| 5
| 5
| The required material quantity is fully reserved.
|-
| 5
| 7
| More material is reserved than required. This may require review, depending on the business rules.
|}

<div style="border-left: 4px solid #d33; background-color: #fff5f5; padding: 10px 12px; margin: 12px 0;">
'''Potential issue:''' If the reserved quantity is greater than the required quantity, the case should be checked against the business rules. It may be valid in some workflows, but it can also indicate an incorrect reservation quantity.
</div>

== Material status ==

=== Purpose ===

Material status describes whether a material can currently be used in the maintenance workflow.

The material status can help users understand if a material is available, blocked, obsolete, or otherwise restricted.

=== Typical material statuses ===

The following statuses are examples and must be aligned with the actual MRO implementation.

{| class="wikitable"
! Status
! Meaning
! Effect
|-
| Available
| The material can be used or reserved.
| Users can select and use the material in maintenance workflows.
|-
| Reserved
| The material or part of its quantity is reserved.
| The material is already assigned to one or more maintenance activities.
|-
| Blocked
| The material must not be used.
| Users should not use the material for new reservations or work packages.
|-
| Obsolete
| The material is no longer intended for use.
| The material should be replaced by another material or removed from active workflows.
|-
| Out of stock
| No available quantity exists.
| The material cannot be fulfilled until stock is replenished.
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Note:''' The exact status values must be taken from the actual MRO status model. This section should not introduce status values that do not exist in the implementation.
</div>

== Reservation status ==

=== Purpose ===

Reservation status describes the current state of a material reservation.

It helps users understand whether a reservation is still open, partially fulfilled, fulfilled, cancelled, or completed.

=== Typical reservation statuses ===

The following statuses are examples and must be aligned with the actual MRO implementation.

{| class="wikitable"
! Status
! Meaning
! Typical situation
|-
| Open
| The reservation has been created but not yet fulfilled.
| Material has been requested, but no quantity has been reserved yet.
|-
| Partially Reserved
| Only part of the required quantity has been reserved.
| Required quantity is 5, reserved quantity is 3.
|-
| Reserved
| The full required quantity has been reserved.
| Required quantity is 5, reserved quantity is 5.
|-
| Issued
| The material has been handed out or issued for execution.
| The maintenance team has received the material.
|-
| Consumed
| The material has been used during execution.
| The material usage has been confirmed.
|-
| Cancelled
| The reservation is no longer required.
| The work package was cancelled or the material is no longer needed.
|}

=== Status calculation ===

Depending on the implementation, the reservation status may be:

* set manually by the user
* calculated from quantity values
* updated by the system during workflow transitions
* synchronized from an external ERP or warehouse system

Example status calculation:

{| class="wikitable"
! Condition
! Possible reservation status
|-
| Reserved quantity is 0
| Open
|-
| Reserved quantity is greater than 0 and lower than required quantity
| Partially Reserved
|-
| Reserved quantity is equal to required quantity
| Reserved
|-
| Reservation was cancelled
| Cancelled
|}

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Implementation check required:''' The final wiki page should document whether reservation status is calculated in MRO, entered manually, or imported from an external system.
</div>

== Usage in tasks or work packages ==

=== Purpose ===

Tasks and work packages represent maintenance work.

Material management is used to define and track which materials are required for this maintenance work.

Material usage can occur during different phases of the maintenance process.

{| class="wikitable"
! Phase
! Material handling
! Example
|-
| Planning
| Required materials are selected and planned.
| The planner adds two oil filters to the pump maintenance work package.
|-
| Preparation
| Required materials are reserved or requested.
| A reservation is created for two oil filters.
|-
| Execution
| The maintenance team uses the material.
| One oil filter is installed during the task.
|-
| Completion
| Actual material usage is confirmed.
| The consumed quantity is recorded.
|}

=== Material requirements on work packages ===

A work package may contain one or more material requirements.

Each material requirement describes which material is needed and in which quantity.

Example:

{| class="wikitable"
! Work package
! Material
! Required quantity
! Unit
|-
| Pump Maintenance WP-4711
| Oil Filter Type A
| 2
| Piece
|-
| Pump Maintenance WP-4711
| Lubricating Oil
| 5
| Liter
|}

=== Material requirements on tasks ===

If material is linked to individual tasks, the material requirement can be more precise.

Example:

{| class="wikitable"
! Task
! Material
! Required quantity
! Unit
|-
| Replace oil filter
| Oil Filter Type A
| 1
| Piece
|-
| Refill oil
| Lubricating Oil
| 5
| Liter
|}

This allows the system and users to understand exactly which material is required for each task.

=== Reservations for work packages ===

A reservation may be created for a complete work package.

This is useful when the material should be prepared for the whole maintenance activity.

Example:

A work package contains three tasks.

The planner creates one material reservation for all required material of the work package.

The warehouse prepares the material before the work package starts.

=== Reservations for tasks ===

A reservation may also be created for a specific task.

This is useful when material usage should be tracked at task level.

Example:

Task: Replace oil filter

Required material: Oil Filter Type A

Required quantity: 1

Reservation: 1 Oil Filter Type A

== Example workflow ==

=== Scenario ===

A pump requires planned maintenance.

The work package contains one task for replacing an oil filter.

=== Step 1: Material Master exists ===

The oil filter is defined as a Material Master.

{| class="wikitable"
! Field
! Value
|-
| Material number
| OF-10045
|-
| Name
| Oil Filter Type A
|-
| Base unit
| Piece
|}

=== Step 2: Material is assigned to the task ===

The task requires one oil filter.

{| class="wikitable"
! Task
! Material
! Required quantity
|-
| Replace oil filter
| Oil Filter Type A
| 1
|}

=== Step 3: Reservation is created ===

A reservation is created for the required material.

{| class="wikitable"
! Reservation
! Material
! Required quantity
! Reserved quantity
! Status
|-
| RES-90001
| Oil Filter Type A
| 1
| 1
| Reserved
|}

=== Step 4: Material is used during execution ===

During execution, the oil filter is installed.

The consumed quantity is recorded, if supported by the implementation.

{| class="wikitable"
! Material
! Reserved quantity
! Consumed quantity
! Result
|-
| Oil Filter Type A
| 1
| 1
| Material was fully used.
|}

=== Step 5: Work is completed ===

The task or work package is completed.

The material reservation can then be considered completed, consumed, or closed, depending on the workflow.

== Important rules and open implementation points ==

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The final documentation should be aligned with the real object model. In particular, relation names, property names, status values, and quantity calculation rules should be verified before the page is published.
</div>

The following information is required to finalize this page precisely:

{| class="wikitable"
! Topic
! Required information
! Why it matters
|-
| Object names
| Exact class names for Material, Material Master, and Reservation.
| Needed to document the real data model instead of generic concepts.
|-
| Relation names
| Exact relation names between Material, Material Master, Reservation, Task, Work Package, and Work Order.
| Needed for technical accuracy.
|-
| Quantity properties
| Exact property names for required quantity, reserved quantity, available quantity, consumed quantity, and open quantity.
| Needed to explain where quantities are stored and how they are calculated.
|-
| Status properties
| Exact property names and allowed values for Material status and Reservation status.
| Needed to avoid inventing unsupported status values.
|-
| Status logic
| Whether statuses are manual, calculated, workflow-driven, or imported from an external system.
| Needed to explain system behavior correctly.
|-
| ERP integration
| Whether materials and reservations are synchronized with SAP or another ERP system.
| Needed to document external references, synchronization rules, and ownership of data.
|-
| Usage level
| Whether material is assigned to tasks, operations, work packages, work orders, or multiple levels.
| Needed to describe the actual workflow correctly.
|-
| Reservation creation
| Whether reservations are created manually, automatically, from templates, or by an external system.
| Needed to explain the user workflow and automation.
|-
| Consumption handling
| Whether consumed quantities are recorded in MRO.
| Needed to document execution and completion behavior.
|-
| Validation rules
| Rules such as required quantity must be greater than 0, reservation cannot exceed available stock, or blocked material cannot be reserved.
| Needed to document important restrictions and error cases.
|}

{{UnderConstructionEnd}}

MROMaintenancePlans

2026-06-16T12:18:40Z

LMA:

MROMaintenancePlans

2026-06-16T07:30:36Z

LMA:

{{UnderConstructionStart}}
= MRO Maintenance Planning =

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Summary:''' The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans. The maintenance plan defines the rules. The generated work package is used by users to execute and complete the actual maintenance work.
</div>

== Overview ==

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

* when a work package should be created
* which asset the work package belongs to
* which template work package is used
* how the template work package is copied
* how many days before the planned execution date the work package may be generated
* how future planning dates are calculated

The actual maintenance work is not executed by the maintenance plan itself. The maintenance plan creates work packages. These generated work packages are then used by users to execute and complete the maintenance work.

In MRO, MaintenancePlan is the abstract base class for maintenance planning. It provides the common foundation for maintenance plans, but it is not intended to be used directly.

The fully implemented maintenance plan types in standard MRO are:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Custom maintenance plan types can be implemented by deriving from the abstract MaintenancePlan base class. However, the standard MRO maintenance planning feature is based on cyclic maintenance plans and round maintenance plans.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Important:''' CyclicMaintenancePlan and RoundMaintenancePlan support recurrence-based scheduling. This includes planned execution dates, automatic work package generation, calendar-based scheduling, completion-based scheduling, automatic recalculation of scheduling dates, and generation based on due dates.
</div>

RoundMaintenancePlan additionally supports maintenance rounds. A round maintenance plan creates one main work package for the round. It can also create additional work packages from child maintenance plans linked via SYSREL_ROUND_RELATION. These additional work packages are assigned to the main round work package.

== Basic Concept ==

The maintenance planning feature is built around four main parts:

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

=== Maintenance Plan ===

The maintenance plan defines the rules for creating work packages.

This includes, for example:

* when a work package should be created
* which asset the work package should belong to
* how many days before the planned execution date the work package may be created
* which template work package should be used
* which recurrence pattern should be used
* whether future dates are calculated calendar-based or completion-based

=== Template Work Package ===

The template work package defines what the generated work package should look like.

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

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

=== Replication Configuration ===

The replication configuration defines how the template work package is copied.

This includes, for example:

* which properties are copied
* how referenced objects are handled
* what the target meta class of the generated work package should be

=== Generated Work Package ===

The generated work package is the actual result created by the maintenance plan.

Example:

# A pump has to be inspected every month.
# A cyclic maintenance plan is created for this pump.
# The plan is configured with a monthly recurrence, an assigned asset, a template work package, and a replication configuration.
# When the plan becomes due, the system uses a replication job to create a new work package from the configured template work package.
# The generated work package is linked back to the maintenance plan via LK_MAINTENANCE_PLAN.

This link allows the maintenance plan to react when the generated work package is planned or completed.

== MaintenancePlan Base Class ==

=== Purpose ===

MaintenancePlan is the abstract base class for maintenance planning in MRO.

It provides the common properties and logic required by maintenance plan implementations.

Because MaintenancePlan is abstract, users do not create or use this base class directly in the standard MRO feature. Instead, the concrete maintenance plan types are used:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Developers can derive from the abstract base class if a project requires a custom maintenance plan type. In that case, the custom implementation must provide the missing plan-specific behavior.

=== Base Class Properties ===

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

=== LK_ASSET ===

LK_ASSET is the link to the asset that requires maintenance.

This can be, for example:

* equipment
* a functional location
* another customized maintainable object deriving from Asset

The generated work package is linked to the same asset.

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

=== LK_WP_TMPL ===

LK_WP_TMPL is the link to the template work package.

The template work package defines what the generated work package should look like.

When the maintenance plan creates a work package, the system copies the work package referenced by LK_WP_TMPL.

The linked work package must be a template work package. This means its ISTEMPLATE property must be set.

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

=== LK_REPLICATION_CONFIG ===

LK_REPLICATION_CONFIG is the link to the replication configuration.

The replication configuration defines how the template work package is copied into a generated work package.

It can define, for example:

* which properties are copied
* how references are copied
* what the target meta class of the generated work package should be

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

=== NEXT_DATE ===

NEXT_DATE defines the planned execution date of the next maintenance activity.

It answers the question: '''When should the next maintenance work be performed?'''

NEXT_DATE is not necessarily the date on which the work package is created.

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

In this example, the system may create the work package on 12 March, but the generated work package is planned for 15 March.

When a work package is generated, the generated work package receives the maintenance plan’s NEXT_DATE as its PLANNED_START.

=== LEAD_DAYS ===

LEAD_DAYS defines how many days before NEXT_DATE the system may create the work package.

This is used to create work packages before the actual planned execution date.

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

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

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system.

It defines the earliest date on which the maintenance plan may create a work package.

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

Example:

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

The maintenance planning orchestrator searches for active plans where EARLIEST_GENERATION_DATE has been reached.

A plan can be considered for automatic work package generation when:

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

If EARLIEST_GENERATION_DATE has not yet been reached, no work package is created.

=== PLAN_STATUS ===

PLAN_STATUS defines whether the maintenance plan is active or inactive.

Only active plans are considered for automatic work package generation. Inactive plans are ignored by the maintenance planning process.

Typical values are:

* Inactive
* Active

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

=== AUTO_CREATE ===

AUTO_CREATE defines whether the system is allowed to automatically create work packages from the maintenance plan.

If AUTO_CREATE is enabled, the maintenance planning orchestrator can create work packages once the plan is due.

If AUTO_CREATE is disabled, the plan does not automatically create work packages.

=== LAST_DATE ===

LAST_DATE stores the date when the most recent generated work package linked to the maintenance plan was completed.

This property is especially important for completion-based scheduling.

{| class="wikitable"
! Value
! Example
|-
| Previous generated work package completed
| 20 March
|-
| SCHEDULING_MODE
| Completion-Based
|-
| Next date is calculated from
| 20 March
|}

The system updates LAST_DATE when a generated work package is completed.

=== PRIORITY ===

PRIORITY is a numeric value that can be used to sort maintenance plans.

For round maintenance plans, there is also a property called PLAN_SELECTION_RULE.

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

== Work Package Properties Used by Maintenance Planning ==

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

=== LK_MAINTENANCE_PLAN ===

LK_MAINTENANCE_PLAN is set on generated work packages.

It stores the maintenance plan that triggered the creation of the work package.

This is important because the maintenance plan itself does not directly store a list of generated work packages. Instead, generated work packages reference their source maintenance plan via LK_MAINTENANCE_PLAN.

This link allows the system to find work packages created from a maintenance plan and to update the maintenance plan when a generated work package is planned or completed.

=== LK_WP_TMPL ===

On a generated work package, LK_WP_TMPL stores the template work package that was used to create the generated work package.

This allows users and the system to see which template was used as the source.

=== LK_ASSET ===

On a generated work package, LK_ASSET stores the asset for which the work package was created.

This is usually copied or assigned based on the maintenance plan’s LK_ASSET.

=== PLANNED_START ===

PLANNED_START stores the planned start date of the generated work package.

When a maintenance plan generates a work package, the system sets:

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

=== ORGA_STATUS ===

ORGA_STATUS is used to determine whether a generated work package is finished.

A work package is considered finished when:

<pre>
ORGA_STATUS == 100
</pre>

Open work packages are generated work packages linked to the maintenance plan where:

<pre>
ORGA_STATUS != 100
</pre>

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Generation rule:''' A maintenance plan does not create another work package while it still has an open generated work package.
</div>

=== TASK_OWNER ===

TASK_OWNER is used in round maintenance scenarios.

When a round maintenance plan creates a main work package and additional work packages from linked child plans, the additional work packages are assigned to the main round work package via TASK_OWNER.

=== ORDERID and GROUPID ===

ORDERID and GROUPID can be copied from the SYSREL_ROUND_RELATION relation to generated work packages in a round maintenance scenario.

They can be used to order or group the additional work packages that belong to the generated round work package.

== CyclicMaintenancePlan ==

=== Purpose ===

A CyclicMaintenancePlan is used for recurring maintenance work on an asset.

It is the standard maintenance plan type for maintenance activities that repeat according to a defined recurrence pattern.

Examples:

* inspect a pump every month
* service a machine every 6 months
* check safety equipment every Monday
* replace a filter every 30 days
* perform annual maintenance on a functional location

A cyclic maintenance plan uses RRULE to define the recurrence. It also uses SCHEDULING_MODE to define how future dates are calculated.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Key concept:''' SCHEDULING_MODE defines whether the plan follows fixed calendar dates or whether the next date depends on the actual completion date of the previous generated work package.
</div>

The supported scheduling modes are:

* Calendar-Based
* Completion-Based

== CyclicMaintenancePlan Properties ==

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

=== RRULE ===

RRULE defines the recurrence pattern of a cyclic maintenance plan.

It describes how often the maintenance should occur.

Examples:

<pre>
FREQ=DAILY
FREQ=WEEKLY;BYDAY=MO,WE,FR
FREQ=MONTHLY;BYMONTHDAY=15
</pre>

The system uses RRULE to calculate future planned execution dates.

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

=== RRULE_START_DATE ===

RRULE_START_DATE defines when the recurrence pattern starts.

The recurrence rule is calculated from this date forward.

Example:

{| class="wikitable"
! Setting
! Value
|-
| RRULE_START_DATE
| 01 January
|-
| RRULE
| Monthly on the 15th
|}

The system uses these values to determine valid planned execution dates.

=== RRULE_UNTIL_DATE ===

RRULE_UNTIL_DATE is an optional end date for the recurrence.

If this date is configured, no further occurrences are generated after this date.

This can be used for maintenance plans that should only run until a certain date.

=== RRULE_COUNT ===

RRULE_COUNT limits how many work packages can be created from the plan.

Example:

{| class="wikitable"
! Setting
! Value
|-
| RRULE_COUNT
| 10
|}

When the number of related generated work packages reaches RRULE_COUNT, the system no longer calculates new occurrences for the plan.

=== SCHEDULING_MODE ===

SCHEDULING_MODE defines how NEXT_DATE is calculated for a cyclic maintenance plan.

SCHEDULING_MODE is only relevant for concrete maintenance plan types that use recurrence logic, such as CyclicMaintenancePlan and RoundMaintenancePlan.

The supported scheduling modes are:

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

This property is one of the most important settings because it defines whether future dates follow the calendar or depend on the actual completion of the previous generated work package.

== Calendar-Based Scheduling ==

=== Purpose ===

Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences.

The next planned execution date is calculated according to RRULE and the calendar recurrence.

This means that delays in completing a work package do not automatically shift the whole future schedule.

Use calendar-based scheduling when the maintenance should happen on fixed dates or fixed calendar intervals.

Examples:

* inspection every 15th day of the month
* safety check every Monday
* yearly inspection every January
* quarterly maintenance in fixed maintenance windows

=== How Calendar-Based Scheduling Works ===

In calendar-based scheduling, the system calculates NEXT_DATE based on the recurrence rule and the relevant dates of existing generated work packages.

The system determines the highest relevant planned or finished date of generated work packages linked to the maintenance plan. Then it uses the recurrence rule to calculate the next valid occurrence after that date.

This means the schedule continues according to the recurrence pattern.

If a work package is completed later than planned, the future schedule does not necessarily move with that completion date.

=== Example: Calendar-Based Scheduling ===

A pump must be inspected on the 15th of every month.

==== Configuration ====

{| class="wikitable" style="width: 100%;"
! Setting
! Value
|-
| Plan type
| CyclicMaintenancePlan
|-
| LK_ASSET
| Pump 1
|-
| LK_WP_TMPL
| Pump Inspection Template
|-
| LK_REPLICATION_CONFIG
| Pump Inspection Replication
|-
| SCHEDULING_MODE
| Calendar-Based
|-
| RRULE
| Monthly on the 15th
|-
| RRULE_START_DATE
| 01 January
|-
| NEXT_DATE
| 15 March
|-
| LEAD_DAYS
| 3
|-
| PLAN_STATUS
| Active
|-
| AUTO_CREATE
| Enabled
|}

==== Result ====

The system calculates:

<pre>
EARLIEST_GENERATION_DATE = 12 March
</pre>

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

Generated work package:

{| class="wikitable"
! Property
! Value
|-
| PLANNED_START
| 15 March
|}

After the work package is planned, the system can calculate the next occurrence:

<pre>
NEXT_DATE = 15 April
</pre>

If the March work package is completed on 20 March, the next date still follows the monthly recurrence. The next planned execution date remains 15 April.

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Result:''' The late completion does not shift the future schedule to 20 April.
</div>

== Completion-Based Scheduling ==

=== Purpose ===

Completion-based scheduling is used when the next maintenance date should depend on the actual completion date of the previous generated work package.

This means that the interval starts after the work has actually been completed.

Use completion-based scheduling when the maintenance should repeat based on the time since the last completed maintenance activity.

Examples:

* service every 30 days after the last service
* inspection 6 months after the previous inspection was completed
* replacement 90 days after the previous replacement
* maintenance where a delay should also delay the next cycle

=== How Completion-Based Scheduling Works ===

In completion-based scheduling, the system recalculates NEXT_DATE after a generated work package is completed.

The completion date becomes the basis for the next occurrence.

Planning changes alone do not define the next recurrence in the same way as calendar-based scheduling.

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

=== Example: Completion-Based Scheduling ===

A machine must be serviced every 30 days after the previous service was completed.

==== Configuration ====

{| class="wikitable" style="width: 100%;"
! Setting
! Value
|-
| Plan type
| CyclicMaintenancePlan
|-
| LK_ASSET
| Machine 1
|-
| LK_WP_TMPL
| Machine Service Template
|-
| LK_REPLICATION_CONFIG
| Machine Service Replication
|-
| SCHEDULING_MODE
| Completion-Based
|-
| RRULE
| Every 30 days
|-
| RRULE_START_DATE
| 01 March
|-
| NEXT_DATE
| 15 March
|-
| LEAD_DAYS
| 3
|-
| PLAN_STATUS
| Active
|-
| AUTO_CREATE
| Enabled
|}

==== Result ====

The system calculates:

<pre>
EARLIEST_GENERATION_DATE = 12 March
</pre>

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

Generated work package:

{| class="wikitable"
! Property
! Value
|-
| PLANNED_START
| 15 March
|}

The work package is completed on 20 March.

Because the plan is completion-based, the system calculates the next date from 20 March.

If the recurrence is every 30 days:

{| class="wikitable"
! Value
! Example
|-
| NEXT_DATE
| around 19 April
|-
| LEAD_DAYS
| 3
|-
| EARLIEST_GENERATION_DATE
| around 16 April
|}

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Result:''' In this mode, the delay from 15 March to 20 March shifts the future schedule.
</div>

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

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

{| class="wikitable" style="width: 100%;"
! Aspect
! Calendar-Based
! Completion-Based
|-
| Basis for NEXT_DATE
| Recurrence defined by RRULE
| Actual completion date of the previous generated work package
|-
| Effect of late completion
| Future dates are not automatically shifted
| Future dates move with the completion date
|-
| Typical use case
| Fixed maintenance windows, fixed calendar intervals, legal or organizational inspection dates
| Service intervals that depend on the actual last maintenance
|-
| Example
| Planned: 15 March Completed: 20 March Next date: 15 April
| Planned: 15 March Completed: 20 March Interval: 30 days Next date: around 19 April
|}

=== Calendar-Based ===

Calendar-based scheduling should be used when the maintenance must follow fixed planned dates.

Characteristics:

* The plan follows the RRULE calendar pattern.
* Future dates are not automatically shifted just because a work package was completed late.
* NEXT_DATE can be recalculated after planning updates.
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates.

Example:

{| class="wikitable"
! Event
! Date
|-
| Planned inspection
| 15 March
|-
| Completed
| 20 March
|-
| Next date
| 15 April
|}

The future date stays aligned with the calendar recurrence.

=== Completion-Based ===

Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed.

Characteristics:

* The plan waits for completion.
* The completion date is used as the basis for NEXT_DATE.
* If the work is completed late, the future schedule moves.
* It is useful for service intervals that depend on the actual last maintenance.

Example:

{| class="wikitable"
! Event
! Date
|-
| Planned service
| 15 March
|-
| Completed
| 20 March
|-
| Interval
| 30 days
|-
| Next date
| around 19 April
|}

The future date shifts because the work was completed later.

== RoundMaintenancePlan ==

=== Purpose ===

A RoundMaintenancePlan is used for recurring maintenance rounds.

It is a specialized type of cyclic maintenance plan. This means that it also uses RRULE and SCHEDULING_MODE.

In addition to the cyclic scheduling logic, a round maintenance plan includes child maintenance plans linked via SYSREL_ROUND_RELATION.

When the round maintenance plan is due, the system creates the main work package for the round. Then it creates additional work packages from the child maintenance plans linked via SYSREL_ROUND_RELATION.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Important for child plans:''' For the child plans, the system does not care whether they are due, active, auto-created, or whether they have a valid RRULE. The round maintenance plan uses the child plans as configuration for the additional work packages that should be created as part of the round.
</div>

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

=== Generated Result ===

Example:

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

Generated main work package:

* Machine Room Round

Additional generated work packages inside the main round work package:

* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection

The additional work packages are assigned to the main round work package. This allows the result of the round maintenance plan to be structured as one complete maintenance round.

== RoundMaintenancePlan Properties and Relations ==

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

=== SYSREL_ROUND_RELATION ===

SYSREL_ROUND_RELATION links the round maintenance plan to its child maintenance plans.

The linked child plans define which additional work packages should be generated when the round maintenance plan is due.

When the round plan generates work packages, the system creates:

* one main work package from the round plan’s own LK_WP_TMPL
* one additional work package for each child maintenance plan linked via SYSREL_ROUND_RELATION

The child maintenance plans do not need to be due themselves for the round maintenance plan to use them during round generation.

=== PLAN_SELECTION_RULE ===

PLAN_SELECTION_RULE exists on RoundMaintenancePlan.

<div style="border-left: 4px solid #f0ad4e; background-color: #fff8e5; padding: 10px 12px; margin: 12px 0;">
'''Open point:''' The exact runtime effect of PLAN_SELECTION_RULE should be documented after the implementation behavior has been verified. Until that behavior is confirmed, the wiki should not claim that PLAN_SELECTION_RULE filters child plans by due date, asset, or priority.
</div>

=== ORDERID and GROUPID ===

The relation between the round maintenance plan and a linked child maintenance plan can contain ORDERID and GROUPID.

When the system creates an additional work package from a linked child maintenance plan, these values can be copied to the generated work package.

This can be used to structure, order, or group the additional work packages in the generated round.

== Properties Calculated or Updated by the System ==

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

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.

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

This value is recalculated when:

* NEXT_DATE changes
* LEAD_DAYS changes
* NEXT_DATE is recalculated after planning or completion
* recurrence settings cause a new NEXT_DATE to be calculated

=== NEXT_DATE ===

For CyclicMaintenancePlan and RoundMaintenancePlan, NEXT_DATE can be calculated or recalculated by the system.

The calculation depends on:

* RRULE
* RRULE_START_DATE
* RRULE_UNTIL_DATE
* RRULE_COUNT
* SCHEDULING_MODE
* related generated work packages
* planning events
* completion events

For calendar-based scheduling, NEXT_DATE is calculated from the recurrence pattern and the highest relevant planned or finished date of related generated work packages.

For completion-based scheduling, NEXT_DATE is calculated from the completion date of the previous generated work package.

=== LAST_DATE ===

LAST_DATE is updated by the system when a generated work package is completed.

It stores the latest completion date of a generated work package related to the maintenance plan.

This value is especially relevant for completion-based scheduling.

=== PLANNED_START on Generated Work Packages ===

When the system generates a work package from a maintenance plan, it sets the generated work package’s PLANNED_START to the maintenance plan’s NEXT_DATE.

Example:

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

=== Links on Generated Work Packages ===

When the system generates a work package, it automatically sets the required links on the generated work package.

The generated work package is linked to:

* the source maintenance plan via LK_MAINTENANCE_PLAN
* the template work package via LK_WP_TMPL
* the assigned asset via LK_ASSET

For round maintenance plans, additional generated work packages from linked child maintenance plans are assigned to the main round work package via TASK_OWNER.

== Properties and Events That Trigger Recalculation ==

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

=== NEXT_DATE Changed ===

When NEXT_DATE changes, the system recalculates EARLIEST_GENERATION_DATE.

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

=== LEAD_DAYS Changed ===

When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.

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

=== RRULE Changed ===

When RRULE changes, the recurrence pattern changes.

The system recalculates NEXT_DATE based on the new recurrence rule and the selected SCHEDULING_MODE.

After NEXT_DATE is recalculated, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_START_DATE Changed ===

When RRULE_START_DATE changes, the start point of the recurrence changes.

The system recalculates the schedule. This can change NEXT_DATE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_UNTIL_DATE Changed ===

When RRULE_UNTIL_DATE changes, the end boundary of the recurrence changes.

The system checks whether future occurrences are still available.

If no further occurrence is possible because of RRULE_UNTIL_DATE, the system cannot calculate a new NEXT_DATE.

=== RRULE_COUNT Changed ===

When RRULE_COUNT changes, the system checks whether the maximum number of generated work packages has already been reached.

If the number of related generated work packages is greater than or equal to RRULE_COUNT, the system does not calculate further occurrences.

=== SCHEDULING_MODE Changed ===

When SCHEDULING_MODE changes, the logic for calculating future dates changes.

Changing to Calendar-Based means that the plan follows the calendar recurrence.

Changing to Completion-Based means that the plan calculates NEXT_DATE from the completion of the previous generated work package.

Because this changes the calculation logic, the system recalculates NEXT_DATE according to the selected SCHEDULING_MODE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== Generated Work Package PLANNED_START Changed ===

When PLANNED_START of a generated work package is set or changed, the work package notifies the linked maintenance plan.

For calendar-based cyclic maintenance plans, this can trigger recalculation of NEXT_DATE. The system uses the planning information to continue the calendar-based recurrence.

For completion-based cyclic maintenance plans, a PLANNED_START change does not drive the recurrence in the same way. NEXT_DATE is mainly calculated after the work package is completed.

=== Generated Work Package Completed ===

When a generated work package is completed, the work package notifies the linked maintenance plan.

A work package is considered completed when:

<pre>
ORGA_STATUS == 100
</pre>

The system updates LAST_DATE. Then the system recalculates NEXT_DATE according to SCHEDULING_MODE.

For calendar-based scheduling:

* the system continues according to the calendar recurrence
* NEXT_DATE is calculated from the recurrence pattern and relevant planned or finished dates

For completion-based scheduling:

* the completion date becomes the basis for the next occurrence
* NEXT_DATE is calculated from the completion date

After NEXT_DATE is updated, EARLIEST_GENERATION_DATE is recalculated.

== Work Package Generation Logic ==

=== When Is a Plan Ready to Create a Work Package? ===

A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled.

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

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

== Round Work Package Generation ==

A round maintenance plan creates a main work package for the round.

After the main work package has been created, the system processes the maintenance plans linked via SYSREL_ROUND_RELATION.

For each linked child maintenance plan, the system creates an additional work package.

These additional generated work packages are assigned to the main round work package via TASK_OWNER.

For child plans used in a round, the system does not care whether the child plan:

* has PLAN_STATUS == Active
* has AUTO_CREATE == true
* has a valid RRULE
* has a valid NEXT_DATE
* is due based on its own EARLIEST_GENERATION_DATE

<div style="border-left: 4px solid #36c; background-color: #f8f9fa; padding: 10px 12px; margin: 12px 0;">
'''Rule:''' The round plan controls the timing. The child plans define what additional work packages should be created as part of the round.
</div>

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

{{UnderConstructionEnd}}

MROMaintenancePlans

2026-06-15T05:47:20Z

LMA: /* See also */

MROMaintenancePlans

2026-06-15T05:46:42Z

LMA:

MROMaintenancePlans

2026-06-15T05:45:39Z

LMA:

MROMaintenancePlans

2026-06-07T12:47:18Z

LMA: 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..."

{{UnderConstructionStart}}
== MRO Maintenance Planning ==

The Maintenance Planning feature in MRO is used to plan recurring maintenance work and automatically generate work packages from maintenance plans.

A maintenance plan defines the rules for creating work packages. These rules include when a work package should be created, which asset it belongs to, which template work package should be used, how the template work package should be copied, how early before the planned execution date the work package may be generated, and how future planning dates are calculated.

The actual maintenance work is not executed by the maintenance plan itself. The maintenance plan creates work packages. These generated work packages are then used by users to execute and complete the actual maintenance work.

In MRO, MaintenancePlan is the abstract base class for maintenance planning. It provides the common foundation for maintenance plans, but it is not intended to be used directly because it is abstract.

The fully implemented maintenance plan types in standard MRO are:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Custom maintenance plan types can be implemented by deriving from the abstract MaintenancePlan base class. However, the standard MRO maintenance planning feature is based on cyclic maintenance plans and round maintenance plans.

CyclicMaintenancePlan and RoundMaintenancePlan support recurrence-based scheduling. This includes planned execution dates, automatic work package generation, calendar-based scheduling, completion-based scheduling, automatic recalculation of scheduling dates, and generation based on due dates.

RoundMaintenancePlan additionally supports maintenance rounds. A round maintenance plan creates one main work package for the round. It can also create additional work packages from child maintenance plans linked via SYSREL_ROUND_RELATION. These additional work packages are assigned to the main round work package.

== Basic concept ==

The maintenance planning feature is built around four main parts:

* the maintenance plan
* the template work package
* the replication configuration
* the generated work package

=== Maintenance plan ===

The maintenance plan defines the rules for creating work packages.

This includes, for example:

* when a work package should be created
* which asset the work package should belong to
* how many days before the planned execution date the work package may be created
* which template work package should be used
* which recurrence pattern should be used
* whether future dates are calculated calendar-based or completion-based

=== Template work package ===

The template work package defines what the generated work package should look like.

This means the template work package is the source work package that is copied when the maintenance plan creates a new work package.

Only work packages with ISTEMPLATE set can be used as template work packages.

=== Replication configuration ===

The replication configuration defines how the template work package is copied.

This includes, for example, which properties are copied, how referenced objects are handled, and what the target meta class of the generated work package should be.

=== Generated work package ===

The generated work package is the actual result created by the maintenance plan.

Example:

A pump has to be inspected every month.

A cyclic maintenance plan is created for this pump. The plan is configured with a monthly recurrence, an assigned asset, a template work package, and a replication configuration.

When the plan becomes due, the system uses a replication job to create a new work package from the configured template work package.

The generated work package is linked back to the maintenance plan via LK_MAINTENANCE_PLAN. This allows the maintenance plan to react when the generated work package is planned or completed.

== MaintenancePlan base class ==

=== Purpose ===

MaintenancePlan is the abstract base class for maintenance planning in MRO.

It provides the common properties and logic that are required by maintenance plan implementations.

Because MaintenancePlan is abstract, users do not create or use this base class directly in the standard MRO feature.

Instead, the concrete maintenance plan types are used:

* CyclicMaintenancePlan
* RoundMaintenancePlan

Developers can derive from the abstract base class if a project requires a custom maintenance plan type. In that case, the custom implementation must provide the missing plan-specific behavior.

=== LK_ASSET ===

LK_ASSET is the link to the asset that requires maintenance.

This can be, for example:

* equipment
* a functional location
* another customized maintainable object deriving from Asset

The generated work package is linked to the same asset.

A cyclic maintenance plan requires LK_ASSET to be assigned in order to be valid.

=== LK_WP_TMPL ===

LK_WP_TMPL is the link to the template work package.

The template work package defines what the generated work package should look like.

When the maintenance plan creates a work package, the system copies the work package referenced by LK_WP_TMPL.

The linked work package must be a template work package. This means its ISTEMPLATE property must be set.

If LK_WP_TMPL is not configured, the maintenance plan cannot create a work package.

=== LK_REPLICATION_CONFIG ===

LK_REPLICATION_CONFIG is the link to the replication configuration.

The replication configuration defines how the template work package is copied into a generated work package.

It can define, for example:

* which properties are copied
* how references are copied
* what the target meta class of the generated work package should be

If LK_REPLICATION_CONFIG is not configured, the maintenance plan cannot create a work package.

=== NEXT_DATE ===

NEXT_DATE defines the planned execution date of the next maintenance activity.

It answers the question: When should the next maintenance work be performed?

NEXT_DATE is not necessarily the date on which the work package is created.

Example:

NEXT_DATE: 15 March
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: 12 March

In this example, the system may create the work package on 12 March, but the generated work package is planned for 15 March.

When a work package is generated, the generated work package receives the maintenance plan’s NEXT_DATE as its PLANNED_START.

=== LEAD_DAYS ===

LEAD_DAYS defines how many days before NEXT_DATE the system may create the work package.

This is used to create work packages before the actual planned execution date.

Example:

NEXT_DATE: 15 March
LEAD_DAYS: 3

The system calculates:

EARLIEST_GENERATION_DATE: 12 March

This means that the work package can be created from 12 March onward.

LEAD_DAYS does not define the recurrence interval. It only defines how early the work package may be generated before the planned execution date.

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system.

It defines the earliest date on which the maintenance plan may create a work package.

The system calculates it like this:

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

Example:

NEXT_DATE: 15 March
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: 12 March

The maintenance planning orchestrator searches for active plans where EARLIEST_GENERATION_DATE has been reached.

A plan can be considered for automatic work package generation when:

EARLIEST_GENERATION_DATE <= current date

If EARLIEST_GENERATION_DATE has not yet been reached, no work package is created.

=== PLAN_STATUS ===

PLAN_STATUS defines whether the maintenance plan is active or inactive.

Only active plans are considered for automatic work package generation.

Inactive plans are ignored by the maintenance planning process.

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

Typical values are:

* Inactive
* Active

=== AUTO_CREATE ===

AUTO_CREATE defines whether the system is allowed to automatically create work packages from the maintenance plan.

If AUTO_CREATE is enabled, the maintenance planning orchestrator can create work packages once the plan is due.

If AUTO_CREATE is disabled, the plan does not automatically create work packages.

=== LAST_DATE ===

LAST_DATE stores the date when the most recent generated work package linked to the maintenance plan was completed.

This property is especially important for completion-based scheduling.

In completion-based scheduling, the completion date of the previous generated work package is used to calculate the next planned execution date.

Example:

Previous generated work package completed: 20 March
SCHEDULING_MODE: Completion-Based
Next date is calculated from: 20 March

The system updates LAST_DATE when a generated work package is completed.

=== PRIORITY ===

PRIORITY is a numeric value that can be used to sort maintenance plans.

For round maintenance plans, there is also a property called PLAN_SELECTION_RULE. The exact effect of this property should be documented only after the implementation behavior has been verified.

== Work package properties used by maintenance planning ==

=== LK_MAINTENANCE_PLAN ===

LK_MAINTENANCE_PLAN is set on generated work packages.

It stores the maintenance plan that triggered the creation of the work package.

This is important because the maintenance plan itself does not directly store a list of generated work packages. Instead, generated work packages reference their source maintenance plan via LK_MAINTENANCE_PLAN.

This link allows the system to find work packages created from a maintenance plan and to update the maintenance plan when a generated work package is planned or completed.

=== LK_WP_TMPL ===

On a generated work package, LK_WP_TMPL stores the template work package that was used to create the generated work package.

This allows users and the system to see which template was used as the source.

=== LK_ASSET ===

On a generated work package, LK_ASSET stores the asset for which the work package was created.

This is usually copied or assigned based on the maintenance plan’s LK_ASSET.

=== PLANNED_START ===

PLANNED_START stores the planned start date of the generated work package.

When a maintenance plan generates a work package, the system sets:

generated WorkPackage.PLANNED_START = MaintenancePlan.NEXT_DATE

=== ORGA_STATUS ===

ORGA_STATUS is used to determine whether a generated work package is finished.

A work package is considered finished when:

ORGA_STATUS == 100

Open work packages are generated work packages linked to the maintenance plan where ORGA_STATUS != 100.

A maintenance plan does not create another work package while it still has an open generated work package.

=== TASK_OWNER ===

TASK_OWNER is used in round maintenance scenarios.

When a round maintenance plan creates a main work package and additional work packages from linked child plans, the additional work packages are assigned to the main round work package via TASK_OWNER.

=== ORDERID and GROUPID ===

ORDERID and GROUPID can be copied from the SYSREL_ROUND_RELATION relation to generated work packages in a round maintenance scenario.

They can be used to order or group the additional work packages that belong to the generated round work package.

== CyclicMaintenancePlan ==

=== Purpose ===

A CyclicMaintenancePlan is used for recurring maintenance work on an asset.

It is the standard maintenance plan type for maintenance activities that repeat according to a defined recurrence pattern.

Examples:

* inspect a pump every month
* service a machine every 6 months
* check safety equipment every Monday
* replace a filter every 30 days
* perform annual maintenance on a functional location

A cyclic maintenance plan uses RRULE to define the recurrence. It also uses SCHEDULING_MODE to define how future dates are calculated.

SCHEDULING_MODE is important because it defines whether the plan follows fixed calendar dates or whether the next date depends on the actual completion date of the previous generated work package.

The supported scheduling modes are:

* Calendar-Based
* Completion-Based

== CyclicMaintenancePlan properties ==

=== RRULE ===

RRULE defines the recurrence pattern of a cyclic maintenance plan.

It describes how often the maintenance should occur.

Examples:

FREQ=DAILY

FREQ=WEEKLY;BYDAY=MO,WE,FR

FREQ=MONTHLY;BYMONTHDAY=15

The system uses RRULE to calculate future planned execution dates.

If RRULE is invalid and cannot be parsed, the cyclic maintenance plan is not valid and cannot create work packages.

=== RRULE_START_DATE ===

RRULE_START_DATE defines when the recurrence pattern starts.

The recurrence rule is calculated from this date forward.

Example:

RRULE_START_DATE: 01 January
RRULE: monthly on the 15th

The system uses these values to determine valid planned execution dates.

=== RRULE_UNTIL_DATE ===

RRULE_UNTIL_DATE is an optional end date for the recurrence.

If this date is configured, no further occurrences are generated after this date.

This can be used for maintenance plans that should only run until a certain date.

=== RRULE_COUNT ===

RRULE_COUNT limits how many work packages can be created from the plan.

Example:

RRULE_COUNT: 10

When the number of related generated work packages reaches RRULE_COUNT, the system no longer calculates new occurrences for the plan.

=== SCHEDULING_MODE ===

SCHEDULING_MODE defines how NEXT_DATE is calculated for a cyclic maintenance plan.

SCHEDULING_MODE is only relevant for concrete maintenance plan types that use recurrence logic, such as CyclicMaintenancePlan and RoundMaintenancePlan.

The supported scheduling modes are:

* Calendar-Based
* Completion-Based

This property is one of the most important settings because it defines whether future dates follow the calendar or depend on the actual completion of the previous generated work package.

== Calendar-based scheduling ==

=== Purpose ===

Calendar-based scheduling is used when maintenance should follow fixed calendar occurrences.

The next planned execution date is calculated according to RRULE and the calendar recurrence.

This means that delays in completing a work package do not automatically shift the whole future schedule.

Use calendar-based scheduling when the maintenance should happen on fixed dates or fixed calendar intervals.

Examples:

* inspection every 15th day of the month
* safety check every Monday
* yearly inspection every January
* quarterly maintenance in fixed maintenance windows

=== How calendar-based scheduling works ===

In calendar-based scheduling, the system calculates NEXT_DATE based on the recurrence rule and the relevant dates of existing generated work packages.

The system determines the highest relevant planned or finished date of generated work packages linked to the maintenance plan.

Then it uses the recurrence rule to calculate the next valid occurrence after that date.

This means the schedule continues according to the recurrence pattern.

If a work package is completed later than planned, the future schedule does not necessarily move with that completion date.

=== Example: calendar-based scheduling ===

A pump must be inspected on the 15th of every month.

Configuration:

Plan Type: CyclicMaintenancePlan
LK_ASSET: Pump 1
LK_WP_TMPL: Pump Inspection Template
LK_REPLICATION_CONFIG: Pump Inspection Replication
SCHEDULING_MODE: Calendar-Based
RRULE: monthly on the 15th
RRULE_START_DATE: 01 January
NEXT_DATE: 15 March
LEAD_DAYS: 3
PLAN_STATUS: Active
AUTO_CREATE: enabled

The system calculates:

EARLIEST_GENERATION_DATE: 12 March

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

Generated work package:

PLANNED_START: 15 March

After the work package is planned, the system can calculate the next occurrence.

NEXT_DATE: 15 April

If the March work package is completed on 20 March, the next date still follows the monthly recurrence.

The next planned execution date remains 15 April.

The late completion does not shift the future schedule to 20 April.

== Completion-based scheduling ==

=== Purpose ===

Completion-based scheduling is used when the next maintenance date should depend on the actual completion date of the previous generated work package.

This means that the interval starts after the work has actually been completed.

Use completion-based scheduling when the maintenance should repeat based on the time since the last completed maintenance activity.

Examples:

* service every 30 days after the last service
* inspection 6 months after the previous inspection was completed
* replacement 90 days after the previous replacement
* maintenance where a delay should also delay the next cycle

=== How completion-based scheduling works ===

In completion-based scheduling, the system recalculates NEXT_DATE after a generated work package is completed.

The completion date becomes the basis for the next occurrence.

Planning changes alone do not define the next recurrence in the same way as calendar-based scheduling.

The important point is:

The plan waits for the generated work package to be completed. Then the system calculates the next date from the completion date.

=== Example: completion-based scheduling ===

A machine must be serviced every 30 days after the previous service was completed.

Configuration:

Plan Type: CyclicMaintenancePlan
LK_ASSET: Machine 1
LK_WP_TMPL: Machine Service Template
LK_REPLICATION_CONFIG: Machine Service Replication
SCHEDULING_MODE: Completion-Based
RRULE: every 30 days
RRULE_START_DATE: 01 March
NEXT_DATE: 15 March
LEAD_DAYS: 3
PLAN_STATUS: Active
AUTO_CREATE: enabled

The system calculates:

EARLIEST_GENERATION_DATE: 12 March

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

Generated work package:

PLANNED_START: 15 March

The work package is completed on 20 March.

Because the plan is completion-based, the system calculates the next date from 20 March.

If the recurrence is every 30 days:

NEXT_DATE: around 19 April
LEAD_DAYS: 3
EARLIEST_GENERATION_DATE: around 16 April

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

== Difference between calendar-based and completion-based scheduling ==

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

Calendar-based scheduling follows the recurrence defined by RRULE.

Completion-based scheduling follows the actual completion of the previous generated work package.

=== Calendar-based ===

Calendar-based scheduling should be used when the maintenance must follow fixed planned dates.

Characteristics:

* The plan follows the RRULE calendar pattern.
* Future dates are not automatically shifted just because a work package was completed late.
* NEXT_DATE can be recalculated after planning updates.
* It is useful for fixed maintenance windows and legally or organizationally fixed inspection dates.

Example:

Planned inspection: 15 March
Completed: 20 March
Next date: 15 April

The future date stays aligned with the calendar recurrence.

=== Completion-based ===

Completion-based scheduling should be used when the next maintenance interval starts after the previous work was completed.

Characteristics:

* The plan waits for completion.
* The completion date is used as the basis for NEXT_DATE.
* If the work is completed late, the future schedule moves.
* It is useful for service intervals that depend on the actual last maintenance.

Example:

Planned service: 15 March
Completed: 20 March
Interval: 30 days
Next date: around 19 April

The future date shifts because the work was completed later.

== RoundMaintenancePlan ==

=== Purpose ===

A RoundMaintenancePlan is used for recurring maintenance rounds.

It is a specialized type of cyclic maintenance plan. This means that it also uses RRULE and SCHEDULING_MODE.

In addition to the cyclic scheduling logic, a round maintenance plan includes child maintenance plans linked via SYSREL_ROUND_RELATION.

When the round maintenance plan is due, the system creates the main work package for the round.

Then it creates additional work packages from the child maintenance plans linked via SYSREL_ROUND_RELATION.

For the child plans, the system does not care whether they are due, active, auto-created, or whether they have a valid RRULE. The round maintenance plan uses the child plans as configuration for the additional work packages that should be created as part of the round.

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

=== Generated result ===

Example:

Round Maintenance Plan: Machine Room Round

Linked child plans under SYSREL_ROUND_RELATION:

* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection

Generated main work package:

* Machine Room Round

Additional generated work packages inside the main round work package:

* Pump 1 Inspection
* Pump 2 Inspection
* Pump 3 Inspection

The additional work packages are assigned to the main round work package. This allows the result of the round maintenance plan to be structured as one complete maintenance round.

== RoundMaintenancePlan properties and relations ==

=== SYSREL_ROUND_RELATION ===

SYSREL_ROUND_RELATION links the round maintenance plan to its child maintenance plans.

The linked child plans define which additional work packages should be generated when the round maintenance plan is due.

When the round plan generates work packages, the system creates:

* one main work package from the round plan’s own LK_WP_TMPL
* one additional work package for each child maintenance plan linked via SYSREL_ROUND_RELATION

The child maintenance plans do not need to be due themselves for the round maintenance plan to use them during round generation.

=== PLAN_SELECTION_RULE ===

PLAN_SELECTION_RULE exists on RoundMaintenancePlan.

The exact runtime effect of this property should be documented after the implementation behavior has been verified.

Until that behavior is confirmed, the wiki should not claim that PLAN_SELECTION_RULE filters child plans by due date, asset, or priority.

=== ORDERID and GROUPID ===

The relation between the round maintenance plan and a linked child maintenance plan can contain ORDERID and GROUPID.

When the system creates an additional work package from a linked child maintenance plan, these values can be copied to the generated work package.

This can be used to structure, order, or group the additional work packages in the generated round.

== Properties calculated or updated by the system ==

=== EARLIEST_GENERATION_DATE ===

EARLIEST_GENERATION_DATE is calculated by the system from NEXT_DATE and LEAD_DAYS.

Formula:

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

This value is recalculated when:

* NEXT_DATE changes
* LEAD_DAYS changes
* NEXT_DATE is recalculated after planning or completion
* recurrence settings cause a new NEXT_DATE to be calculated

=== NEXT_DATE ===

For CyclicMaintenancePlan and RoundMaintenancePlan, NEXT_DATE can be calculated or recalculated by the system.

The calculation depends on:

* RRULE
* RRULE_START_DATE
* RRULE_UNTIL_DATE
* RRULE_COUNT
* SCHEDULING_MODE
* related generated work packages
* planning events
* completion events

For calendar-based scheduling, NEXT_DATE is calculated from the recurrence pattern and the highest relevant planned or finished date of related generated work packages.

For completion-based scheduling, NEXT_DATE is calculated from the completion date of the previous generated work package.

=== LAST_DATE ===

LAST_DATE is updated by the system when a generated work package is completed.

It stores the latest completion date of a generated work package related to the maintenance plan.

This value is especially relevant for completion-based scheduling.

=== PLANNED_START on generated work packages ===

When the system generates a work package from a maintenance plan, it sets the generated work package’s PLANNED_START to the maintenance plan’s NEXT_DATE.

Example:

MaintenancePlan.NEXT_DATE: 15 March
Generated WorkPackage.PLANNED_START: 15 March

=== Links on generated work packages ===

When the system generates a work package, it automatically sets the required links on the generated work package.

The generated work package is linked to:

* the source maintenance plan via LK_MAINTENANCE_PLAN
* the template work package via LK_WP_TMPL
* the assigned asset via LK_ASSET

For round maintenance plans, additional generated work packages from linked child maintenance plans are assigned to the main round work package via TASK_OWNER.

== Properties and events that trigger recalculation ==

=== NEXT_DATE changed ===

When NEXT_DATE changes, the system recalculates EARLIEST_GENERATION_DATE.

Formula:

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

=== LEAD_DAYS changed ===

When LEAD_DAYS changes, the system recalculates EARLIEST_GENERATION_DATE.

Formula:

EARLIEST_GENERATION_DATE = NEXT_DATE - LEAD_DAYS

=== RRULE changed ===

When RRULE changes, the recurrence pattern changes.

The system recalculates NEXT_DATE based on the new recurrence rule and the selected SCHEDULING_MODE.

After NEXT_DATE is recalculated, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_START_DATE changed ===

When RRULE_START_DATE changes, the start point of the recurrence changes.

The system recalculates the schedule.

This can change NEXT_DATE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== RRULE_UNTIL_DATE changed ===

When RRULE_UNTIL_DATE changes, the end boundary of the recurrence changes.

The system checks whether future occurrences are still available.

If no further occurrence is possible because of RRULE_UNTIL_DATE, the system cannot calculate a new NEXT_DATE.

=== RRULE_COUNT changed ===

When RRULE_COUNT changes, the system checks whether the maximum number of generated work packages has already been reached.

If the number of related generated work packages is greater than or equal to RRULE_COUNT, the system does not calculate further occurrences.

=== SCHEDULING_MODE changed ===

When SCHEDULING_MODE changes, the logic for calculating future dates changes.

Changing to Calendar-Based means that the plan follows the calendar recurrence.

Changing to Completion-Based means that the plan calculates NEXT_DATE from the completion of the previous generated work package.

Because this changes the calculation logic, the system recalculates NEXT_DATE according to the selected SCHEDULING_MODE.

If NEXT_DATE changes, EARLIEST_GENERATION_DATE is recalculated as well.

=== Generated work package PLANNED_START changed ===

When PLANNED_START of a generated work package is set or changed, the work package notifies the linked maintenance plan.

For calendar-based cyclic maintenance plans, this can trigger recalculation of NEXT_DATE.

The system uses the planning information to continue the calendar-based recurrence.

For completion-based cyclic maintenance plans, a PLANNED_START change does not drive the recurrence in the same way. NEXT_DATE is mainly calculated after the work package is completed.

=== Generated work package completed ===

When a generated work package is completed, the work package notifies the linked maintenance plan.

A work package is considered completed when:

ORGA_STATUS == 100

The system updates LAST_DATE.

Then the system recalculates NEXT_DATE according to SCHEDULING_MODE.

For calendar-based scheduling:

* the system continues according to the calendar recurrence
* NEXT_DATE is calculated from the recurrence pattern and relevant planned or finished dates

For completion-based scheduling:

* the completion date becomes the basis for the next occurrence
* NEXT_DATE is calculated from the completion date

After NEXT_DATE is updated, EARLIEST_GENERATION_DATE is recalculated.

== Work package generation logic ==

=== When is a plan ready to create a work package? ===

A cyclic or round maintenance plan can create a work package only if all required conditions are fulfilled.

The plan must be valid.

For cyclic maintenance plans, this means:

* RRULE is valid
* LK_ASSET is assigned
* NEXT_DATE is available

The plan must be active:

PLAN_STATUS == Active

AUTO_CREATE must be enabled.

A template work package must be assigned:

LK_WP_TMPL must be set.

A replication configuration must be assigned:

LK_REPLICATION_CONFIG must be set.

The earliest generation date must be reached:

EARLIEST_GENERATION_DATE <= current date

There must be no open work package for the plan.

This means there must be no generated work package linked via LK_MAINTENANCE_PLAN where ORGA_STATUS != 100.

This prevents the system from creating multiple open work packages for the same maintenance plan.

== Round work package generation ==

A round maintenance plan creates a main work package for the round.

After the main work package has been created, the system processes the maintenance plans linked via SYSREL_ROUND_RELATION.

For each linked child maintenance plan, the system creates an additional work package.

These additional generated work packages are assigned to the main round work package via TASK_OWNER.

For child plans used in a round, the system does not care whether the child plan:

* has PLAN_STATUS == Active
* has AUTO_CREATE == true
* has a valid RRULE
* has a valid NEXT_DATE
* is due based on its own EARLIEST_GENERATION_DATE

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

{{UnderConstructionEnd}}

MRO Implemented Objects

2026-05-26T07:20:11Z

LMA: /* Pick List Task */

MRO Implemented Objects are pre-configured standard MRO objects enhanced with additional logic and features. For most tasks, value properties are pre-set, and many of them also implement additional MRO-relevant classifications.

== Workpackage ==

=== Procedure Workpackage ===
MetaClass Name: PROCEDURE_WORKPACKAGE | MetaClass UID: 007c78f8-fafd-4bde-8add-e11990625e7a

A Procedure Workpackage serves as a container for tasks and other procedures. It stores its entire structure in a JSON format, which is predefined using a workflow editor. When a specific state is triggered, the corresponding sub-tasks and procedures are created or updated accordingly.

Extra Classifications: [[MROCLS_PROCEDURE]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| PROCEDURE_STATUS || {{Integer}} || Represents the current state: Draft = 10, ReadyToUse = 20, Published = 30, Open = 40, Executing = 50, Completed = 60, Approved = 70, Rejected = 80
|-
| JSON || {{String}} || JSON representation of the procedure
|-
| ISTEMPLATE || {{Boolean}} || Indicates whether the procedure is a template
|}

== Task ==

=== Switch Start Task ===
MetaClass Name: SWITCH_START_TASK | MetaClass UID: 3c3614e2-635f-4e07-b02a-a72c81b9e328

A Switch Start Task confirms task completion by the system after an expression calculation. The task is automatically marked as complete once the calculation finishes successfully. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_START_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state: Undefined = 0, Ongoing = 10, Finished = 20, Error = 30
|-
| BRANCH_TRUE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as true
|-
| BRANCH_FALSE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as false
|-
| DISPLAYSTRING_TRUE || {{String}} || DisplayString for the case the expression is evaluated as true
|-
| DISPLAYSTRING_FALSE || {{String}} || DisplayString for the case the expression is evaluated as false
|-
| VALUE || {{Boolean}} || Result of the evaluated expression
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Switch End Task ===
MetaClass Name: SWITCH_END_TASK | MetaClass UID: 261a3e63-2b8e-4f3e-ab22-295bbe421e7a

A Switch End Task confirms task completion by the system. The task is invisible to the user and is always automatically marked as complete. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_END_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LK_SWITCH_START_TASK || {{Guid}} || Link to Switch task
|}

=== Check Task ===
MetaClass Name: CHECK_TASK | Metaclass UID: A360287D-2979-4D91-8B1A-6086FC1BEDA1 
MetaClass Name: CUSTOM_CHECK_TASK | Metaclass UID: DF61A1DB-5238-4A87-85A6-B9C09B54B242

A Check Task confirms task completion. The task is complete once a value is selected (including Not Applicable). 

Extra Classifications: [[MROCLS_MRO_CHECK_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Numeric Task ===
MetaClass Name: NUMERIC_TASK | MetaClass UID: b1789da3-bd67-4f93-b14b-22fd41afb215 
MetaClass Name: CUSTOM_NUMERIC_TASK | MetaClass UID: 047d05f3-a876-4f9d-a40e-2a098e9ba49b

A Numeric Task records a numeric double value (e.g., from a temperature sensor). Once a value is entered (including Not Applicable), the task is considered complete.
An acceptability range and measurement unit can be defined. If the value falls outside the acceptable range, a red alert and/or a technical status update can be triggered.
The behaviour of the previous value indicator must be defined separately.

Extra Classifications: [[MROCLS_MRO_NUMERIC_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Double}} || Recorded double numeric value
|-
| VALUE_UNIT || {{String}} || Measurment unit
|}

=== Inspection Task ===
MetaClass Name: INSPECTION_TASK | MetaClass UID: 08571b05-a093-479a-a10a-9d03c435b1b5 
MetaClass Name: CUSTOM_INSPECTION_TASK | MetaClass UID: a0123b54-ddcf-49be-8c66-7ca86c4c5277

An Inspection Task captures a binary decision. Once a value is selected (including Not Applicable), the task is complete. 
Custom labels can override the default icons: Checkmark (✔) and Cross (✘).
Label behavior must be defined separately in the customization settings.

Extra Classifications: [[MROCLS_MRO_INSPECTION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LABEL_FALSE || {{String}} || Label for negative outcome
|-
| LABEL_TRUE || {{String}} || Label for positive outcome
|}

=== Text Task ===
MetaClass Name: TEXT_TASK | MetaClass UID: 7298d038-003a-41d5-bc24-c97018ca7e85 
MetaClass Name: CUSTOM_TEXT_TASK | MetaClass UID: c0a95da8-8e32-4036-8db4-ef438deb14de

A Text Task allows entry of free-form text. Once a value is entered (including Not Applicable), the task is complete.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{String}} || Entered text
|}

=== Picture Task ===
MetaClass Name: PICTURE_TASK | MetaClass UID: bee0b281-7da1-470e-9838-46724d47b621 
MetaClass Name: CUSTOM_PICTURE_TASK | MetaClass UID: e58c6957-ecb2-4e3f-a4b7-6953b917d7d4

A Picture Task confirms whether a photo has been taken. The task is only complete once a value is entered (including Not Applicable). 
A button must be available to add a photo as a child object. Task confirmation is blocked unless at least one photo is attached.
The behavior for photo addition and confirmation blocking must be defined in customization.

Extra Classifications: [[MROCLS_PICTURE_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Pick List Task ===
MetaClass Name: PICKLIST_TASK | MetaClass UID: 78651014-f41e-4254-987f-6cf55c687d35 
MetaClass Name: CUSTOM_PICKLIST_TASK | MetaClass UID: 83551c77-554e-4715-b327-16f0a6ee196a

A Pick List Task allows the user to select one value from a list of available items. It looks and behaves similarly to a standard Integer Task with a Selective List, but its selectable values are provided by an [[UBIK_Active_Lists|Active List]] defined on instance level.

Once a list item is selected, the task is considered complete. Alternatively, the task can be completed by selecting Not Applicable, if this option is available.

Pick List Tasks are intended for MRO workflows where the available options depend on the concrete task instance or workflow context instead of being defined globally.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Integer}} || Selected list item value
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Supervisor Check Task ===
MetaClass Name: SUPERVISOR_CHECK_TASK | MetaClass UID: 76910d64-5bc0-4674-9c43-108959119846 
MetaClass Name: CUSTOM_SUPERVISOR_CHECK_TASK | MetaClass UID: 1e4a5506-0c6f-4447-bd0a-d5c87282a0e9

A Supervisor Check Task confirms task completion by a supervisor. The task is complete once a value is selected. 
Confirmation is only possible after NFC recognition of the supervisor and PIN entry.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| SUPERVISOR || {{Guid}} || Supervisor
|-
| PERMISSION || {{String}} || Supervisor permissions
|}

=== Interface Task ===
MetaClass Name: INTERFACE_TASK | MetaClass UID: d9a80e3d-02f6-4f0c-b243-7ece9ad82849 
MetaClass Name: CUSTOM_INTERFACE_TASK | MetaClass UID: e437ef02-d49b-4f23-9ab8-9a9836366c3d

Currently under development.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Calculation Task ===
MetaClass Name: CALCULATION_TASK | Metaclass UID: 3ec9d0f2-9d0f-4c1b-80bd-1efeaf010fa0 
MetaClass Name: CUSTOM_CALCULATION_TASK | Metaclass UID: e2b24a28-2382-46d2-8f4b-5f52168a9e27

Currently under development.

Extra Classifications: [[MROCLS_CALCULATION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state (Undefined = 0, Pending = 10, Finished = 20, Error = 30)
|-
| TARGET_PROPERTY_NAME || {{String}} || Name of Target Property (on owner)
|-
| TARGET_PROPERTY_TYPE || {{Integer}} || Type of Target Property (Undefined = 0, Bool = 1, Int = 3, Double = 4)
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Signature Task ===
MetaClass Name: SIGNATURE_TASK | Metaclass UID: 66D6A529-E233-4CE2-9E11-B65984D5B0DA 
MetaClass Name: CUSTOM_SIGNATURE_TASK | Metaclass UID: ECE1E20F-2BA3-4BC4-A0DD-9AFFDBB23790

A Signature Task captures a sign-off action to confirm the completion of a procedure. The task is complete once a written signature is provided. 

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Signature}} || Signature
|}

== Procedure Tasks ==
The following tasks are specialized versions intended for use within procedures. They implement both the [[MROCLS_SEQUENTIALTASK]] and [[MROCLS_GROUPEDTASK]] classifications.

MetaClass Name: PROCEDURE_CHECK_TASK | MetaClass UID: 63D68EA4-E78C-4A33-A35A-301A01A2568E 
MetaClass Name: PROCEDURE_NUMERIC_TASK | MetaClass UID: f578f50b-eecd-4734-929b-43e1f1f246fa 
MetaClass Name: PROCEDURE_INSPECTION_TASK | MetaClass UID: 9369b841-c5bf-43df-909f-3a5063763f81 
MetaClass Name: PROCEDURE_TEXT_TASK | MetaClass UID: 4dd8fee2-9d3e-4fa1-9a61-d580f5d4201c 
MetaClass Name: PROCEDURE_PICTURE_TASK | MetaClass UID: 4c0db9da-dfcc-48ad-9d89-6c958a5ac39f 
MetaClass Name: PROCEDURE_SUPERVISOR_CHECK_TASK | MetaClass UID: 9bb8e1b1-04f8-46f0-a9c9-0bb2960a49e5 
MetaClass Name: PROCEDURE_INTERFACE_TASK | MetaClass UID: 8d9ff119-510b-425c-b917-f72783e4570c 
MetaClass Name: PROCEDURE_CALCULATION_TASK | Metaclass UID: ed31735c-c807-40e9-b9a4-254e77445dd5 
MetaClass Name: PROCEDURE_SIGNATURE_TASK | Metaclass UID: 202CDB9D-BEEB-4E5A-A333-5235A9E6FF94 
MetaClass Name: PROCEDURE_PICK_LIST_TASK | MetaClass UID: 241a2248-36f6-44ab-9c8d-0357b7cbe24c 

[[Category:Plugin|MRO Implemented Objects]]

== File Documents ==

=== JSON File Document ===
MetaClass Name: FILEDOCUMENT_MRO_JSON | MetaClass UID: 016e57d5-37b3-42e0-a753-f675d4cbf338

File Document for JSON file of a Procedure Workpackage.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PROCEDURE_WORKPACKAGE || {{Guid}} ||
|}

=== Picture Task File document ===
MetaClass Name: FILEDOCUMENT_MRO_PICTURE_TASK | MetaClass UID: 2488fd79-4729-4090-9587-82103a9869e0

File Document for image files of a Picture Task.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PICTURE_TASK || {{Guid}} ||
|}

== See also ==
* [[MRO_(Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MROCLS_MRO_TASK#Task]] (Classification)
* [[MROCLS_SEQUENTIALTASK]] (Classification)
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)
* [[MROCLS_PICK_LIST_TASK]] (Classification)

[[Category:Plugin|MRO Implemented Objects]]

MRO Implemented Objects

2026-05-26T07:19:40Z

LMA: /* See also */

MRO Implemented Objects are pre-configured standard MRO objects enhanced with additional logic and features. For most tasks, value properties are pre-set, and many of them also implement additional MRO-relevant classifications.

== Workpackage ==

=== Procedure Workpackage ===
MetaClass Name: PROCEDURE_WORKPACKAGE | MetaClass UID: 007c78f8-fafd-4bde-8add-e11990625e7a

A Procedure Workpackage serves as a container for tasks and other procedures. It stores its entire structure in a JSON format, which is predefined using a workflow editor. When a specific state is triggered, the corresponding sub-tasks and procedures are created or updated accordingly.

Extra Classifications: [[MROCLS_PROCEDURE]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| PROCEDURE_STATUS || {{Integer}} || Represents the current state: Draft = 10, ReadyToUse = 20, Published = 30, Open = 40, Executing = 50, Completed = 60, Approved = 70, Rejected = 80
|-
| JSON || {{String}} || JSON representation of the procedure
|-
| ISTEMPLATE || {{Boolean}} || Indicates whether the procedure is a template
|}

== Task ==

=== Switch Start Task ===
MetaClass Name: SWITCH_START_TASK | MetaClass UID: 3c3614e2-635f-4e07-b02a-a72c81b9e328

A Switch Start Task confirms task completion by the system after an expression calculation. The task is automatically marked as complete once the calculation finishes successfully. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_START_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state: Undefined = 0, Ongoing = 10, Finished = 20, Error = 30
|-
| BRANCH_TRUE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as true
|-
| BRANCH_FALSE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as false
|-
| DISPLAYSTRING_TRUE || {{String}} || DisplayString for the case the expression is evaluated as true
|-
| DISPLAYSTRING_FALSE || {{String}} || DisplayString for the case the expression is evaluated as false
|-
| VALUE || {{Boolean}} || Result of the evaluated expression
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Switch End Task ===
MetaClass Name: SWITCH_END_TASK | MetaClass UID: 261a3e63-2b8e-4f3e-ab22-295bbe421e7a

A Switch End Task confirms task completion by the system. The task is invisible to the user and is always automatically marked as complete. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_END_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LK_SWITCH_START_TASK || {{Guid}} || Link to Switch task
|}

=== Check Task ===
MetaClass Name: CHECK_TASK | Metaclass UID: A360287D-2979-4D91-8B1A-6086FC1BEDA1 
MetaClass Name: CUSTOM_CHECK_TASK | Metaclass UID: DF61A1DB-5238-4A87-85A6-B9C09B54B242

A Check Task confirms task completion. The task is complete once a value is selected (including Not Applicable). 

Extra Classifications: [[MROCLS_MRO_CHECK_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Numeric Task ===
MetaClass Name: NUMERIC_TASK | MetaClass UID: b1789da3-bd67-4f93-b14b-22fd41afb215 
MetaClass Name: CUSTOM_NUMERIC_TASK | MetaClass UID: 047d05f3-a876-4f9d-a40e-2a098e9ba49b

A Numeric Task records a numeric double value (e.g., from a temperature sensor). Once a value is entered (including Not Applicable), the task is considered complete.
An acceptability range and measurement unit can be defined. If the value falls outside the acceptable range, a red alert and/or a technical status update can be triggered.
The behaviour of the previous value indicator must be defined separately.

Extra Classifications: [[MROCLS_MRO_NUMERIC_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Double}} || Recorded double numeric value
|-
| VALUE_UNIT || {{String}} || Measurment unit
|}

=== Inspection Task ===
MetaClass Name: INSPECTION_TASK | MetaClass UID: 08571b05-a093-479a-a10a-9d03c435b1b5 
MetaClass Name: CUSTOM_INSPECTION_TASK | MetaClass UID: a0123b54-ddcf-49be-8c66-7ca86c4c5277

An Inspection Task captures a binary decision. Once a value is selected (including Not Applicable), the task is complete. 
Custom labels can override the default icons: Checkmark (✔) and Cross (✘).
Label behavior must be defined separately in the customization settings.

Extra Classifications: [[MROCLS_MRO_INSPECTION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LABEL_FALSE || {{String}} || Label for negative outcome
|-
| LABEL_TRUE || {{String}} || Label for positive outcome
|}

=== Text Task ===
MetaClass Name: TEXT_TASK | MetaClass UID: 7298d038-003a-41d5-bc24-c97018ca7e85 
MetaClass Name: CUSTOM_TEXT_TASK | MetaClass UID: c0a95da8-8e32-4036-8db4-ef438deb14de

A Text Task allows entry of free-form text. Once a value is entered (including Not Applicable), the task is complete.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{String}} || Entered text
|}

=== Picture Task ===
MetaClass Name: PICTURE_TASK | MetaClass UID: bee0b281-7da1-470e-9838-46724d47b621 
MetaClass Name: CUSTOM_PICTURE_TASK | MetaClass UID: e58c6957-ecb2-4e3f-a4b7-6953b917d7d4

A Picture Task confirms whether a photo has been taken. The task is only complete once a value is entered (including Not Applicable). 
A button must be available to add a photo as a child object. Task confirmation is blocked unless at least one photo is attached.
The behavior for photo addition and confirmation blocking must be defined in customization.

Extra Classifications: [[MROCLS_PICTURE_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Pick List Task ===
MetaClass Name: PICKLIST_TASK | MetaClass UID: 78651014-f41e-4254-987f-6cf55c687d35 
MetaClass Name: CUSTOM_PICKLIST_TASK | MetaClass UID: 83551c77-554e-4715-b327-16f0a6ee196a

A Pick List Task allows the user to select one value from a list of available items. It looks and behaves similarly to a standard Integer Task with a Selective List, but its selectable values are provided by an Active List defined on instance level.

Once a list item is selected, the task is considered complete. Alternatively, the task can be completed by selecting Not Applicable, if this option is available.

Pick List Tasks are intended for MRO workflows where the available options depend on the concrete task instance or workflow context instead of being defined globally.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Integer}} || Selected list item value
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Supervisor Check Task ===
MetaClass Name: SUPERVISOR_CHECK_TASK | MetaClass UID: 76910d64-5bc0-4674-9c43-108959119846 
MetaClass Name: CUSTOM_SUPERVISOR_CHECK_TASK | MetaClass UID: 1e4a5506-0c6f-4447-bd0a-d5c87282a0e9

A Supervisor Check Task confirms task completion by a supervisor. The task is complete once a value is selected. 
Confirmation is only possible after NFC recognition of the supervisor and PIN entry.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| SUPERVISOR || {{Guid}} || Supervisor
|-
| PERMISSION || {{String}} || Supervisor permissions
|}

=== Interface Task ===
MetaClass Name: INTERFACE_TASK | MetaClass UID: d9a80e3d-02f6-4f0c-b243-7ece9ad82849 
MetaClass Name: CUSTOM_INTERFACE_TASK | MetaClass UID: e437ef02-d49b-4f23-9ab8-9a9836366c3d

Currently under development.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Calculation Task ===
MetaClass Name: CALCULATION_TASK | Metaclass UID: 3ec9d0f2-9d0f-4c1b-80bd-1efeaf010fa0 
MetaClass Name: CUSTOM_CALCULATION_TASK | Metaclass UID: e2b24a28-2382-46d2-8f4b-5f52168a9e27

Currently under development.

Extra Classifications: [[MROCLS_CALCULATION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state (Undefined = 0, Pending = 10, Finished = 20, Error = 30)
|-
| TARGET_PROPERTY_NAME || {{String}} || Name of Target Property (on owner)
|-
| TARGET_PROPERTY_TYPE || {{Integer}} || Type of Target Property (Undefined = 0, Bool = 1, Int = 3, Double = 4)
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Signature Task ===
MetaClass Name: SIGNATURE_TASK | Metaclass UID: 66D6A529-E233-4CE2-9E11-B65984D5B0DA 
MetaClass Name: CUSTOM_SIGNATURE_TASK | Metaclass UID: ECE1E20F-2BA3-4BC4-A0DD-9AFFDBB23790

A Signature Task captures a sign-off action to confirm the completion of a procedure. The task is complete once a written signature is provided. 

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Signature}} || Signature
|}

== Procedure Tasks ==
The following tasks are specialized versions intended for use within procedures. They implement both the [[MROCLS_SEQUENTIALTASK]] and [[MROCLS_GROUPEDTASK]] classifications.

MetaClass Name: PROCEDURE_CHECK_TASK | MetaClass UID: 63D68EA4-E78C-4A33-A35A-301A01A2568E 
MetaClass Name: PROCEDURE_NUMERIC_TASK | MetaClass UID: f578f50b-eecd-4734-929b-43e1f1f246fa 
MetaClass Name: PROCEDURE_INSPECTION_TASK | MetaClass UID: 9369b841-c5bf-43df-909f-3a5063763f81 
MetaClass Name: PROCEDURE_TEXT_TASK | MetaClass UID: 4dd8fee2-9d3e-4fa1-9a61-d580f5d4201c 
MetaClass Name: PROCEDURE_PICTURE_TASK | MetaClass UID: 4c0db9da-dfcc-48ad-9d89-6c958a5ac39f 
MetaClass Name: PROCEDURE_SUPERVISOR_CHECK_TASK | MetaClass UID: 9bb8e1b1-04f8-46f0-a9c9-0bb2960a49e5 
MetaClass Name: PROCEDURE_INTERFACE_TASK | MetaClass UID: 8d9ff119-510b-425c-b917-f72783e4570c 
MetaClass Name: PROCEDURE_CALCULATION_TASK | Metaclass UID: ed31735c-c807-40e9-b9a4-254e77445dd5 
MetaClass Name: PROCEDURE_SIGNATURE_TASK | Metaclass UID: 202CDB9D-BEEB-4E5A-A333-5235A9E6FF94 
MetaClass Name: PROCEDURE_PICK_LIST_TASK | MetaClass UID: 241a2248-36f6-44ab-9c8d-0357b7cbe24c 

[[Category:Plugin|MRO Implemented Objects]]

== File Documents ==

=== JSON File Document ===
MetaClass Name: FILEDOCUMENT_MRO_JSON | MetaClass UID: 016e57d5-37b3-42e0-a753-f675d4cbf338

File Document for JSON file of a Procedure Workpackage.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PROCEDURE_WORKPACKAGE || {{Guid}} ||
|}

=== Picture Task File document ===
MetaClass Name: FILEDOCUMENT_MRO_PICTURE_TASK | MetaClass UID: 2488fd79-4729-4090-9587-82103a9869e0

File Document for image files of a Picture Task.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PICTURE_TASK || {{Guid}} ||
|}

== See also ==
* [[MRO_(Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MROCLS_MRO_TASK#Task]] (Classification)
* [[MROCLS_SEQUENTIALTASK]] (Classification)
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)
* [[MROCLS_PICK_LIST_TASK]] (Classification)

[[Category:Plugin|MRO Implemented Objects]]

MRO Objects (Client)

2026-05-26T07:19:30Z

LMA: /* See also */

[[File:MRO_WinX.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
[[File:MRO_MAUI1.jpeg|thumb|alt=MRO Child List UI (Android)|MRO UI (Android)]]
The WinX client UI displays MRO configured objects like any other root- or child-object enriched by some additional logic and features.

== Basic User Interface ==
The representation of MRO features comprises some indicators and interactive controls. In the {{UBIK}} child list, the main object displays cumulated technical and organisational status as well as the overall work progress based on the underlying data branch. Objects classified as MRO objects in general provide indicators for the MRO status. This means the status is shown next to the main icon of a child-/details-/documents-page as well as next to the icons of the child list items:

=== Technical Status ===

The technical status indicator is shown on all objects that represent a technical state or receive the technical status from subsequent objects in the underlying data branch. If e.g. a inventory object is reported as damaged, its parent objects will all display the exclamation mark symbol to indicate that a problem was reported in the child items.

[[File:TechStats_WinX.png|100px|Technical Status Indicator (Winx & Mobile)]]

=== Organisational Status ===
The organisational status indicates the amount of confirmed work within the data branch, including already confirmed work packages as well as tasks that are locked by their owning work package. The organisational status indicator is displayed on all objects that represent an organisational state or receive the organisational status from subsequent objects in the underlying data branch, and visualizes the amount of confirmed work performed within that branch.
<gallery>
File:OrgaStatusIndicatorWinX.PNG|Organisational Status Indicator (WinX)
File:ConfirmedWP_WinX.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
File:ConfirmedWP_MAUI.jpeg|MRO Workpackage Confirmed Indicator (Mobile)
</gallery>

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

=== Work Progress ===
The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.

{{Version/WinXSince|5.0}} {{Version/MobileSince|5.0}} By default, the progress is displayed with maximum one decimal place. For example, 99.75% is displayed as 99.8%. The format string used to achieve this is <code>{0:0.#}%</code>.

If other numeric formats are preferred in your usecases, you can refer to [https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings custom numeric format strings] for more information. The template to customize for this is the UBIKMROProgressBadge within UBIKThemes.

{{Clear}}

== MRO Objects ==
A set of specific objects can be used to provide the required structure for MRO:

=== Task Owner ===
A [[MROCLS_MRO_TASKOWNER|Task Owner]] is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.

=== Work Package===
A [[MROCLS_MRO_WORKPACKAGE|Work Package]] is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed. Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.

<gallery>
File:ConfirmingWP_WinX.png|MRO Workpackage confirm button (WinX)
File:MRORevoke_WinX.png|MRO Workpackage revoke confirmation button (WinX)
File:ConfirmingWP_MAUI.jpeg|MRO Workpackage confirm button (Android)
File:MRORevoke_MAUI.jpeg|MRO Workpackage revoke confirmation button (Android)
</gallery>

=== Task ===
A [[MROCLS_MRO_TASK|Task]] is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called '''VALUE''' in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.

On both clients, a Task can be reverted by clicking twice on the Not Applicable button.

{{Attention|The MetaProperty ''VALUE'' has to use [[Attributes]] in order to be validated. Otherwise, the calculation of work progress will not be possible.}}

==== Measurement Task ====

A [[MROCLS_MRO_MEASUREMENT_TASK|Measurement Task]] inherits from [[MROCLS_MRO_TASK|Task]] and documents a measured value (e.g. read from a pressure gauge). Therefore, clicking the value on the shown task opens an editor to enter the desired value. If no value was entered before, an empty line will be shown. Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option ''Not Applicable'' to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken). An additional small value indicator below the main value can report e.g. the previously entered value. The behaviour of this previous value indicator has to be specified separately in the customizing.
{{Clear}}

<gallery widths=497px heights=69px>
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
</gallery>

==== Progress Task ====

[[MROCLS_MRO_PROGRESS_TASK| Progress Task]] inherits from [[MROCLS_MRO_MEASUREMENT_TASK|Task]] and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option ''Not Applicable''.

There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
{{Clear}}

<gallery widths=497px heights=69px>
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
</gallery>

==== Check Task ====

A [[MROCLS_MRO_CHECK_TASK|Check Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished by reporting ''Done'' or ''Not Applicable''. This is intended for a simple To-Do task that is either done or not.
{{Clear}}

<gallery widths=497px heights=69px>
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
</gallery>

==== Inspection Task ====

[[MROCLS_MRO_INSPECTION_TASK|Inspection Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished, when the user reports with a positive or negative answer or ''Not Applicable'' (e.g. reporting a yes/no answer for existing equipment).
{{Clear}}

<gallery widths=497px heights=69px>
File:Finished Inspection Task UWP.png|Finished MRO InspectionTask (WinX)
File:Inspection task android.jpg|Finished MRO InspectionTask (Android)
</gallery>

==== Sequential Task ====
The [[MROCLS_SEQUENTIALTASK|sequential task classification]] allows you to pre-define a sequence in which tasks are to be resolved by users. This means that it is required for one or multiple tasks to be finished in order for other tasks to become "unlocked" and editable. A task can have any number of "predecessors". Predecessors are the tasks that are required to be finished first.

A task can have predecessors that live anywhere else in the object hierarchy. It is not necessary for a task and its predecessors to be part of the same work package, even though this is likely the most common use case.

The state of a sequential task is evaluated both offline and online to get the best possible user experience. The user will see dependent tasks update immediately if their successors were finished, if those tasks are currently visible in the UI. There is 1 case in which the server-side state will override the client-side (offline) evaluation, discussed below.
The state of each sequential task is evaluated the following way:

# If the server-side state says the task is open, we consider this as the truthful state and don't do any other evaluation.
# Check if the task has any predecessors.
# Try to load each predecessor task.
#* If loading of any predecessor fails (the object is not available offline), the task will be locked.
# If all predecessor tasks are finished, the task is open and can be edited. Otherwise, the task is locked.

The customizer setting up the task dependency relations needs to ensure that the dependencies are not cyclical. In this case, it would be impossible for any tasks in the "cycle" to be finished.

'''Example'''

As a demonstration of this feature, see [[Media:Sequential_tasks_winx.mp4|this video]]. The relations between tasks are defined as in [[Media:Task_relations.png|this image]], starting at A1 and A2, which are not dependent on any other tasks. The lines (from left to right) indicate dependencies. This means that B2 has tasks A1 and A2 as its predecessors, for example.

==== Grouped Task {{Version/WinXSince|4.2}}{{Version/XamarinSince|4.2}} ====
Sometimes, not all tasks have to be finished. More specifically, there might be a predefined condition where you only need to finish a certain number of tasks among a group of them. These are known in {{UBIK}} as [[MROCLS_GROUPEDTASK|grouped tasks]].

The idea is, a group of tasks can be defined as siblings to each other and they also share the same server configured threshold. When the number of finished tasks among that group exceeds the threshold, the entire group is considered as no longer necessary. When reflected in the overall status of the task owner(s), these tasks would appear as if they are finished.

{{Hint|Technically speaking, the finished status is completely independent from the not necessary status on a task. A grouped task which is no longer necessary can be both finished or not yet finished. In other words, users don't have to finish a not necessary grouped task, but they still can.}}

{{Hint|The precise status calculation for grouped tasks and their task owners requires the knowledge of all siblings tasks. Imagine 2 out of 3 tasks must be finished but the client only knows 1 in total and the others are only available at the server at that time. This makes it impossible to draw conclusions whether the task(s) should be necessary or not. Under such circumstances, the local status calculation is done as if these are just regular tasks.}}

{{Hint|Like with the other MRO objects, the client always chooses the best available statuses for grouped tasks to present to the users. More specifically, it uses the statuses calculated by the server when the client is not offline and there are no uncommitted local changes on the involved objects. Otherwise, it uses the statuses calculated locally to the best of its knowledge.}}

A task can also be a grouped and a sequential one at the same time. In such a case, the grouped nature of the sibling tasks will affect the way the task sequence completes.

For example, task A1, A2 and A3 are 3 grouped sibling tasks and only 1 of them needs to be finished. At the same time, they are all predecessors of task B. Normally, all predecessors must be finished (and locked) before task B becomes the next one in the sequence and therefore unlocked. In this case, however, as soon as one of the predecessors is finished, all three become unnecessary (and locked) and task B unlocks as a result of that.

==== Supervisor Task {{Version/XamarinSince|4.8}} ====
As the name suggests, supervisor tasks are those that must be finished under supervision. When users want to finish a [[MROCLS_MRO_SUPERVISOR_TASK|supervisor task]], they must hand over their work devices to a supervisor. The latter checks the work status and scans an NFC tag if the work is approved. If the [[MROCLS_MRO_SUPERVISOR|supervisor]] has sufficient permissions for the task and the correct supervisor PIN is given, the task gets unlocked and the users can proceed to finish it.

<gallery widths=300px heights=300px>
File:UI_Xamarin_Supervisor_Task_Before_Verification.jpg|Supervisor Task Before Verification/Unlocking (Mobile)
File:UI_Xamarin_Supervisor_Task_Enter_PIN.jpg|Supervisor Task Enter PIN (Mobile)
File:UI_Xamarin_Supervisor_Task_After_Verification.jpg|Supervisor Task After Verification/Unlocking (Mobile)
</gallery>

A thing to note is that while the need to verify a supervisor task can be seen as a type of locking, it's certainly not the only reason for a [[Locked_Objects|locked object]]. This means a supervisor task can remain locked (although for different reasons) even after a supervisor has successfully verified it. This can often be the case if you use it in combination with other features such as [[MRO_Objects_(Client)#Sequential_Task|sequential tasks]], [[User_Rights|user rights]].

{{Hint|For security reasons, the verification process is cancelled if the supervisor enters the wrong PIN for three times. Scanning the tag again is required in that case.}}
{{Hint|A setting controls [[RFID_tags#Choose_which_information_to_use_from_a_tag|which information in a scanned tag is used]] during this process.}}

==== Signature Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

The Signature Task is a task type that is completed by capturing a handwritten signature from the user. The task contains an editor field that serves as the entry point for the signing process. When the user clicks (or taps) on the editor field, a signature dialog opens. Within this dialog, the user can provide their signature. After confirming the input, the signature is saved and the task is automatically marked as completed.

If the task is signed while the client is online:
* The User (signee) is resolved immediately by the server and displayed.
* The ValidationTimestamp is generated and displayed.
* Both values are shown directly in the editor field after signing.

{{Hint|The User only gets resolved by the server and displayed once you're in online mode}}

If the displayed User and/or ValidationTimestamp cannot be fully shown due to limited space in the editor field, the complete information can be accessed via a Popup.
To show the Popup displaying the full User and ValidationTimestamp without truncation, click on the editor field.

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

==== Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_PICTURE_TASK|picture task]] is a check task which can only be finished when it has at least one child document containing a valid file. In the UI, an additional photo button is presented next to the check so users can easily take photos before finishing the tasks.
* As any other objects, picture tasks can carry and display [[SYSCLS_CHILDINFOOWNER|child count information]]. But that is not a mandatory part of the feature. Even when it's not configured and not visible in the UI, you can still finish the tasks.
* In WinX/UWP, the UI also presents an expander which allows you to display the child documents of picture tasks. This is not present by default in the Mobile app due to the screen size limit but [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#Show_NextLevel_Children.2FDocuments|can be easily customized]].

{{Hint|The task is named as such because pictures are the most commonly used types, but the child documents can be of other types as well. }}

When a user tries to finish a picture task by tapping the check, the app might perform some data synchronization first if in online mode, which includes
* Syncing the child objects (including documents) of the task.
* Downloading the file(s) of the child documents.
During data synchronization, the check button on that task turns into a wait indicator. Afterwards, the app checks if the prerequisites to finish the task are met.
* If there are no child documents or no local files for the child documents, the task remains unfinished and the user gets informed about the reasons.
* Otherwise, the task gets finished and the photo button gets disabled.

{{Hint|Setting NA (not applicable) on a picture task is always possible, regardless of the condition of child documents.}}

==== Numeric Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_MRO_NUMERIC_TASK|numeric task]] is a task which records a double value (e.g. from a temperature sensor). Entering the value (including Not Applicable) completes the task.
* The value is compared against an accaptable value range which is not editable on the client.
* Deviation from this range results in visual feedback as well as the [[#Tech Status|tech status]] being set to display an issue.
* If the configured value range is invalid (e.g. min > max) and the user enters a value, the [[#Tech Status|tech status]] will also be set to display an issue.
* A numeric task also has a special value unit that can be set per task instance. If set, it overrides the standard value unit defined on the [[MetaProperty#Unit_Item|MetaProperty]].

==== Pick List Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_PICK_LIST_TASK|Pick List task]] looks and behaves the same like a standard Integer Task with SelectiveList. Other than the standard Integer Task, the Pick List Task has an [[UBIK_Active_Lists|Active List]] defined on instance level to pick from for its value property. The task counts as finished as soon as a list item has been selected, or when pressing ''Not Applicable''.

{{DeprecatedStartTag|parameter=Please refer to [[Main_Page]] for the most recent information.}}
=== MRO objects with project information (WinX only) {{Version/WinXSince|2.5.4}} ===
[[File:UI_WinX_MRO_ProjectInfo.png|thumb|MRO Object with Project Info (WinX)]]
An MRO object (except tasks) might also bring along [[MROCLS_PROJECTINFORMATION|project information]]. In this case, the project information together with the MRO progress are displayed in a bar chart. The start & end dates of the MRO object are displayed on the progress bar. The length and the position of the progress bar, together with the current date mark indicate the timeline.
{{Clear}}
{{DeprecatedEndTag}}

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

== Locking ==
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].

== See also ==
* [[MRO (Plugin)]]
* [[MROCLS_PROJECT]]
* [[MROCLS_PROJECTINFORMATION]]
* [[MROCLS_SEQUENTIALTASK]]
* [[MROCLS_GROUPEDTASK]]
* [[MROCLS_MRO_CHECK_TASK]]
* [[MROCLS_MRO_INSPECTION_TASK]]
* [[MROCLS_MRO_MEASUREMENT_TASK]]
* [[MROCLS_MRO_PROGRESS_TASK]]
* [[MROCLS_MRO_TASK]]
* [[MROCLS_MRO_TASKOWNER]]
* [[MROCLS_MRO_WORKPACKAGE]]
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)
* [[MROCLS_PICK_LIST_TASK]] (Classification)

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

MRO Objects (Client)

2026-05-26T07:19:13Z

LMA: /* See also */

[[File:MRO_WinX.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
[[File:MRO_MAUI1.jpeg|thumb|alt=MRO Child List UI (Android)|MRO UI (Android)]]
The WinX client UI displays MRO configured objects like any other root- or child-object enriched by some additional logic and features.

== Basic User Interface ==
The representation of MRO features comprises some indicators and interactive controls. In the {{UBIK}} child list, the main object displays cumulated technical and organisational status as well as the overall work progress based on the underlying data branch. Objects classified as MRO objects in general provide indicators for the MRO status. This means the status is shown next to the main icon of a child-/details-/documents-page as well as next to the icons of the child list items:

=== Technical Status ===

The technical status indicator is shown on all objects that represent a technical state or receive the technical status from subsequent objects in the underlying data branch. If e.g. a inventory object is reported as damaged, its parent objects will all display the exclamation mark symbol to indicate that a problem was reported in the child items.

[[File:TechStats_WinX.png|100px|Technical Status Indicator (Winx & Mobile)]]

=== Organisational Status ===
The organisational status indicates the amount of confirmed work within the data branch, including already confirmed work packages as well as tasks that are locked by their owning work package. The organisational status indicator is displayed on all objects that represent an organisational state or receive the organisational status from subsequent objects in the underlying data branch, and visualizes the amount of confirmed work performed within that branch.
<gallery>
File:OrgaStatusIndicatorWinX.PNG|Organisational Status Indicator (WinX)
File:ConfirmedWP_WinX.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
File:ConfirmedWP_MAUI.jpeg|MRO Workpackage Confirmed Indicator (Mobile)
</gallery>

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

=== Work Progress ===
The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.

{{Version/WinXSince|5.0}} {{Version/MobileSince|5.0}} By default, the progress is displayed with maximum one decimal place. For example, 99.75% is displayed as 99.8%. The format string used to achieve this is <code>{0:0.#}%</code>.

If other numeric formats are preferred in your usecases, you can refer to [https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings custom numeric format strings] for more information. The template to customize for this is the UBIKMROProgressBadge within UBIKThemes.

{{Clear}}

== MRO Objects ==
A set of specific objects can be used to provide the required structure for MRO:

=== Task Owner ===
A [[MROCLS_MRO_TASKOWNER|Task Owner]] is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.

=== Work Package===
A [[MROCLS_MRO_WORKPACKAGE|Work Package]] is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed. Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.

<gallery>
File:ConfirmingWP_WinX.png|MRO Workpackage confirm button (WinX)
File:MRORevoke_WinX.png|MRO Workpackage revoke confirmation button (WinX)
File:ConfirmingWP_MAUI.jpeg|MRO Workpackage confirm button (Android)
File:MRORevoke_MAUI.jpeg|MRO Workpackage revoke confirmation button (Android)
</gallery>

=== Task ===
A [[MROCLS_MRO_TASK|Task]] is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called '''VALUE''' in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.

On both clients, a Task can be reverted by clicking twice on the Not Applicable button.

{{Attention|The MetaProperty ''VALUE'' has to use [[Attributes]] in order to be validated. Otherwise, the calculation of work progress will not be possible.}}

==== Measurement Task ====

A [[MROCLS_MRO_MEASUREMENT_TASK|Measurement Task]] inherits from [[MROCLS_MRO_TASK|Task]] and documents a measured value (e.g. read from a pressure gauge). Therefore, clicking the value on the shown task opens an editor to enter the desired value. If no value was entered before, an empty line will be shown. Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option ''Not Applicable'' to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken). An additional small value indicator below the main value can report e.g. the previously entered value. The behaviour of this previous value indicator has to be specified separately in the customizing.
{{Clear}}

<gallery widths=497px heights=69px>
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
</gallery>

==== Progress Task ====

[[MROCLS_MRO_PROGRESS_TASK| Progress Task]] inherits from [[MROCLS_MRO_MEASUREMENT_TASK|Task]] and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option ''Not Applicable''.

There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
{{Clear}}

<gallery widths=497px heights=69px>
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
</gallery>

==== Check Task ====

A [[MROCLS_MRO_CHECK_TASK|Check Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished by reporting ''Done'' or ''Not Applicable''. This is intended for a simple To-Do task that is either done or not.
{{Clear}}

<gallery widths=497px heights=69px>
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
</gallery>

==== Inspection Task ====

[[MROCLS_MRO_INSPECTION_TASK|Inspection Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished, when the user reports with a positive or negative answer or ''Not Applicable'' (e.g. reporting a yes/no answer for existing equipment).
{{Clear}}

<gallery widths=497px heights=69px>
File:Finished Inspection Task UWP.png|Finished MRO InspectionTask (WinX)
File:Inspection task android.jpg|Finished MRO InspectionTask (Android)
</gallery>

==== Sequential Task ====
The [[MROCLS_SEQUENTIALTASK|sequential task classification]] allows you to pre-define a sequence in which tasks are to be resolved by users. This means that it is required for one or multiple tasks to be finished in order for other tasks to become "unlocked" and editable. A task can have any number of "predecessors". Predecessors are the tasks that are required to be finished first.

A task can have predecessors that live anywhere else in the object hierarchy. It is not necessary for a task and its predecessors to be part of the same work package, even though this is likely the most common use case.

The state of a sequential task is evaluated both offline and online to get the best possible user experience. The user will see dependent tasks update immediately if their successors were finished, if those tasks are currently visible in the UI. There is 1 case in which the server-side state will override the client-side (offline) evaluation, discussed below.
The state of each sequential task is evaluated the following way:

# If the server-side state says the task is open, we consider this as the truthful state and don't do any other evaluation.
# Check if the task has any predecessors.
# Try to load each predecessor task.
#* If loading of any predecessor fails (the object is not available offline), the task will be locked.
# If all predecessor tasks are finished, the task is open and can be edited. Otherwise, the task is locked.

The customizer setting up the task dependency relations needs to ensure that the dependencies are not cyclical. In this case, it would be impossible for any tasks in the "cycle" to be finished.

'''Example'''

As a demonstration of this feature, see [[Media:Sequential_tasks_winx.mp4|this video]]. The relations between tasks are defined as in [[Media:Task_relations.png|this image]], starting at A1 and A2, which are not dependent on any other tasks. The lines (from left to right) indicate dependencies. This means that B2 has tasks A1 and A2 as its predecessors, for example.

==== Grouped Task {{Version/WinXSince|4.2}}{{Version/XamarinSince|4.2}} ====
Sometimes, not all tasks have to be finished. More specifically, there might be a predefined condition where you only need to finish a certain number of tasks among a group of them. These are known in {{UBIK}} as [[MROCLS_GROUPEDTASK|grouped tasks]].

The idea is, a group of tasks can be defined as siblings to each other and they also share the same server configured threshold. When the number of finished tasks among that group exceeds the threshold, the entire group is considered as no longer necessary. When reflected in the overall status of the task owner(s), these tasks would appear as if they are finished.

{{Hint|Technically speaking, the finished status is completely independent from the not necessary status on a task. A grouped task which is no longer necessary can be both finished or not yet finished. In other words, users don't have to finish a not necessary grouped task, but they still can.}}

{{Hint|The precise status calculation for grouped tasks and their task owners requires the knowledge of all siblings tasks. Imagine 2 out of 3 tasks must be finished but the client only knows 1 in total and the others are only available at the server at that time. This makes it impossible to draw conclusions whether the task(s) should be necessary or not. Under such circumstances, the local status calculation is done as if these are just regular tasks.}}

{{Hint|Like with the other MRO objects, the client always chooses the best available statuses for grouped tasks to present to the users. More specifically, it uses the statuses calculated by the server when the client is not offline and there are no uncommitted local changes on the involved objects. Otherwise, it uses the statuses calculated locally to the best of its knowledge.}}

A task can also be a grouped and a sequential one at the same time. In such a case, the grouped nature of the sibling tasks will affect the way the task sequence completes.

For example, task A1, A2 and A3 are 3 grouped sibling tasks and only 1 of them needs to be finished. At the same time, they are all predecessors of task B. Normally, all predecessors must be finished (and locked) before task B becomes the next one in the sequence and therefore unlocked. In this case, however, as soon as one of the predecessors is finished, all three become unnecessary (and locked) and task B unlocks as a result of that.

==== Supervisor Task {{Version/XamarinSince|4.8}} ====
As the name suggests, supervisor tasks are those that must be finished under supervision. When users want to finish a [[MROCLS_MRO_SUPERVISOR_TASK|supervisor task]], they must hand over their work devices to a supervisor. The latter checks the work status and scans an NFC tag if the work is approved. If the [[MROCLS_MRO_SUPERVISOR|supervisor]] has sufficient permissions for the task and the correct supervisor PIN is given, the task gets unlocked and the users can proceed to finish it.

<gallery widths=300px heights=300px>
File:UI_Xamarin_Supervisor_Task_Before_Verification.jpg|Supervisor Task Before Verification/Unlocking (Mobile)
File:UI_Xamarin_Supervisor_Task_Enter_PIN.jpg|Supervisor Task Enter PIN (Mobile)
File:UI_Xamarin_Supervisor_Task_After_Verification.jpg|Supervisor Task After Verification/Unlocking (Mobile)
</gallery>

A thing to note is that while the need to verify a supervisor task can be seen as a type of locking, it's certainly not the only reason for a [[Locked_Objects|locked object]]. This means a supervisor task can remain locked (although for different reasons) even after a supervisor has successfully verified it. This can often be the case if you use it in combination with other features such as [[MRO_Objects_(Client)#Sequential_Task|sequential tasks]], [[User_Rights|user rights]].

{{Hint|For security reasons, the verification process is cancelled if the supervisor enters the wrong PIN for three times. Scanning the tag again is required in that case.}}
{{Hint|A setting controls [[RFID_tags#Choose_which_information_to_use_from_a_tag|which information in a scanned tag is used]] during this process.}}

==== Signature Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

The Signature Task is a task type that is completed by capturing a handwritten signature from the user. The task contains an editor field that serves as the entry point for the signing process. When the user clicks (or taps) on the editor field, a signature dialog opens. Within this dialog, the user can provide their signature. After confirming the input, the signature is saved and the task is automatically marked as completed.

If the task is signed while the client is online:
* The User (signee) is resolved immediately by the server and displayed.
* The ValidationTimestamp is generated and displayed.
* Both values are shown directly in the editor field after signing.

{{Hint|The User only gets resolved by the server and displayed once you're in online mode}}

If the displayed User and/or ValidationTimestamp cannot be fully shown due to limited space in the editor field, the complete information can be accessed via a Popup.
To show the Popup displaying the full User and ValidationTimestamp without truncation, click on the editor field.

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

==== Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_PICTURE_TASK|picture task]] is a check task which can only be finished when it has at least one child document containing a valid file. In the UI, an additional photo button is presented next to the check so users can easily take photos before finishing the tasks.
* As any other objects, picture tasks can carry and display [[SYSCLS_CHILDINFOOWNER|child count information]]. But that is not a mandatory part of the feature. Even when it's not configured and not visible in the UI, you can still finish the tasks.
* In WinX/UWP, the UI also presents an expander which allows you to display the child documents of picture tasks. This is not present by default in the Mobile app due to the screen size limit but [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#Show_NextLevel_Children.2FDocuments|can be easily customized]].

{{Hint|The task is named as such because pictures are the most commonly used types, but the child documents can be of other types as well. }}

When a user tries to finish a picture task by tapping the check, the app might perform some data synchronization first if in online mode, which includes
* Syncing the child objects (including documents) of the task.
* Downloading the file(s) of the child documents.
During data synchronization, the check button on that task turns into a wait indicator. Afterwards, the app checks if the prerequisites to finish the task are met.
* If there are no child documents or no local files for the child documents, the task remains unfinished and the user gets informed about the reasons.
* Otherwise, the task gets finished and the photo button gets disabled.

{{Hint|Setting NA (not applicable) on a picture task is always possible, regardless of the condition of child documents.}}

==== Numeric Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_MRO_NUMERIC_TASK|numeric task]] is a task which records a double value (e.g. from a temperature sensor). Entering the value (including Not Applicable) completes the task.
* The value is compared against an accaptable value range which is not editable on the client.
* Deviation from this range results in visual feedback as well as the [[#Tech Status|tech status]] being set to display an issue.
* If the configured value range is invalid (e.g. min > max) and the user enters a value, the [[#Tech Status|tech status]] will also be set to display an issue.
* A numeric task also has a special value unit that can be set per task instance. If set, it overrides the standard value unit defined on the [[MetaProperty#Unit_Item|MetaProperty]].

==== Pick List Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

A [[MROCLS_PICK_LIST_TASK|Pick List task]] looks and behaves the same like a standard Integer Task with SelectiveList. Other than the standard Integer Task, the Pick List Task has an [[UBIK_Active_Lists|Active List]] defined on instance level to pick from for its value property. The task counts as finished as soon as a list item has been selected, or when pressing ''Not Applicable''.

{{DeprecatedStartTag|parameter=Please refer to [[Main_Page]] for the most recent information.}}
=== MRO objects with project information (WinX only) {{Version/WinXSince|2.5.4}} ===
[[File:UI_WinX_MRO_ProjectInfo.png|thumb|MRO Object with Project Info (WinX)]]
An MRO object (except tasks) might also bring along [[MROCLS_PROJECTINFORMATION|project information]]. In this case, the project information together with the MRO progress are displayed in a bar chart. The start & end dates of the MRO object are displayed on the progress bar. The length and the position of the progress bar, together with the current date mark indicate the timeline.
{{Clear}}
{{DeprecatedEndTag}}

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

== Locking ==
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].

== See also ==
* [[MRO (Plugin)]]
* [[MROCLS_PROJECT]]
* [[MROCLS_PROJECTINFORMATION]]
* [[MROCLS_SEQUENTIALTASK]]
* [[MROCLS_GROUPEDTASK]]
* [[MROCLS_MRO_CHECK_TASK]]
* [[MROCLS_MRO_INSPECTION_TASK]]
* [[MROCLS_MRO_MEASUREMENT_TASK]]
* [[MROCLS_MRO_PROGRESS_TASK]]
* [[MROCLS_MRO_TASK]]
* [[MROCLS_MRO_TASKOWNER]]
* [[MROCLS_MRO_WORKPACKAGE]]
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)
* [[MROCLS_PICK_LIST_TASK]] (Classification)
* [[MROCLS_PICK_LIST_TASK]] (Classification)

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

MRO Implemented Objects

2026-05-26T07:18:17Z

LMA: /* Procedure Tasks */

MRO Implemented Objects are pre-configured standard MRO objects enhanced with additional logic and features. For most tasks, value properties are pre-set, and many of them also implement additional MRO-relevant classifications.

== Workpackage ==

=== Procedure Workpackage ===
MetaClass Name: PROCEDURE_WORKPACKAGE | MetaClass UID: 007c78f8-fafd-4bde-8add-e11990625e7a

A Procedure Workpackage serves as a container for tasks and other procedures. It stores its entire structure in a JSON format, which is predefined using a workflow editor. When a specific state is triggered, the corresponding sub-tasks and procedures are created or updated accordingly.

Extra Classifications: [[MROCLS_PROCEDURE]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| PROCEDURE_STATUS || {{Integer}} || Represents the current state: Draft = 10, ReadyToUse = 20, Published = 30, Open = 40, Executing = 50, Completed = 60, Approved = 70, Rejected = 80
|-
| JSON || {{String}} || JSON representation of the procedure
|-
| ISTEMPLATE || {{Boolean}} || Indicates whether the procedure is a template
|}

== Task ==

=== Switch Start Task ===
MetaClass Name: SWITCH_START_TASK | MetaClass UID: 3c3614e2-635f-4e07-b02a-a72c81b9e328

A Switch Start Task confirms task completion by the system after an expression calculation. The task is automatically marked as complete once the calculation finishes successfully. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_START_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state: Undefined = 0, Ongoing = 10, Finished = 20, Error = 30
|-
| BRANCH_TRUE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as true
|-
| BRANCH_FALSE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as false
|-
| DISPLAYSTRING_TRUE || {{String}} || DisplayString for the case the expression is evaluated as true
|-
| DISPLAYSTRING_FALSE || {{String}} || DisplayString for the case the expression is evaluated as false
|-
| VALUE || {{Boolean}} || Result of the evaluated expression
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Switch End Task ===
MetaClass Name: SWITCH_END_TASK | MetaClass UID: 261a3e63-2b8e-4f3e-ab22-295bbe421e7a

A Switch End Task confirms task completion by the system. The task is invisible to the user and is always automatically marked as complete. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_END_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LK_SWITCH_START_TASK || {{Guid}} || Link to Switch task
|}

=== Check Task ===
MetaClass Name: CHECK_TASK | Metaclass UID: A360287D-2979-4D91-8B1A-6086FC1BEDA1 
MetaClass Name: CUSTOM_CHECK_TASK | Metaclass UID: DF61A1DB-5238-4A87-85A6-B9C09B54B242

A Check Task confirms task completion. The task is complete once a value is selected (including Not Applicable). 

Extra Classifications: [[MROCLS_MRO_CHECK_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Numeric Task ===
MetaClass Name: NUMERIC_TASK | MetaClass UID: b1789da3-bd67-4f93-b14b-22fd41afb215 
MetaClass Name: CUSTOM_NUMERIC_TASK | MetaClass UID: 047d05f3-a876-4f9d-a40e-2a098e9ba49b

A Numeric Task records a numeric double value (e.g., from a temperature sensor). Once a value is entered (including Not Applicable), the task is considered complete.
An acceptability range and measurement unit can be defined. If the value falls outside the acceptable range, a red alert and/or a technical status update can be triggered.
The behaviour of the previous value indicator must be defined separately.

Extra Classifications: [[MROCLS_MRO_NUMERIC_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Double}} || Recorded double numeric value
|-
| VALUE_UNIT || {{String}} || Measurment unit
|}

=== Inspection Task ===
MetaClass Name: INSPECTION_TASK | MetaClass UID: 08571b05-a093-479a-a10a-9d03c435b1b5 
MetaClass Name: CUSTOM_INSPECTION_TASK | MetaClass UID: a0123b54-ddcf-49be-8c66-7ca86c4c5277

An Inspection Task captures a binary decision. Once a value is selected (including Not Applicable), the task is complete. 
Custom labels can override the default icons: Checkmark (✔) and Cross (✘).
Label behavior must be defined separately in the customization settings.

Extra Classifications: [[MROCLS_MRO_INSPECTION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LABEL_FALSE || {{String}} || Label for negative outcome
|-
| LABEL_TRUE || {{String}} || Label for positive outcome
|}

=== Text Task ===
MetaClass Name: TEXT_TASK | MetaClass UID: 7298d038-003a-41d5-bc24-c97018ca7e85 
MetaClass Name: CUSTOM_TEXT_TASK | MetaClass UID: c0a95da8-8e32-4036-8db4-ef438deb14de

A Text Task allows entry of free-form text. Once a value is entered (including Not Applicable), the task is complete.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{String}} || Entered text
|}

=== Picture Task ===
MetaClass Name: PICTURE_TASK | MetaClass UID: bee0b281-7da1-470e-9838-46724d47b621 
MetaClass Name: CUSTOM_PICTURE_TASK | MetaClass UID: e58c6957-ecb2-4e3f-a4b7-6953b917d7d4

A Picture Task confirms whether a photo has been taken. The task is only complete once a value is entered (including Not Applicable). 
A button must be available to add a photo as a child object. Task confirmation is blocked unless at least one photo is attached.
The behavior for photo addition and confirmation blocking must be defined in customization.

Extra Classifications: [[MROCLS_PICTURE_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Pick List Task ===
MetaClass Name: PICKLIST_TASK | MetaClass UID: 78651014-f41e-4254-987f-6cf55c687d35 
MetaClass Name: CUSTOM_PICKLIST_TASK | MetaClass UID: 83551c77-554e-4715-b327-16f0a6ee196a

A Pick List Task allows the user to select one value from a list of available items. It looks and behaves similarly to a standard Integer Task with a Selective List, but its selectable values are provided by an Active List defined on instance level.

Once a list item is selected, the task is considered complete. Alternatively, the task can be completed by selecting Not Applicable, if this option is available.

Pick List Tasks are intended for MRO workflows where the available options depend on the concrete task instance or workflow context instead of being defined globally.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Integer}} || Selected list item value
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Supervisor Check Task ===
MetaClass Name: SUPERVISOR_CHECK_TASK | MetaClass UID: 76910d64-5bc0-4674-9c43-108959119846 
MetaClass Name: CUSTOM_SUPERVISOR_CHECK_TASK | MetaClass UID: 1e4a5506-0c6f-4447-bd0a-d5c87282a0e9

A Supervisor Check Task confirms task completion by a supervisor. The task is complete once a value is selected. 
Confirmation is only possible after NFC recognition of the supervisor and PIN entry.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| SUPERVISOR || {{Guid}} || Supervisor
|-
| PERMISSION || {{String}} || Supervisor permissions
|}

=== Interface Task ===
MetaClass Name: INTERFACE_TASK | MetaClass UID: d9a80e3d-02f6-4f0c-b243-7ece9ad82849 
MetaClass Name: CUSTOM_INTERFACE_TASK | MetaClass UID: e437ef02-d49b-4f23-9ab8-9a9836366c3d

Currently under development.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Calculation Task ===
MetaClass Name: CALCULATION_TASK | Metaclass UID: 3ec9d0f2-9d0f-4c1b-80bd-1efeaf010fa0 
MetaClass Name: CUSTOM_CALCULATION_TASK | Metaclass UID: e2b24a28-2382-46d2-8f4b-5f52168a9e27

Currently under development.

Extra Classifications: [[MROCLS_CALCULATION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state (Undefined = 0, Pending = 10, Finished = 20, Error = 30)
|-
| TARGET_PROPERTY_NAME || {{String}} || Name of Target Property (on owner)
|-
| TARGET_PROPERTY_TYPE || {{Integer}} || Type of Target Property (Undefined = 0, Bool = 1, Int = 3, Double = 4)
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Signature Task ===
MetaClass Name: SIGNATURE_TASK | Metaclass UID: 66D6A529-E233-4CE2-9E11-B65984D5B0DA 
MetaClass Name: CUSTOM_SIGNATURE_TASK | Metaclass UID: ECE1E20F-2BA3-4BC4-A0DD-9AFFDBB23790

A Signature Task captures a sign-off action to confirm the completion of a procedure. The task is complete once a written signature is provided. 

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Signature}} || Signature
|}

== Procedure Tasks ==
The following tasks are specialized versions intended for use within procedures. They implement both the [[MROCLS_SEQUENTIALTASK]] and [[MROCLS_GROUPEDTASK]] classifications.

MetaClass Name: PROCEDURE_CHECK_TASK | MetaClass UID: 63D68EA4-E78C-4A33-A35A-301A01A2568E 
MetaClass Name: PROCEDURE_NUMERIC_TASK | MetaClass UID: f578f50b-eecd-4734-929b-43e1f1f246fa 
MetaClass Name: PROCEDURE_INSPECTION_TASK | MetaClass UID: 9369b841-c5bf-43df-909f-3a5063763f81 
MetaClass Name: PROCEDURE_TEXT_TASK | MetaClass UID: 4dd8fee2-9d3e-4fa1-9a61-d580f5d4201c 
MetaClass Name: PROCEDURE_PICTURE_TASK | MetaClass UID: 4c0db9da-dfcc-48ad-9d89-6c958a5ac39f 
MetaClass Name: PROCEDURE_SUPERVISOR_CHECK_TASK | MetaClass UID: 9bb8e1b1-04f8-46f0-a9c9-0bb2960a49e5 
MetaClass Name: PROCEDURE_INTERFACE_TASK | MetaClass UID: 8d9ff119-510b-425c-b917-f72783e4570c 
MetaClass Name: PROCEDURE_CALCULATION_TASK | Metaclass UID: ed31735c-c807-40e9-b9a4-254e77445dd5 
MetaClass Name: PROCEDURE_SIGNATURE_TASK | Metaclass UID: 202CDB9D-BEEB-4E5A-A333-5235A9E6FF94 
MetaClass Name: PROCEDURE_PICK_LIST_TASK | MetaClass UID: 241a2248-36f6-44ab-9c8d-0357b7cbe24c 

[[Category:Plugin|MRO Implemented Objects]]

== File Documents ==

=== JSON File Document ===
MetaClass Name: FILEDOCUMENT_MRO_JSON | MetaClass UID: 016e57d5-37b3-42e0-a753-f675d4cbf338

File Document for JSON file of a Procedure Workpackage.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PROCEDURE_WORKPACKAGE || {{Guid}} ||
|}

=== Picture Task File document ===
MetaClass Name: FILEDOCUMENT_MRO_PICTURE_TASK | MetaClass UID: 2488fd79-4729-4090-9587-82103a9869e0

File Document for image files of a Picture Task.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PICTURE_TASK || {{Guid}} ||
|}

== See also ==
* [[MRO_(Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MROCLS_MRO_TASK#Task]] (Classification)
* [[MROCLS_SEQUENTIALTASK]] (Classification)
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)

[[Category:Plugin|MRO Implemented Objects]]

MRO Implemented Objects

2026-05-26T07:16:53Z

LMA: /* Dynamic List Task */

MRO Implemented Objects are pre-configured standard MRO objects enhanced with additional logic and features. For most tasks, value properties are pre-set, and many of them also implement additional MRO-relevant classifications.

== Workpackage ==

=== Procedure Workpackage ===
MetaClass Name: PROCEDURE_WORKPACKAGE | MetaClass UID: 007c78f8-fafd-4bde-8add-e11990625e7a

A Procedure Workpackage serves as a container for tasks and other procedures. It stores its entire structure in a JSON format, which is predefined using a workflow editor. When a specific state is triggered, the corresponding sub-tasks and procedures are created or updated accordingly.

Extra Classifications: [[MROCLS_PROCEDURE]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| PROCEDURE_STATUS || {{Integer}} || Represents the current state: Draft = 10, ReadyToUse = 20, Published = 30, Open = 40, Executing = 50, Completed = 60, Approved = 70, Rejected = 80
|-
| JSON || {{String}} || JSON representation of the procedure
|-
| ISTEMPLATE || {{Boolean}} || Indicates whether the procedure is a template
|}

== Task ==

=== Switch Start Task ===
MetaClass Name: SWITCH_START_TASK | MetaClass UID: 3c3614e2-635f-4e07-b02a-a72c81b9e328

A Switch Start Task confirms task completion by the system after an expression calculation. The task is automatically marked as complete once the calculation finishes successfully. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_START_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state: Undefined = 0, Ongoing = 10, Finished = 20, Error = 30
|-
| BRANCH_TRUE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as true
|-
| BRANCH_FALSE || {{Guid}} || Link to another task or task owner for the case the expression is evaluated as false
|-
| DISPLAYSTRING_TRUE || {{String}} || DisplayString for the case the expression is evaluated as true
|-
| DISPLAYSTRING_FALSE || {{String}} || DisplayString for the case the expression is evaluated as false
|-
| VALUE || {{Boolean}} || Result of the evaluated expression
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Switch End Task ===
MetaClass Name: SWITCH_END_TASK | MetaClass UID: 261a3e63-2b8e-4f3e-ab22-295bbe421e7a

A Switch End Task confirms task completion by the system. The task is invisible to the user and is always automatically marked as complete. No user input is required. 

Extra Classifications: [[MROCLS_SWITCH_END_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LK_SWITCH_START_TASK || {{Guid}} || Link to Switch task
|}

=== Check Task ===
MetaClass Name: CHECK_TASK | Metaclass UID: A360287D-2979-4D91-8B1A-6086FC1BEDA1 
MetaClass Name: CUSTOM_CHECK_TASK | Metaclass UID: DF61A1DB-5238-4A87-85A6-B9C09B54B242

A Check Task confirms task completion. The task is complete once a value is selected (including Not Applicable). 

Extra Classifications: [[MROCLS_MRO_CHECK_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Numeric Task ===
MetaClass Name: NUMERIC_TASK | MetaClass UID: b1789da3-bd67-4f93-b14b-22fd41afb215 
MetaClass Name: CUSTOM_NUMERIC_TASK | MetaClass UID: 047d05f3-a876-4f9d-a40e-2a098e9ba49b

A Numeric Task records a numeric double value (e.g., from a temperature sensor). Once a value is entered (including Not Applicable), the task is considered complete.
An acceptability range and measurement unit can be defined. If the value falls outside the acceptable range, a red alert and/or a technical status update can be triggered.
The behaviour of the previous value indicator must be defined separately.

Extra Classifications: [[MROCLS_MRO_NUMERIC_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Double}} || Recorded double numeric value
|-
| VALUE_UNIT || {{String}} || Measurment unit
|}

=== Inspection Task ===
MetaClass Name: INSPECTION_TASK | MetaClass UID: 08571b05-a093-479a-a10a-9d03c435b1b5 
MetaClass Name: CUSTOM_INSPECTION_TASK | MetaClass UID: a0123b54-ddcf-49be-8c66-7ca86c4c5277

An Inspection Task captures a binary decision. Once a value is selected (including Not Applicable), the task is complete. 
Custom labels can override the default icons: Checkmark (✔) and Cross (✘).
Label behavior must be defined separately in the customization settings.

Extra Classifications: [[MROCLS_MRO_INSPECTION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| LABEL_FALSE || {{String}} || Label for negative outcome
|-
| LABEL_TRUE || {{String}} || Label for positive outcome
|}

=== Text Task ===
MetaClass Name: TEXT_TASK | MetaClass UID: 7298d038-003a-41d5-bc24-c97018ca7e85 
MetaClass Name: CUSTOM_TEXT_TASK | MetaClass UID: c0a95da8-8e32-4036-8db4-ef438deb14de

A Text Task allows entry of free-form text. Once a value is entered (including Not Applicable), the task is complete.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{String}} || Entered text
|}

=== Picture Task ===
MetaClass Name: PICTURE_TASK | MetaClass UID: bee0b281-7da1-470e-9838-46724d47b621 
MetaClass Name: CUSTOM_PICTURE_TASK | MetaClass UID: e58c6957-ecb2-4e3f-a4b7-6953b917d7d4

A Picture Task confirms whether a photo has been taken. The task is only complete once a value is entered (including Not Applicable). 
A button must be available to add a photo as a child object. Task confirmation is blocked unless at least one photo is attached.
The behavior for photo addition and confirmation blocking must be defined in customization.

Extra Classifications: [[MROCLS_PICTURE_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Pick List Task ===
MetaClass Name: PICKLIST_TASK | MetaClass UID: 78651014-f41e-4254-987f-6cf55c687d35 
MetaClass Name: CUSTOM_PICKLIST_TASK | MetaClass UID: 83551c77-554e-4715-b327-16f0a6ee196a

A Pick List Task allows the user to select one value from a list of available items. It looks and behaves similarly to a standard Integer Task with a Selective List, but its selectable values are provided by an Active List defined on instance level.

Once a list item is selected, the task is considered complete. Alternatively, the task can be completed by selecting Not Applicable, if this option is available.

Pick List Tasks are intended for MRO workflows where the available options depend on the concrete task instance or workflow context instead of being defined globally.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Integer}} || Selected list item value
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Supervisor Check Task ===
MetaClass Name: SUPERVISOR_CHECK_TASK | MetaClass UID: 76910d64-5bc0-4674-9c43-108959119846 
MetaClass Name: CUSTOM_SUPERVISOR_CHECK_TASK | MetaClass UID: 1e4a5506-0c6f-4447-bd0a-d5c87282a0e9

A Supervisor Check Task confirms task completion by a supervisor. The task is complete once a value is selected. 
Confirmation is only possible after NFC recognition of the supervisor and PIN entry.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|-
| SUPERVISOR || {{Guid}} || Supervisor
|-
| PERMISSION || {{String}} || Supervisor permissions
|}

=== Interface Task ===
MetaClass Name: INTERFACE_TASK | MetaClass UID: d9a80e3d-02f6-4f0c-b243-7ece9ad82849 
MetaClass Name: CUSTOM_INTERFACE_TASK | MetaClass UID: e437ef02-d49b-4f23-9ab8-9a9836366c3d

Currently under development.

Extra Classifications: [[MROCLS_MRO_SUPERVISOR_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Boolean}} || Task completion
|}

=== Calculation Task ===
MetaClass Name: CALCULATION_TASK | Metaclass UID: 3ec9d0f2-9d0f-4c1b-80bd-1efeaf010fa0 
MetaClass Name: CUSTOM_CALCULATION_TASK | Metaclass UID: e2b24a28-2382-46d2-8f4b-5f52168a9e27

Currently under development.

Extra Classifications: [[MROCLS_CALCULATION_TASK]] 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| EXPRESSION || {{String}} || Condition that will be evaluated by the client
|-
| VALUE || {{Integer}} || Evaluation state (Undefined = 0, Pending = 10, Finished = 20, Error = 30)
|-
| TARGET_PROPERTY_NAME || {{String}} || Name of Target Property (on owner)
|-
| TARGET_PROPERTY_TYPE || {{Integer}} || Type of Target Property (Undefined = 0, Bool = 1, Int = 3, Double = 4)
|}

[[Category:Plugin|MRO Implemented Objects]]

=== Signature Task ===
MetaClass Name: SIGNATURE_TASK | Metaclass UID: 66D6A529-E233-4CE2-9E11-B65984D5B0DA 
MetaClass Name: CUSTOM_SIGNATURE_TASK | Metaclass UID: ECE1E20F-2BA3-4BC4-A0DD-9AFFDBB23790

A Signature Task captures a sign-off action to confirm the completion of a procedure. The task is complete once a written signature is provided. 

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| VALUE || {{Signature}} || Signature
|}

== Procedure Tasks ==
The following tasks are specialized versions intended for use within procedures. They implement both the [[MROCLS_SEQUENTIALTASK]] and [[MROCLS_GROUPEDTASK]] classifications.

MetaClass Name: PROCEDURE_CHECK_TASK | MetaClass UID: 63D68EA4-E78C-4A33-A35A-301A01A2568E 
MetaClass Name: PROCEDURE_NUMERIC_TASK | MetaClass UID: f578f50b-eecd-4734-929b-43e1f1f246fa 
MetaClass Name: PROCEDURE_INSPECTION_TASK | MetaClass UID: 9369b841-c5bf-43df-909f-3a5063763f81 
MetaClass Name: PROCEDURE_TEXT_TASK | MetaClass UID: 4dd8fee2-9d3e-4fa1-9a61-d580f5d4201c 
MetaClass Name: PROCEDURE_PICTURE_TASK | MetaClass UID: 4c0db9da-dfcc-48ad-9d89-6c958a5ac39f 
MetaClass Name: PROCEDURE_DYNAMIC_LIST_TASK | MetaClass UID: 241a2248-36f6-44ab-9c8d-0357b7cbe24c 
MetaClass Name: PROCEDURE_SUPERVISOR_CHECK_TASK | MetaClass UID: 9bb8e1b1-04f8-46f0-a9c9-0bb2960a49e5 
MetaClass Name: PROCEDURE_INTERFACE_TASK | MetaClass UID: 8d9ff119-510b-425c-b917-f72783e4570c 
MetaClass Name: PROCEDURE_CALCULATION_TASK | Metaclass UID: ed31735c-c807-40e9-b9a4-254e77445dd5 
MetaClass Name: PROCEDURE_SIGNATURE_TASK | Metaclass UID: 202CDB9D-BEEB-4E5A-A333-5235A9E6FF94 

== File Documents ==

=== JSON File Document ===
MetaClass Name: FILEDOCUMENT_MRO_JSON | MetaClass UID: 016e57d5-37b3-42e0-a753-f675d4cbf338

File Document for JSON file of a Procedure Workpackage.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PROCEDURE_WORKPACKAGE || {{Guid}} ||
|}

=== Picture Task File document ===
MetaClass Name: FILEDOCUMENT_MRO_PICTURE_TASK | MetaClass UID: 2488fd79-4729-4090-9587-82103a9869e0

File Document for image files of a Picture Task.

Extra Classifications: none 
Implemented Properties:
{| class="wikitable" width=50%
|-
! width=30% | Name !! width=20% | Data type !! Comment
|-
| LK_PICTURE_TASK || {{Guid}} ||
|}

== See also ==
* [[MRO_(Plugin)]]
* [[MRO_Objects_(Client)]]
* [[MROCLS_MRO_TASK#Task]] (Classification)
* [[MROCLS_SEQUENTIALTASK]] (Classification)
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)

[[Category:Plugin|MRO Implemented Objects]]