The Table Services Flights -> Flights
This table shows a list of flights and the basic data required for service recording. The individual contracts and services related to a flight are listed in the additional dependent tables of the module. These are described in the following chapters.
Under Services Flights, a Flight Event is defined as an incident for which one or more services are rendered – e.g. handling of a flight.
All flight events are automatically imported from the flight plan database. This includes the basic data shown in the list below. Normally, the complete handling of an aircraft from its arrival to its departure is subsumed in one Flight Event . This allows covering the complete handling in one event and with one contract. As default, the leading flight "leg" is the departure, i.e. only the departure is listed in the table Flights. Nevertheless, it might become necessary to split the rotation of arrival and departure of an aircraft, e.g. if the aircraft stays for a longer maintenance period and the arrival handling has to be billed etc. These cases can be solved by appropriate contract design etc.
Most of the basic flight data cannot be edited under Services Flights because it is recorded in the flight scheduling module. An important exception to this is the State* of the event, which is of central significance for the service recording and invoicing procedures. The State* is used to define the status of service recording and invoicing for an event.
Important: When searching and listing flight events in the table, you should use the available filter functions – especially the date filter. Otherwise you might load thousands of flights from the database. To prevent this, the current date is used as default filter in the Search panel.
Following data is displayed for events under Services Flights:
|
Only displayed if you are logged-in under the holding, this field shows at which airport station the flight takes place. |
|
An automatically assigned identification marker uniquely defining an event for software processing. |
|
Internal ID of the rotation |
|
Marker that shows if the flight is an arrival (A) or a departure (D) |
|
Flight number |
|
Available for flight events only, the scheduled time for the flight is displayed here |
|
Owner is taken over from the fields Airline A/D in the module Flights |
|
Registration of aircraft of the flight event |
|
Aircraft type used in a flight event. Aircraft types are defined in the master data module Flights. In addition to your individual type definition, the variants for IATA and ICAO are also listed in the corresponding fields if available. |
|
Service Type Code also called Flight Type. Attribute of the flight provided by the external system or set manually in module Flights. |
|
Handling type of the flight. Handling types are defined in the master data module Fis and assigned to flights in the flight scheduling module. |
|
Ready flag as set in module Flights |
|
On-Block (Arrival) respectively Off-Block date and time (Departure) of a flight |
|
For flight events, the actual time the event took place |
|
Depending on the status of the service recording, a specific status definition is selected from this pull-down menu. This is one of the central functions of the table Events (see following chapter). |
|
If a contract has been automatically assigned to an event, the contract name is displayed here. In case more than one contract is assigned, the total number of contracts is shown. Details about contracts can be accessed in the table Flight Events > Contracts. |
|
For all flights which have at least been calculated (button |
|
Only available in the Search panel. Checkbox to show if there are open charges to one of the registered services or not. |
|
Software automatically shows the invoice recipient who is defined in a handling contract which is assigned to a flight event. If no contract is assigned or an assigned contract does not include an invoice recipient, the software enters the aircraft owner here. Note that it is possible to manually change the recipient in the pull-down menu Capt. Rec. If no recipient is stated in the contract or no aircraft owner can be identified, this field remains empty. |
|
Manually change the invoice recipient if necessary, or enter a recipient if no invoice recipient could be identified from a handling contract or aircraft. Manually entered recipients always have priority over automatically identified recipients. Note that invoice recipients available here for selection are defined in the master data table Customer of the master data module Contract. |
|
The current invoice recipient is derived from the field Calc. Recipient unless a manually set Capt. Recipient exists. |
|
Previous (for arrivals) or next (for departures) airport of the flight |
|
If a flight has been cancelled, the cancellation time and date is displayed here. Cancellations are recorded in the flight scheduling module and only displayed here. Note that although no services are provided for cancelled flight, there might be price condfigurations which define that even for cancelled flights a part of the handling contract price has to be paid. Thus, even cancelled flights have to be taken into account for service recording and price calculation. |
|
Customer is liable to pay cash or is billed in the general invoicing procedure. This definition is set for each customer in the table Customer > Financial Profile, master data module Contracts. Note that this mark must be available in order for a cash bill to be printed! If you have to create a cash invoice for an airline which is not marked as cash-paying, you first have to change the setting in the master data. |
|
If this flag is set, the corresponding billing events get highlighted similar to the color of the cash payers. |
|
Flag indicating whether the cash hotrun was already done for this flight event |
|
Date to be printed out on the invoice. If no invoice date is entered manually, the system will use the date on which the invoice is actually created (hotrun) as default |
|
In this pull-down menu the payment option for a cash payment can be selected, i.e. cash, a variety of credit cards etc. The options available here can be defined in the table Mode of Payment in the master data module BILLING. |
|
If the flight is part of a rotation, the flight number of the partner flight leg |
|
Checkbox to show if there are open discrepancies to one of the registered services or not. |
|
Internal (handling company) status of a discrepancy: May be Closed or In Progress. |
|
Airline status of a discrepancy. This status can only be set by the airline/customer via the Airline Web Portal. Two possibilities: Approved or Rejected. |
|
Freely definable comment concerning the event can be entered here. Note that this remark will be issued on invoicing documents according to the invoice template settings! |
|
The flag is set automatically by the system whenever an error occurs during the automatic price calculation procedure. In this case, the error is listed in the field Remark Calculation. |
|
If an error occurs during the price calculation for an event, corresponding information is entered here and the data records are marked with a bright red background colour. Errors covered with this automated plausibility check include missing contract price configurations, lacking master data for services etc. |
|
Care of (c/o) of cash payer (for invoice) |
|
Name of cash payer (for invoice) |
|
Street or P.O. Box of cash payer (for invoice) |
|
Zip code of the cash payer (for invoice) |
|
City of cash payer (for invoice) |
|
Country of cash payer (for invoice) |
|
Delay of the flight in minutes |
|
Delay of the rotation in minutes |
|
If this flag is set to active, a credit customer is handled as a cash payer. |
|
Date and time when the data record was changed last (filled automatically) |
|
Name of the last user who changed the data record (filled automatically) |
|
Set CLC-flag to mark that Load Control is done by the carrier. The default of the flag is "false". For some airlines the basic handling rate depends on who does the load control. Usually, this is done by the handling company, but in case it is done by the carrier a reduced basic handling rate applies. |
|
Flag that is automatically set if a primary service with a quantity greater 0 has no associated service (with quantity greater 0). |
|
Each of the checked primary services of the flight event with their quantity and the associated service with its quantity is listed here (one line per service, multiline text field in edit panel). |
|
Remarks for the billing officer in the backoffice can be entered in the MSR. These remarks will be shown here. |
|
It is possible to override the default cash invoice contact by selecting a Cash Payer Contact Person. Only users with the Billing flag set can be selected, just like for the invoice cycle Contact Person. |
Important:
A Flight Event is highlighted in red when the system cannot calculate it for any reasons (e.g. missing data like Handling Type that is relevant for the calculation).
A Flight Event is highlighted in orange when the invoice recipient is a cash payer (see checkbox Rec.Cash).
A Flight Event is highlighted in pink when it has open discrepancies (see checkbox Has Open Discr.).
A Flight Event with Service Dependency Warning (no SDN exists or the SDN has not been signed) is highlighted in purple .
A Flight is highlighted in yellow when it has been modified.
A Flight Event is highlighted in purple when it is has been cancelled.
The State of a Flight Event
The State* assigned to a flight event under Services Flights does not only serve informational purposes. It is also used to allow or restrict access to the event and the services.
The following figure summarizes all different States* as well as the processes and operative activities involved:
Diagram of event States under Service*
Important: Note that the event State* is something completely different than individual service states!
Please note that some of the chronological steps in service recording can be set back to previous stages. The following points reflect a recommended workflow optimally using the State* features. Depending on your individual procedures, this can be freely modified in most steps:
The state Open is the first a Flight Event gets automatically assigned per default.
In the State* ' Service ', the recording and editing of services is possible. Note that with use of the optional module MSR, the operative services might already have been recorded with mobile data devices on the apron. Thus, Service is mainly used to record non-operational services, and to perform the commercial preparation of the contracts and services for the invoicing under Billing.
After all services for an event have been recorded, the financial processing can be started. In this step, prices are checked and calculated, preparing the event for the billing process. After checking the services and their prices, the button Calculate charges
is used to finally calculate all prices (please note that an automated process for this is also available, see chapter Ready flag and automatic calculation). Once this process is finished, the button
can be used again to set the State* from ' Service ' to ' Invoicing '. Important: In contrast to other mostly informational State* assignments, the State* ' Invoicing ' has an immediate consequence for the software process! Events with the State* ' Invoicing ' are automatically taken into account in invoicing processes started in the software module Billing. Once an event has been included in such an invoice run, it cannot be simply modified any longer because both the invoicing documents and the financial accounting data have been finally created!After an event has been part of an invoice run (completely or partially) under Billing, it keeps the State* " Invoiced ". In this State*, normal editing for invoiced services is no longer possible. In this respect, it is important to note that an event which has already been part of an invoicing process might have services which have and services which have not been invoiced. This can result from the settings which have been used for the invoicing procedure in Billing: it is not only possible to create invoices based on complete events, but also to create invoices for specific selections of services only (e.g. to invoice only ramp or passenger services etc.). This means, that only a part of the services included in a contract might have been invoiced in an invoice run. You can discern invoiced and non-invoiced services from their Charge State : already invoiced services have the Charge State 'Invoiced' while non-invoiced services are assigned 'Calculated'.
Before any changes to the services of an event which has been part of an invoice run can be made, the State* of the event (not of any service!) has to be set back to 'Calculated' by clicking the button
. After this, you can switch to the dependent table where you want to edit a service. Services which have not yet been invoiced ( Charge State 'Calculated') can still be changed as usual. Note that any changes here will automatically set back the event State* to 'Service'. The only way to correct services which have already been invoiced erroneously ( Charge State 'Invoiced') is the use of the Credit/Debit processes which is described in detail in chapter Credit and Debit Processes.
Note that after the changes have been made, the event has to be calculated and set to the State* 'Invoicing' again!
Important: Note that the event State* is something completely different than individual service states!
Service Categories
Services are subdivided into three different categories:
Standard contract services: Services included in a handling contract which are always performed/made available and automatically accounted for.
Additional contract services: Services which are included or partially included in a contract, but which are only performed upon special request by the customer.
Special services: Extra services not included in a contract, which are performed or made available for a customer.
Chaining of flights with already captured services
In case two flight legs with already captured services for each leg are chained, the system behaves as follows:
The contract services of the trailing leg are transferred to the services of the leading leg, i.e. after chaining, two charges are listed in Flight Events → Additional Services: one of the leading leg and one of the trailing leg.
Please consider: Chaining of flights is only possible for flights having the same contract.
Recording of Additional Contract Services
In addition to standard services, contracts can also contain optional services which are only provided if explicitly requested by a customer in specific situations (e.g. de-icing of an aircraft). These optional services are usually included at special rates and conditions.
All optional services are listed in the table Events → Contract Items, where they can be recorded and edited. As default, the Captured Amount of service units provided is listed is "zero", i.e. the service is listed as not provided. If an optional service is rendered, the actual Captured Amount is entered. The price for all optional services is calculated automatically according to the parameters defined in the contract.
Recording of Special Services
Services not included but requested by and provided for the customer can also be recorded. These are called special services in Services Flights. Before a special service can be recorded, make sure the corresponding event is marked in the table Events and switch to the table Events → Special Services. Here, you can add data records for all special services. Services of this category are calculated in accordance with the standard price catalogue.
Calculation of the Total Price
After all services provided for an event have been recorded, the button Calculate Charges 
has to be clicked in order to initiate the final price calculation required to prepare an event for the invoicing process. In this process, the prices of all individual services are calculated with reference to contractual parameters and price formulas (note that prices can vary depending of a variety of circumstances).
Only after this process has been run, an event may be assigned the State* " Invoicing ".
Important: Whenever an event which has been calculated is modified or edited thereafter, the calculation process has to be performed again!
Automatic calculation
On demand it is possible to enable the automatic calculation.
Please note that you can prevent the automatic calculation process from calculating an event by marking the Blocked checkbox. After marking this checkbox, the event is not taken into account for automatic calculating purposes until you remove the mark again.
Important: Note that on demand the automatic calculation can be configured that it automatises all calculation processes during the night.
Ready flag and automatic calculation
Before the final commercial processing of events and the services provided for them can be started, that the following aspects have to be ensured:
all necessary flight data is properly recorded for the price calculation
the operative services have been recorded under Msr (if this optional module is used). Only after this is ensured, the calculation and invoicing can continue.
Thus, the Ready checkbox has been included for flight data records in the module Flights which is used to mark flight events as fully recorded for further commercial processing. This checkbox can only be marked after mandatory flight data has been recorded and the module Msr has been executed for the corresponding flight.
After the Ready flag has been set in the flight scheduling Flights, the event State* under Service is automatically set to 'Service'. From then on, the event and its contracts and services will be included in an automated price calculation process which runs in the background. This process calculates all prices for the applicable contracts and services. Once an event has thus been calculated, its State* is automatically changed to 'Calculated'. In this state, it is no longer taken into account for the automated calculation processes, unless you change/edit anything about the contracts/services for the event.
If you access a 'Calculated' event again to ad/edit contracts and services, it is automatically returned to the State* 'Service' as soon as you make the first change to the data.
Please note that you can prevent the automatic calculation process from calculating an event by marking the Blocked checkbox. After marking this checkbox, the event is not taken into account for automatic calculating purposes until you remove the mark again.
Credit and Debit Processes
In addition to the recording and calculation of events and their services, ServicesFlights also offers functions for the handling of credits and debits.
After an event has been finally invoiced under Billing – i.e. the invoices have been created and sent to the customer, and the data has been forwarded to a financial accounting system – it is not possible to simply edit the existing data records under Services Flights anymore. All services recorded for an event are set to the Charge State* "Invoiced" and can no longer be edited. Any errors which might have occurred during service recording or calculation have to be corrected by creating additional credit or debit notes.
For creating a credit note for an erroneously billed service under Service, mark the service data record and click the button Credit. This will create a copy of the service data record listing the original price with a negative sign 
. After the changes have been stored, the next Credit invoice run under Billing will automatically generate a new invoice sent as a credit note to the customer.
If any services have been provided, but not recorded, it is possible to simply add them as a new service data record and store them. As with the Credit process, these services will then be taken into account with the next Debit invoice run under Billing and will automatically generate a new invoice sent as a credit note to the customer.
Note that both Credits and Debits are marked in the data field Inv.-Type of the corresponding service data records.
Creation and Printing of a Cash Invoice
For customers liable to pay cash, Services Flights features a function for the immediate creation and printing of a cash invoice document.
Before a cash invoicing procedure can be started, the following prerequisites have to be met:
All services have to be recorded and the basic pricing has to be checked
The final calculation has been run by clicking the button Calculate Charges
The State* has to be kept on Calculated (not Invoicing as for Credit Customers)
The customer must be defined as cash payer (checkbox Rec.Cash in the table Flight Events is marked)
The invoice print will be started by pressing the button Cash Payment Preview 
or the button Hotrun 
. This will open a new browser window, displaying a preview of the invoice document, which can then be printed.
After a cash invoice has been created, the event will be stored for a financial accounting invoicing run under Billing. Should the creation of a cash payment invoice have to be repeated due to errors, the previous run(s) will be kept stored as Cancelled for bookkeeping reasons. Only the final cash invoice will remain valid for the financial accounting.
Printing of Handling Documents or Attachments
After marking an event in the table Flight Events and a corresponding entry in the table Flight Events → Handling Documents or Flight Events → Attachments, the button View/Print Document 
is enabled and can be used to print out e.g. a Service Delivery Note (SDN) or an Indemnity Form or any other attached document.
Grouping of service entries for the same service
Typically, multiple entries are captured using the MSR. Usually, each of these entries shall be rounded for itself as shown in section "Round Quantity on MSR" in the picture below.
It may happen, though, that the same service is provided to the same passenger in several steps, each occasion captured with their own time stamps. In that case, the times for the service entries (for example related to the same passenger) shall be summed up and then the sum shall get rounded – refer to section "Round Quantity" in the picture above.
It is also possible to perform grouping of services after the creation of the additional entries, so that entries can get created first and are then grouped in a second step.
MSR:
Within the service details in the MSR, a short id can be entered for each entry. The MSR user can assign the same id to all those entries which shall be summed up before rounding, i.e. which belong together for example because the entry just represents a continuation of a service provision to same passenger.MSR tab in Backoffice:
The group number is displayed as additional attribute.Calculation:
The existing parameter "Round Quantity on MSR" is extended. It summs up all entries of a service with the same group number and applies the specified rounding afterwards.
The button Show Service Delivery Note
Generating an SDN by clicking the button Show Service Delivery Note 
behaves as follows:
In case there is no SDN available yet, an SDN with all CALCULATED and INVOICED charges is created.
In case that already one or several SDNs exist(s), only the last/newest (current SDN) one is considered in the following:
In case there are no new/unassigned CALCULATED/INVOICED charges for the billing event, the current SDN is called.
In case the billing event has not been calculated yet or the current SDN has not been signed yet, all further new CALCULATED/INVOICED charges are added to the current SDN and the already captured signature is deleted if necessary.
In case an SDN has been signed and includes calculated charges, the signature and the calculated charges are maintained. All possibly not calculated charges are integrated into a new supplementary SDN.
This means:
As long as a billing event has not been calculated, an already captured signature will be deleted at each newly captured service.
After calculation of a billing event, the signature available at the time of the calculation applies irrevocably to the calculated services.
In case both legs are calculated one after another, the signature thus applies to all services of the rotation.
If after calculation of just one leg a further SDN is generated, the signature only applies to the calculated leg, and the not calculated services are listed on a supplementary SDN, which has to be signed again.
|
Please also consider the following videos: Credit Card Surcharges and Discounts: How to add services to a billing event: How to calculate a billing event and move it to invoicing: How to create a invoice preview and provisional invoice: CreditACP customer wants to pay cash: |