This history is located in IFS/Part Catalog. Changes to the serial's operational status, operational condition, and current position will create records in history. For more information, refer to the online help file: Part Serial Handling.
History records are also created when the following updates are performed for a serial in Fleet and Asset Management:
The serial is locked.
The maintenance group is changed.
The workshop code is changed.
The serial is deleted from Fleet and Asset Management.
The serial is set to be in quarantine.
The serial is removed from quarantine.
The serial is renamed with a new part number and the revision.
When the serial structure is changed, all structure changes will be recorded here as long as the status of the serial is different from the Planned for Operation status. Structure changes that can be performed on a serial structure are:
Install serial
Remove serial
Replace serial
Rob serial
Swap serial
Serial structure changes can also be recorded for changes done in the past.
In Fleet and Asset Management, when a modification of execution type Terminating Action leading to a part identity change is embodied, the serial assigned to and/or affected by the modification will be renamed automatically with the new part number and revision defined on the modification. Replacement history will be updated with the new part number and revision of the serial being renamed, if specified. You can choose to update replacement history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification.
It is possible to de-comply a modification event which is already complied with, provided that de-compliance is allowed for the assigned/affected part. If a modification event leading to a part identity change is de-complied, the renamed serial will be reversed back to its origin defined on the modification when the de-complied modification event is finished. If replacement history was updated previously with the new part number and revision, the replacement history record(s) will be updated once more to include the old part number and revision of the serial.
Note: Asynchronous reporting will not work if the replacement history is not updated with part identity change information for the serial.
Structure changes may also be recorded on a work order or on a shop order (in IFS/Complex Assembly MRO). In these cases, the reality and the registered structure in the application might not always match. If so, there will be records created in the serial structure mismatch log.
All data in the serial structure mismatch log must be handled by resolving or canceling the records. When the mismatch records are handled, they are moved to the serial structure mismatch log history.
When the vehicle condition is changed a corresponding record is created in the vehicle condition history for a vehicle. The vehicle condition can be changed automatically when the operational status of the vehicle is changed from Out of Operation to In Operation or vice versa, provided that the object properties are defined to control automatic updates. The vehicle condition can be changed manually as well. For more information on how to define object properties, refer to the online help file Verify or Adjust Default Object Properties.
Vehicle condition history data can be used to evaluate the availability of a vehicle over a period of time.
It is possible to add, correct or remove entries in the vehicle condition history. This is useful, for instance, when a vehicle condition change entry has not been logged in the system or has been logged incorrectly and the historical data needs to be corrected. Note that it is not possible to correct or remove the last entry in the vehicle condition history or to add an entry that is later in time than the last entry. This is to prevent mismatches between the current vehicle condition of a vehicle and the most recent entry in the vehicle condition history.
When a part identity change occurs on a serial as a result of a modification embodiment, the vehicle condition history will be updated with the new part number and revision of the serial, if specified. Vehicle condition history will be updated when the Update Other History check box is selected. You can choose to update vehicle condition history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When the part and/or serial number of a serial is changed, the operational status of the old serial (i.e., the serial before the rename) is set to Renamed. The new serial containing the changed part and/or serial number will receive the operational status that the old serial had prior to the rename. If however, the configuration of the serial becomes invalid as a result of the serial rename, the operational status of the new serial is automatically set to Out Of Operation. A history record will be created in the serial identification history in addition to the history record in part serial history.
If the part number and revision of the serial was changed as a result of a modification embodiment, information on the modification that has been complied with is retained in the serial identification history. This modification information can be used as a reference for the reason a part identity change was performed on the serial.
Furthermore, information describing the history data that is updated when the serial is renamed is displayed in the serial identification history.
When all the route sequences in the serial transportation route are completed, a history record is created per route sequence.
The serial transportation route is used to move a serial from one location to another. For each route sequence that is completed, the serials location will be updated. When the last route sequence completed, all rows for the defined route sequences will be copied to the serial route history. The next time the serial is to be moved to a new location with a transportation route, the same transportation route can be re-used.
When a part identity change occurs on a serial as a result of a modification embodiment, the serial route history will be updated with the new part number and revision of the serial, if specified. Serial route history will be updated when the Update Other History check box is selected. You can choose to update serial route history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
As long as the serial is in operation, all the operational parameters will get operational measures. Every time operational loggings are performed, these data will also be recorded in the operational log history.
(Operational measures can be registered in the Serial Operational Information/Operational Log tab. Historical operational loggings for used serials can be entered in the Component Life/Operational Log tab.)
Operational parameter values will also be recorded at the time an order is performed, but these measurements are stored on the work order. You have the option of querying for historical operational values to view all the records from both these histories in chronological order.
Note: The method through which the serial is used will affect the related due-calculations.
If specified, the operational log history will be updated with the new part number and/or revision of the serial being renamed. When you choose to rename a serial without updating history records, the latest operational logging on the old serial will be copied automatically to the new serial. The purpose of this feature is to provide a starting point for historical operational loggings on the new serial.
When a modification of execution type Terminating Action leading to a part identity change is embodied, the serial assigned to and/or affected by the modification will be renamed automatically with the new part number and revision defined on the modification. You can choose to update serial operational log history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
If a modification event leading to a part identity change is de-complied, the renamed serial will be reversed back to its origin defined on the modification when the de-complied modification event is finished. If operational log history was updated previously with the new part number and revision, the operational log history record(s) will be updated once more to include the old part number and revision of the serial.
Note: Asynchronous reporting will not work if the operational log history is not updated with part identity change information for the serial.
The stress rating history will record the current stress rating for the serial. Every time the current stress rating is changed, the new current stress rating will be added to the history.
If for instance a serial part was used before it was registered in the system, you have the option of entering historical stress ratings for the part. Stress rating history is used to calculate the remaining life for life limited parts.
When a part identity change occurs on a serial as a result of a modification embodiment, stress rating history will be updated with the new part number and revision of the serial, if specified. Stress rating history will be updated when the Update Other History check box is selected. You can choose to update stress rating history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When handling a work order if a fault event is reported to be finished, the fault will be moved to the fault history.
If the fault is already repaired, the fault will be moved to the fault history immediately.
If IFS/Complex Assembly MRO is installed, fault history records might also be created from the disposition shop order if the discrepancy code is connected to a fault code.
When a part identity change occurs on a serial as a result of a modification embodiment, serial fault history will be updated with the new part number and revision of the serial, if specified. Serial fault history will be updated when the Update Other History check box is selected. You can choose to update serial fault history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
All maintenance events that have been finished will be recorded here. If the event is connected to a maintenance order, the maintenance order must be finished before the event is moved to history. Note: Fault events that are already repaired are considered as finished events in history.
If the Simplified Work Order distribution type was used, the event is handled within Fleet and Asset Management. Here the workshop and resource group must be entered, along with any material that was used. A corresponding work order and work task will be created in the background, time reported and authorized, and material issued from inventory. If the Work Order distribution type was used, the event is processed using the normal work order flow in IFS/Work Order Management. Here a work order is created for each event while a work task is created for each task card and subtask included on the event. Connected data, such as, resources, material and sign off requirements will be included on the relevant work task. For more information, refer the online help file Work Order - Fleet and Asset Management. If the Execution Logic Structure distribution type was used, the work will be sorted according to predefined grouping criteria and an execution logic structure (ELS) is generated for the maintenance order. When the maintenance order is released a corresponding structure of work orders will be created containing the work tasks that need to be performed. This work is also processed using the normal work order flow, the only exception is there is a separate window (Work Order Execution Logic) that can be used when working with ELS work orders.
When the work task is finished, resources with reported time, issued material quantities, and completed sign offs are transferred back to the event (either on the maintenance order or in serial order history). The cost for resources and material will also be transferred. These costs are used to calculate the total cost for the work performed on the event. If the work task is reopened and additional changes done on it, e.g., additional time is reported on a resource, this information will be transferred back to the event once the task is finished.
The following event-related information is retained in serial order history:
General information on the event, e.g., the event code, event type, and valid serial information.
Order information, such as, the order number, costs, workshop, work order number (if any), and manufacturer information.
Operational parameter information.
Events that have been canceled to be performed later.
Information on any non routine work that was discovered and reported on the order.
Information on any sign off requirements defined on the event.
Information on the task cards connected to the event. This includes the resources, material, zones, access panels, and sign off requirements defined on the task cards.
When a part identity change occurs on a serial as a result of a modification embodiment, serial order history will be updated with the new part number and the revision of the serial, if specified. Serial order history will be updated when the Update Other History check box is selected. You can choose to update serial order history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
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 maintenance order.
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.
The snapshots of a maintenance order will contain information of the maintenance scope throughout the planning stages up until execution. There are no restrictions 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.
The entries are sorted by a valid journal category, i.e., Info, Mx Event Removed, and Changed Grouping ID, for easy viewing. Furthermore, additional information on the entry is displayed in the Journal Text field. For example, when a maintenance order is released, the journal entry will be created for category Info and the Journal Text field for the record will display the date the maintenance order was released as well as any information entered when releasing the maintenance order. Journal entries will be generated when the following changes take place:
All canceled events will be recorded here. This can be done for all running events.
When a part identity change occurs on a serial as a result of a modification embodiment, maintenance event cancellation history for the serial will be updated with the new part number and revision of the serial, if specified. The maintenance event cancellation history will be updated when the Update Other History check box is selected. You can choose to update serial order history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When a maintenance event is finished, the maintenance event will be inserted in the serial interval maintenance history.
When a part identity change occurs on a serial as a result of a modification embodiment, serial interval maintenance history will be updated with the new part number and revision of the serial, if specified. Serial interval maintenance history will be updated when the Update Other History check box is selected. You can choose to update serial interval maintenance history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When a condition monitoring is performed on a serial, each monitoring will be logged in the condition measurement history. If the monitoring resulted in the creation of a pending event, the event number will also be visible.
When a part identity change occurs on a serial as a result of a modification embodiment, condition measurement history will be updated with the new part number and revision of the serial, if specified. Condition measurement history will be updated when the Update Other History check box is selected. You can choose to update condition measurement history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When a modification event is finished, the modification event will be inserted in the serial modification history. All execution types (Initial Inspections, Continued inspections, Terminating Action) will create a serial modification history.
This history may be used to determine whether a modification is complied with or not. The modification is complied with when the terminating action is performed. You can also de-comply the previously complied modification if necessary. As a result of this, a pending event is automatically created for the de-complied modification.
If IFS/Complex Assembly MRO is installed, serial modification history and serial modification affected part history will be generated when you sign of an event, provided that all conditions have been are fulfilled. These condition are displayed below (Serial Modification Affected Part History).
When a part identity change occurs on a serial as a result of a modification embodiment, serial modification history will be updated with the new part number and revision of the serial, if specified. Serial modification history will be updated when the Update Other History check box is selected. You can choose to update serial modification history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
When a modification event is finished, the corresponding serial modification affected part history record is generated if the following conditions are fulfilled:
the modification execution type is Terminating Action.
the affected part is defined is signed of and set to Affected Serial marked as complied with.
When a part identity change occurs on a serial as a result of a modification embodiment, serial modification affected part history will be updated with the new part number and revision of the serial, if specified. Serial modification affected part history will be updated when the Update Other History check box is selected. You can choose to update serial modification affected part history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
Operational events will be moved to the operational planning history by a batch job running every night. The criteria for the events to be moved, is the given number of days after the planned finish date. The number of days delay is defined in the Configuration Basic Data/Object Property tab or the System Definitions/Object Property tab. For more information, refer the online help files Verify or Adjust Default Object Properties and Adjust and Verify Background Job For Remove Old Operational Events.
You have the option of removing redundant history records from the operational planning history.
When a part identity change occurs on a serial as a result of a modification embodiment, operational planning history will be updated with the new part number and revision of the serial, if specified. Operational planning history will be updated when the Update Other History check box is selected. You can choose to update operational planning history when finishing a modification event (i.e., through the embodiment of the modification) that leads to a part identity change on the serials assigned to and/or affected by the modification. If the de-compliance of a modification leading to a part identity change is performed, the previously updated history record will be updated once more when the de-complied modification is finished and will include the old part number and revision of the serial.
Historical information on closed and voided flight logs will be retained in the system in order to facilitate follow up and analysis of events. For instance, a pilot can follow up on what has been done to an aircraft prior to flying it or a flight line mechanic can identify if similar problems have occurred before on a specific aircraft or any other aircrafts.
For a period of time it can be important information to view voided and closed flight logs together with open logs for a vehicle. In basic data, you have the option of defining the number of days these records are to remain in the Flight Log window. This is defined by entering the required number of days against a specific owner organization in the Hist. Flight Logs After No Of Days field in the Flight Log Basic Data/Operator Information window. Once the number of days is reached, voided and closed flight logs associated with the given owner organization will be moved to history through a background job. If a value is not given in basic data, 0 (zero) becomes the default value and the relevant flight logs will be moved to history as soon as the background job is executed.
In the flight log history, detail data such as operational loggings on a flight, crew information, reported faults and actions taken can be viewed on the flight log for a vehicle.