Maintenance Order

General

There are two ways in which maintenance orders are created; a maintenance order is generated when distributing a pending event or the maintenance order is created manually. With the manual creation of maintenance orders it is possible to plan a maintenance visit ahead of time. Planners of the visit can then create the maintenance order for the visit at any time prior to the actual visit occurring and can add and remove events (pending events and convenience tasks) from the maintenance order as the needs and requirements for the visit are established.

When distributing events you can create a package of events to be distributed to a maintenance order for execution at a workshop. You can only distribute events for the same top serial or a serial in its structure. The events on the maintenance order will be distributed with the same planned start and finish dates and with the same distribution type.

When the maintenance order is distributed with the Simplified Work Order distribution type, all events connected to the maintenance order will be handled within IFS/Fleet and Asset Management. When the Work Order distribution type is used, all events connected to the order will be created as work orders in IFS/Work Order Management and must be processed there. Task cards and subtasks included on the events will be created as work tasks, and connected resources, material, sign off requirements etc will be transferred to these work tasks. When the Execution Logic Structure distribution type is used, a work order structure will be created in IFS/Work Order Management based on the execution logic structure (ELS) for the maintenance order.

For information on how to process a work order in IFS/Work Order Management, refer the online help file Work Order. For information on work order distribution and handling in IFS/Fleet and Asset Management, refer the online help file Work Order - Fleet and Asset Management.

The following is a summary of the main actions that can be performed on a maintenance order:

Manually create and plan the order. This includes assigning pending events to the maintenance order.
Enter the grouping ID to use when sorting work on a maintenance order with the Execution Logic Structure distribution type.
Connect a service contract to the maintenance order. This is only applicable for maintenance orders with the Work Order or Execution Logic Structure distribution types. The service contract will be used to apply material ownership, based on part provisioning rules on the contract, to the maintenance order material demands and for additional material demands included during work execution (i.e., on the work tasks with the VIM connection type). When the maintenance order/event is released, the connected service contract will be transferred to the generated work orders and work tasks, and the most suitable vehicle service line on the contract will be applied to these work orders/work tasks. If a valid vehicle service line does not exist, no contract will be applied.
Connect a heavy maintenance contract to the maintenance order. This is only applicable for maintenance orders with the distribution type Work Order or Execution Logic Structure. The part provisioning rules are defined on the heavy maintenance contract will be used to apply material ownership to the maintenance order material demands and for additional material demands included during work execution (i.e., on the work tasks with the VIM connection type). When the maintenance order/event is released, the connected heavy maintenance contract, contract groups, and contract lines defined on the maintenance events will be assigned to the generated work orders and/or work tasks.
Calculate the progress of the maintenance order using valid progress templates.
Perform critical path calculation on the maintenance order ELS.
Identify the stages of a maintenance order and its connected events through the status-handling functionality.
Certification checking on the maintenance order and its connected events through defined signature requirements. The signature requirements define the requirements on the certifications required to sign off any work that has been carried out.
Follow up on the task cards and subtasks connected to events on the maintenance order.
Manage non routine work, i.e., abnormalities found during the execution of scheduled work.
Manage events generated as a result of condition measurements performed on work tasks for ongoing maintenance orders.
Connect task cards to the events that are connected to the maintenance order.
Connect post maintenance check information to an event if it is the execution of the event that has revealed the need for a post maintenance check to be carried out.
Create snapshots of a maintenance order.
Create a service quotation for the maintenance order or for a specific event on the maintenance order.

Note: The service contract or heavy maintenance contract will not be applied to the corresponding work orders and work tasks if,

Both contract and service quotation are connected to the maintenance order or
A contract is connected to the maintenance order and a service quotation is connected to an included maintenance event.

This is because in both instances the service quotation is prioritized instead of the service contract.

Maintenance Order Status

The following table shows a description of each status on the maintenance order:

Status	Description
New	The initial status used to represent an available maintenance slot. When a maintenance order is created manually it will automatically receive this status. In this status the maintenance order the minimum information required is the workshop ID and planned start and end dates.
Initial Scope Definition	The status used when defining the scope of the maintenance order, i.e., in terms of identifying the events to be included.
Under Preparation	The status in which task cards can be connected to the events and the execution logic structure is created.
Released	When the maintenance order with the Work Order or Execution Logic Structure distribution type is released, work orders will be generated per event and work tasks per task card and subtask. Data, such as, resources, material, and sign off requirements is transferred to the task.
Started	This status is used to indicate that work has started on the maintenance order.
Work Done	This status is used to indicate that all connected events are in either the Work Done or Finished status. When the maintenance order is in this status, sign off can be performed.
Finished	This status is used to indicate that the maintenance order has been signed off and is finished.
Cancelled	When a maintenance order is canceled, all connected events will be canceled as well. This status is used when the maintenance order is no longer applicable.

Maintenance Event Status

The following table shows a description of each status on an event:

Status	Description
New	The initial status used to represent an existing event that is not yet planned to be executed.
Planned in Scope	In this status the event has been planned on a maintenance order, but no work order has yet been created.
Incomplete	In this status the event has been planned on a maintenance order, but no task cards have been defined for the event.
Under Preparation	In this status task cards have been connected to events on the maintenance order.
Released	Depending on the distribution type selected, work orders will be created with connected work tasks, resources, material etc. when the event is released. When a MO is released with the distribution type work order, there is a character limit of 200 for the event description. If the character limit of the event in the event description exceeds 60, only the first 60 characters are displayed in the Directive of the work order.The full description is then passed into the long description.
Started	This status is used to indicate that work has started on at least one of the connected task cards.
Work Done	This status is used to indicate that all task cards have reached the Work Done status or a higher status. Sign off can be performed on events in this status. Note: It is possible to reopen a maintenance event if, for instance, unplanned work is required and you need to add more task cards to the event. When reopened, the event is set to the Started status.
Finished	This status is used to indicate that the event has been signed off and is finished. When the event reaches this status, it will be transferred to the serial order history.
Cancelled	When an event is canceled, the status of the event will be changed to New and it will be disconnected from the current maintenance order.

