 |
       |
||
|
|
|
 |
|
|
|
||||||||||||||||||||||||||||||
|
Messaging System |
||||||||||||||||||||||||||||||
|
Observing the existing communications regarding requests for new or changed flight operations one can easily notice the flow from the sales department towards the commercial planning and then further to operations department. The actual channels and media of communications may vary from company to company.
This process is very important since any 'noise' in the channel can result in misinterpreted information which can further lead to huge problems in final operations. Later investigations may show that some departments did not receive the corresponding flight notification or that the delivery was too late. Our solution prevents such problems and introduces advanced messaging system that guarantees integrity of information, synchronizes all participants and obtains prompt delivery as well as confirmation of receipt. All this is combined with advanced tools used for the creation of requests and an archive that keeps the history track of all related events. User Groups The users are divided into three groups: initiators, coordinators and recipients. Each group uses a slightly different version of application that is adjusted to their needs. Initiators represent the origin of all requests. They prepare a detailed specification of all flights and changes thereof and send it to coordinators. Coordinators check the incoming requests and perform several activities to place changes into schedules. If that is not possible, they reject the request which is then returned to its origin with a description of the problem or a suggestion of alternate solution. When the process of request adjustment is completed the coordinators forward the request to recipients. After recipients get this notification, a confirmation is sent back to all participants including the name of the recipient and his department together with the date and exact time when the message was opened. Tree views The received requests are gathered in the Archive view in a tree form. They are organized by dates and equipped with items that specify the proposed changes. The symbols that are attached to these items reflect their current status. The Links view displays a tree of all requests that were processed for the selected item in the past. The History view describes all events in a lifecycle of the selected request, from its creation, eventual rejection or forwarding and the final confirmation of its last recipient. Events are detailed with names and times. The Edit view is divided into several subviews designed to specify the proposed request and its items. Edit view The Edit view is divided into several subviews designed to specify the proposed request and its items. Two dialogs are designed to input the description of required changes in operations. The header dialog specifies basic properties of the request and additional data that is necessary when declaring a charter operation. This data is later used by the system to generate a corresponding traffic rights request. The items dialog is used to input the specification of the required changes on a leg level. The dialog is composed of two segments that represent the current (Before) and the future (After) state of the operation. If the top segment is empty and the bottom one filled, then the user is introducing new operation. If the situation is reversed, the user requests a deletion of existing operation. When both segments are filled, only some changes regarding times, frequency or equipment of the existing operation are expected. After the system checks the proposed changes it automatically generates the necessary standardized SSIM messages that are to be sent in order to request approval from the corresponding airport authorities. Requester Agent In order to be automatically alarmed of incoming flight notification messages, members of the Recipients group can have a special Requester Agent application installed. It enables a sound alarm and adequate response even when the main Requester application is not active. Requests can also be displayed and printed in a classical form to suit the eventual usage of paper archive.  |
|
|||||||||||||||||||||||||||||
