This history is located in IFS/Part Catalog. All status changes on a serial, will create records in this history. The valid statuses are: Operational Status, Operational Condition, Current Position and Lock. 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 IFS/VIM (IFS/Vehicle Information Management):
The maintenance group is changed.
The workshop code is changed.
The serial is deleted from IFS/VIM.
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 IFS/VIM, 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 task (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 task which is already complied with, provided that de-compliance is allowed for the assigned/affected part. If a modification task 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 task 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.
Every time the Vehicle Condition is changed, a history record is created. Vehicle conditions can be changed manually. The vehicle condition can be changed automatically when the operational status is changed from Out Of Operation to In Operation status, or In Operation to Out Of Operation, provided that the object properties are defined to control automatic updates. For more information on how to define object properties, refer to the online help file Verify or Adjust Default Object Properties.
These data can be used to evaluate how long the vehicle has been available.
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 task (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 in IFS/VIM. 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 task (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 task (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 task 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 task 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 task (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 task 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 task (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 finished tasks will be recorded here. If you use the distribution type Simplified Work Order when distributing the task, the task must be handled in the Maintenance Order/Included Tasks window. If the distribution type is Work Order, the task must be processed through the ordinary work order in IFS/Work Order Management. For more information, refer to the online help file Work Orders for VIM Serials. If the distribution type is Execution Logic Structure, the task must be processed through the Work Order Execution Logic window in IFS/Work Order Management. When the status of the maintenance order is set to Finished, records will be created in the serial order history. Note: Fault tasks that are already repaired are considered as finished tasks in history.
The following information is retained on a serial order history entry:
General information on the task, e.g., the task code, task type, the workshop at which the task is executed and valid serial information.
Order information, such as, the order number, cost, work order number (if any) and manufacturer information.
Operational parameter information.
Tasks that have been cancelled 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 task.
Information on the operations (instructions or subtasks) connected to the task. Further information on the materials, tools and facilities, zones, access panels and signature requirements defined on the operations (instruction or subtask) is displayed.
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 task (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 cancelled, the cause for canceling.
Information on the tasks that were executed or cancelled 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 tasks included on the maintenance order as well as all instructions (task cards) connected to each task.
The entries are sorted by a valid journal category, i.e., Info, Task 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 cancelled tasks will be recorded here. This can be done for all running tasks.
When a part identity change occurs on a serial as a result of a modification embodiment, task cancellation history for the serial will be updated with the new part number and revision of the serial, if specified. Task 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 task (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 task is finished, the maintenance task 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 task (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 task, the task 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 task (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 task is finished, the modification task 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 task 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 a task, 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 task (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 task 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 task (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 task (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 tasks. 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.