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.
The replacement history can be used to view all serial replacements that have been performed. Two history transactions are recorded. One for serials being disconnected and another for serials being connected.
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.
Note: Non-serialized parts that have been installed into or removed from a serial structure will also exist in the replacement history.
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.
The structure mismatch log history can be used to view resolved or canceled mismatches that exist between a physical structure and a system defined structure.
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 option is enabled. 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 option is enabled. 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 Report Operational Logging page. Historical operational loggings for used serials can be entered in the operational logging tabs found in the Serial Initialization page.)
The Overhaul Performed and Repair Performed options will be selected for loggings that are generated when an overhaul (cycle) is performed on the serial, when the Value After Repair is reset for the serial or when the Reset Value After Overhaul and Repair command is executed in a CAMRO (IFS/Complex Assembly MRO) work flow. If both options are selected, either an overhaul (cycle) has been performed or the Value After Overhaul and Value After Repair was reset as part of a CAMRO work flow. If only the Repair Performed option is selected, either the Value After Repair was reset from a maintenance event or it was reset as part of a CAMRO work flow. These options will be selected based on following criteria:
Overhaul Performed - Add On Value = 0 or NULL, Value After Overhaul = 0, Measure Remark is not NULL
Repair Performed - Add On Value = 0 or NULL, Value After Repair = 0, Measure Remark is not NULL
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 option is enabled. 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.
For more information on the life limit concept, refer the online help file Life Limits Concept in IFS Fleet and Asset Management.
When a fault is completed (maintenance event is finished) it will be moved to the history. If the fault is already repaired, the fault will be moved to the fault history immediately. In history, information such as the person responsible for reporting the fault, the structure of the serial for which the fault was reported, fault deferral information, connected post maintenance checks, connected operational plans, function breakdown (entered when reporting the fault and repairing the fault), actions taken to repair the fault, and additional information on faults registered for non-serialized parts will be retained.
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 option is enabled. 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.
Information on 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 page (Work Order Structure) 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, workshop, work order number (if any), manufacturer information, total cost for performing the work (i.e., the accumulated cost of resources and material utilized for the work) shown both in the currency used on the work order and the currency used in Fleet and Asset Management.
Operational parameter values. Operational parameter values can arise as a result of a maintenance event or work order been completed. These values are given, or will be the last historical values closest to the date the event was performed. If needed, it is possible to change the operational parameter value reported when an event or work order was completed.
Events that have been canceled to be performed later.
Information on any non routine work that was discovered and reported on the order. Non routines are the faults that are discovered during the inspection phase of a visit. These faults are reported on the work order or work task on which it was discovered. When a fault is reported, a fault event is created automatically for it and added to the current work package (maintenance order) of the visit.
Information on any sign off requirements defined on the event.
Information on the task cards connected to the event. This includes the subtasks, resources, material, zones, access panels, and sign off requirements defined on the task cards. To view information on the master event to which this task card or subtask is connected, click View Master Maintenance Event. This command will only be enabled for task cards with the duplicate type Duplicate, and where the master event is different to the duplicate event. See below sub sections for more information on resource and material handling for 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 option is enabled. 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.
In the serial order history, you can view information on the resources for which time was reported (either on the corresponding work task or when performing quick reporting on an event). When the work task or maintenance order is finished, resources with reported time and costs will be transferred back to the maintenance order/history. If there are additional resource demands for which time has been reported, this information will also be transferred. Reported time and cost is summarized per resource group and task card or subtask. 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 once the work task is finished.
Planned quantities and hours will be shown for resources from the task library (task card or subtask). Planned values will not be shown for any additional resources that have been reported in on the work task. This makes it easier to analyze actual utilization against planned resource requirements. The following table describes how resources are transferred to the serial order history when the work task or maintenance order is finished:
| Action | Transferred to Serial Order History |
| Time has been reported on a transferred resource demand (i.e., from the maintenance order) | The corresponding resource demand line in serial order history will be updated with accumulated reported hours and costs. |
| A resource demand has been added to the work task and time reported | A new resource demand line will be added to the serial order history with accumulated reported hours and cost. If a demand already exists for the resource ID, this demand line will be updated with accumulated reported hours and costs. |
| A transferred resource demand has been removed from the work task | The original resource demand line will remain in serial order history with 0 reported hours and cost. |
In the serial order history, you can view information on the utilized material (either on the corresponding work task or when performing quick reporting on an event). When the work task or maintenance order is finished, issued material quantities and costs will be transferred back to the maintenance order/history. If there are additional material that have been issued on the work task, this information will also be transferred. If the work task is reopened and additional changes done on it, e.g., additional material is issued, this information will be transferred back once the work task is finished.
Planned quantities will be shown for material from the task library (task card or subtask). Planned values will not be shown for any additional material that have been issued on the work task. This makes it easier to analyze actual utilization against planned material requirements. The following table describes how material is transferred to the serial order history when the work task or maintenance order is finished:
| Action | Transferred to Maintenance Order (or Serial Order History) |
| Material is issued against a transferred material demand (i.e., from the maintenance order) | The corresponding material demand line in serial order history will be updated with issued quantity and cost. |
| A material demand has been added to the work task and issued | A new material demand line will be added to the serial order history with issued quantity and cost. |
| A transferred material demand has been removed from the work task | The original material demand line will remain in serial order history with 0 issued quantity and cost. |
| Ownership of a transferred material demand is changed on the work task and issues are done against the material with the new ownership. | Ownership will be updated on the original material demand line along with the issued quantity and cost. |
If the serial's unit of measure (UoM) is different to the UoM of the site at which the work was executed, automatic UoM conversions is performed when a maintenance event (with material demands) is distributed and when issued material is reported back to the event. You can use this tab to view the utilized quantities in accordance with the UoM on the different sites.
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 option is enabled. 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.
This historical data can be used to view the history of completed interval maintenance.
When a maintenance event is finished, the maintenance event will be inserted in the serial interval maintenance history.
If the interval maintenance event has been changed, this information is also stored in the history. The changes may have been performed when changing or resetting interval maintenance from the Serial Maintenance/Interval Maintenance tab.
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 option is enabled. 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, including those that led to maintenance events and those that were within the stated limits. If the monitoring resulted in the creation of a pending event, the event number will be displayed.
Analyzing the history of the completed condition measurements can help you to pinpoint production errors or weaknesses.
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 option is enabled. 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 option is enabled. 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.
To create a pending maintenance event for the decompliance of a previously performed modification, click Create Maintenance Event for Decompliance on the record.
The serial modification affected part history can be used to view serials affect by the modification that was performed. 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 or a decomply is performed on a serial
Serials are listed as affected parts on the modification and the Signoff field for the affected part is set to Affected Serial marked as complied with.
The Origin field displays how the history record was created. If the value is Ordinary Logging, there will always be a corresponding record for the assigned part in the Serial Modification History page with the same maintenance event number. If the value of the field is Component Life, there can be a corresponding record for the assigned part in the Serial Modification History page with the same maintenance event number. But not necessarily; it depends on whether the information about the assigned part was provided when originally entering the affected part in the Serial Initialization/Modification Affected Serials tab.
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 option is enabled. 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 Object Properties page. 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 option is enabled. 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 page. 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 Operator Information page. 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.
Following detail data can be viewed in the flight log history:
Operational loggings on a flight.
Disruptions, such as, deviations or cancellations that occurred during a flight.
Crew information, including the different operational tasks performed by each crew member and also how the time for each crew member was split between the different types of crew time for the flight.
Reported faults and any actions taken to remedy a fault.
Condition measurements recorded on the flight log.
Pre- and post- flight activities that were performed on a specific flight or on the flight log.
Flight that have been moved from or moved to the flight log.
Changes performed on a flight log when amended (can be viewed in the journal).
Affected Serials on Historical Modifications
Changed Interval Maintenance History List
Condition Measurement History List
Fault History List
Flight Log History
Flight Log History List
History per Serial
Interval Maintenance History List
Maintenance Event Cancellation History List
Maintenance Order History
Operational Planning History List
Post Maintenance Check History List
Serial Identification History
Serial Information
Serial Modification History
Serial Modification History List
Serial Operational Log History List
Serial Order History
Serial Order History List
Serial Route History
Serial Structure Mismatch History
Stress Rating History
Task Cards for Serial Order History
Vehicle Condition History
Vehicle Condition History List