MRO acquisition is introduced on the purchase order and customer order to enable the handling of the material flow for a customer owned top object that should be repaired/overhauled in a MRO scenario.
The receipt of the object is performed on a purchase order and the shipping of the object is performed on a customer order. To distinguish these types of order lines a new supply/demand code is introduced, Maintenance, Repair and Overhaul (MRO).
In all MRO scenarios a work order is used just like in service management. One difference between some MRO scenarios and service management is that in a service management scenario the actual work is performed “in-the-field”. That means that the work is performed were the object is situated. In some MRO scenarios the object is sent to the “repair site” and when the repair/overhaul is finished it is sent back (se picture below).
The functionality developed to support the above flow is that it is possible from the work order (or from a wizard) to create a MRO Object Receive Order. A new client is developed to handle these orders and to enable registry of miscellaneous parts. The miscellaneous parts are for example packaging material, accessories, tools etc. that not should be received into inventory. It may be important though to send the miscellaneous parts back with the repaired/overhauled object. The receipt of the object is an ordinary receipt of a serial handled part.
When the repair is finished, creation and reservation of a customer order line is manually triggered from the work order and the shipping of the object is initiated.
The customer in this context is always an external customer. It is not possible to create orders for receiving or shipping a MRO object for a customer belonging to the same site as the order site.
For internal orders the MRO object may be handled by moving them between sites with for example a transport task.
To enable receipt of the MRO object the customer has to be defined as a supplier and vice versa (Supplier/Purchase tab).
The MRO object is any type of object possible to handle on a work order. This means that a MRO object is either a VIM object or an Equipment object.
A MRO receive order is technically a purchase order containing a purchase order line with demand code MRO. This type of order is used for receiving the MRO object into inventory. To get the MRO object into inventory, it is a prerequisite that the object exist on either a MRO Work Order or a Component Repair Order.
The specific characteristics for a MRO purchase order line are;
To be able to handle the same MRO object several times it is allowed for a MRO purchase order line to be received even though the serial number has been used before on this site. The condition is that the part serial object has current position InFacility or Issued.
When a new IFS/Vehicle Information Management or Equipment object is created it typically gets the current position InFacility. When a MRO object is delivered to the customer it gets the current position Issued.
When receiving the MRO object the receipt is just like an ordinary receipt of a serial handled part. The difference is that the serial no is defined in advance and can’t be changed at receipt.
When receiving the MRO object it is quite common that some miscellaneous parts has to be registered as well. The miscellaneous parts are things delivered with the object but not needed in the actual repair/overhaul. Typically this is package material, racks etc. By registering these as miscellaneous parts an appendix is written for the;
When receiving a MRO object into inventory the current position is set to InInventory, operational condition is set to Non Operational and operational status is set to Out of Operation. This is to reflect the state of the object. The operational condition and operational status might already have these values at receipt. Operational condition is used to keep track of if the repair/overhaul of the object has been performed successfully and approved from a QA perspective.
The main difference between different types of MRO scenarios is how the actual repair/overhaul is performed. This is left out of this document. The common thing for all MRO scenarios is that a work order is used. When the MRO object is considered to be finished in the repair process and everything is ready for the object to be shipped back to the customer this is initiated from the work order.
If the repair/overhaul was successful and approved the object is set to Operational. This is supposed to be the main flow. By using action Return Object the ship back process is initiated.
If the object isn’t Operational there is another action for this type of ship back. The idea is to keep a quite restrictive security on the later function.
The customer order is used for shipping back the customer owned object. The connection between work order and customer order might be created in a number of ways.
The specific characteristics for a MRO customer order line are;
After the reservation step the only thing that differs from an ordinary customer order line is that appendixes for miscellaneous part are created for the pick list and the delivery note.