Plan Maintenance Visit

A maintenance order can be created weeks or even months ahead of time. The maintenance order can be created manually in an initial state to represent an available maintenance slot without any events yet being identified. In this initial state the maintenance order can be created with just the workshop and planned start and finish dates. As you continue with the planning of the order, you can add and remove events as the needs and requirements for the visit are established. When the scope is defined and ready for execution, the maintenance order can be released. At this time, a snapshot of the maintenance order can be taken to retain as a reference in terms of the initial request for the maintenance visit versus the final request.

Manage Maintenance Visit

You can assign additional events to the ongoing work scope. If events that do not have defined task cards exist, you must connect valid task cards to these events. For instance, if non routines have been discovered or condition measurements have been performed on an ongoing work scope, events may have been generated without any predefined task cards. For such events, task cards must be defined before you can proceed with the event.

Complete Maintenance Visit

When you are completing a maintenance order, you have the option of defining additional event information directly on the maintenance order. Furthermore, if sign off requirements have been defined on the maintenance order, sign off must be performed before completing the maintenance order.

Maintenance Order History

When a maintenance order has being signed off and set to the Finished status, the maintenance order becomes historical and is transferred to the maintenance order history. The following information is retained on the historical maintenance order:

General information on the maintenance order, e.g., the distribution type used to distribute the order, the workshop at which the work is to be performed, the grouping ID used to generate execution logic structures, and if the maintenance order was canceled, the cause for canceling.
Information on the events that were executed or canceled on the maintenance order.
Information on any non routine work that was discovered during execution of the scheduled maintenance and reported on the work order or work task.
Information on any sign off requirements defined on the maintenance order.
Information on any snapshots taken of the maintenance order at various stages.
Journal entries generated when key actions were performed on the maintenance order.

Maintenance Order Snapshot

The snapshots of a maintenance order will contain information of the maintenance scope throughout the planning stages up until execution. There are no restriction on when or how many snapshots can be taken. A snapshot can be taken, for instance, when releasing the maintenance order once the scope is defined and ready for execution. This snapshot can then be used as a reference in terms of the initial request for the maintenance visit as opposed to the final request.

The snapshot will contain all events included on the maintenance order as well as all task cards connected to each event.

Maintenance Order Structure Change Log

The Structure change log is used for tracking removed and installed parts, both non-serialized and serialized, when executing a work scope. Mainly tracking of removed and installed parts are generated transactions, but we can verify them and to some extent edit these logged transactions. In addition to the generated transactions, removal and installation transactions can be entered manually for a component.

On the transactions, there is a status indicating if the structure change transaction is valid at the time it is created in the log. The status can manually be changed from Valid to Invalid and an Invalid transaction can then again be removed. An Invalid transaction can manually be changed to become Valid. A duplicate transaction cannot be manually set but will be set by the application. The user can then set the status to Valid on the duplicate transaction that is the correct transaction, and the rest will remain as duplicate transactions.

From the structure change log, the actual structure change for an installed or removed transaction can be done. When selecting the Perform Structure Change option, the assistant for performing the structure change will be displayed for the selected record. The data on the record selected, will be defaulted in the assistant but may require the user to enter some additional information.

Maintenance Order Journal

The maintenance order journal is used to retain information on key changes to a maintenance order. The following changes on a maintenance order lead to the automatic creation of a journal entry:

An event is removed from the maintenance order
The grouping criteria on the maintenance is changed
The maintenance order is released

Entries created for the above-mentioned changes are sorted into four valid journal categories: Info, Mx Event Removed, Changed Grouping ID and Task Card List Modified. Additional information on the journal entry is displayed in the journal text for each record. Journal entries will be generated when the following changes take place:

When an event is removed from the maintenance order. There are several scenarios that can cause the automatic removal of an event from the maintenance order:
- When a structure change is performed on a maintenance order in the Planned In Scope, Incomplete or Under Preparation status, and events exist on the maintenance order for serials that are no longer installed in the structure of the top serial.
- When a modification is set to the Obsolete status. This applies to maintenance orders in the Initial Scope Definition and Under Preparation statuses.
- When the maintenance program is changed for a serial or a maintenance program is set to the Obsolete status. This applies to maintenance orders in the Initial Scope Definition and Under Preparation statuses.
- When the revision is changed on a serial. This applies to maintenance orders in the Initial Scope Definition and Under Preparation statuses.
- When a serial is renamed. This applies to maintenance orders in the Initial Scope Definition and Under Preparation statuses.
When the grouping criteria on the maintenance order is changed.
When the maintenance order is released.
When the task card list is modified on a maintenance event.

The content of the journal entries differs depending on the cause for their generation. They are as follows:

The journal text for when an event is removed from the maintenance order will contain information on the affected serial.
The journal text for when the grouping criteria is changed on a maintenance order will include the IDs of the new and changed grouping ID as well as the ID of the user who performed the change.
The journal text for when the maintenance order is released will contain the date the maintenance order was released as well as any information entered when releasing the maintenance order.