PSA utilized the Flight Disruption functionality for a little over two years. In most cases, the functionality performed as intended where a technician or controller would link a fault to a flight disruption and add details. However, issues arose when there were tail swaps following the disruption or when there was no maintenance action documented as part of the disruption. When those occurred, there was no way to accurately tie the original disruption to the correct aircraft. As a result, PSA recently created a workflow outside of Maintenix to overcome the shortfall. 

Thank you for the quick and detailed response.  You described one of the items we were hoping to understand.  Thanks again!

Hi Zachary and Sean,

I have some good news for you both. The product limitation with tail swaps on flights disruptions was resolved in 8.3-SP6, under the tracking number OPER-43494, and MXC-I-815 through the Enhancement Request process.

In 8.3-SP4 the ability to delete a flight disruption was added to the product.

Assigned to developer right now as part of ongoing maintenance of this feature, we have two fixes planned for the flight disruption search page, which I anticipate will be part of the 8.3-SP9 release.

Thank you Robert, that is good news and rather timely from our perspective.  Appreciate the update.  

@Robert Bellemare fixes for the  ‘search page’ or ‘create disruption page’?

ie /web/flightdisruption/CreateEditFlightDisruption.jsp

Just checking as Qantas requested that ‘Maintenance Event’ be changed to barcode. hoping thats ones still there, its the only clunky part of the process if the disruption is raised manually after.

Also, was SP4 the version that added the Disruptions tab against the flight. Great new featur..

Qantas have used the flight disruption feature for some time, using only mx we streamlined another process, developed a few reports and were able to remove the need for entire system and its database.

Sorry Bobby, I definitely mentioned the correct page. One fix is related to searching by aircraft, it needs to be adapted to use the new data model elements used to fix the aircraft swap workflow.

The second fix is for the delay code showing the character set code instead of special characters as they should appear.

An issue that may be related was an error in assigning a maintenance event to a flight disruption. We solved this problem in 8.3-SP2 as part of a larger effort on the Search by Type pages. Your upgrade should give you relief in this area. Are you speaking purely from the perspective of relabeling the field? There are always options to address this using the i18n feature. I believe you may still maintain a customization in this area.

The file is lbl_en_US.properties in the maintenix/web area: web.lbl.MAINTENANCE_EVENT. Your IT department should be able to add this to the scope of modifications.

Thanks Rob, sorry I did not mean relabeling. This was an actual GUI change on /maintenix/web/flightdisruption/CreateEditFlightDisruption.jsp

Maintenance Event: asks for task name + has the option to pass off to /maintenix/web/task/TaskSearchByType.jsp

Suggest a concesus from other operators that this field would be best changed to enter the task barcode for the Maintenance event, refer sample .jsp example

Thanks again for the response and support. We do need to catch up for that beer when you’re in syd next!

Icelandair is on similar place like PSA is mentioning, currently it’s maintained in in-house solution.

We do get Flights and Disruptions via the Flight API, but we’re having hard time connecting Faults to Flights were we normally create a Turn Check and if it have technical delay we think the right way is to create it from the Turn Check WO, but when doing that Maintenix doesn’t allow the user to link the Fault to a flight, it default set to “Found During Check”, so even we do integrate disruption against the flight we can’t link the Fault. Only if the Fault is created outside of the WO and then manually linked to WO. This is simply too many steps in our opinion, would be nice to hear how Quantas solved the linking between flight and fault.

In our operation AMT is not the person who decide if the delay is technical or not or it’s duration, that’s a committee in NCC (NOC, OCC) and when decision is made the information to Maintenix are fed via Flight API.

Icelandair is currently on 8.3-SP7 stream.