The Table Services → Account

In this table the booking of service revenues to internal accounts can be defined corresponding to ERP accounts to which individual services are to be booked.

In order to define and edit the accounting settings for an individual service, mark the corresponding service in the table Services and switch to the dependent table Services → Account.

Please note that most of the data recorded here is required only for informational purposes or for the preparation of forwarding data to an external financial accounting system (e.g. SAP, ORACLE Finance etc.). Because the format of the data required by different financial accounting systems may vary, only the general proceedings can be explained here. If required, the individual details can be clarified in cooperation with a topsystem contact.

Important: One decisive entry for the price calculation is the data field VAT. Here, the country-specific applicable VAT rate for the service has to be entered! Otherwise, no VAT will be included in the invoicing processes!

Remarks regarding the flags Special Service (table Services) and MSR (table Services → Account):

• Flags Special Service and MSR are set: Service is shown in the MSR, service can be recorded as special service in the application and in MSR.

• Only flag Special Service is set: Service is not shown in the MSR, service can be recorded as special service in the application.

• Only flag MSR is set: Service is shown in the MSR if it is a contractual service, service can neither be recorded as special service in the application nor in the MSR.

• Neither of the flags is set: Service is not shown in the MSR, service can neither be recorded as special service in the application nor in the MSR.

Following data can be recorded for the accounting of services:

The Table Services → Price Configurations

This master data table is used to define details about service prices and price calculations. The table is dependent on the table Services. It also has the table Price Configurations → Rules as a dependent table.

The following data is available in the table Services → Price Configurations:

The basic principle is the following:

• The services are listed in the table Services.

• The calculation rules of prices and quantity are defined in the table Services → Price Configurations.

• Whether a calculation rule applies to a particular event is specified in the table Services → Price Configurations → Rules.

To access information about the price details concerning a specific service, mark its entry in one of the tables Services and switch to the dependent table Services → Price Configurations to get a list of all price details concerning the selected service.

Please note that not only the basic prices for services are managed here but – in combination with the additional table Price Configurations → Rules and the master data module Price Formulas – also copious and detailed regulations and formulas for automated calculations.

Important: Please note that the complete procedure described below is applicable only for services which are provided for an event outside The Module MessageBroker Interfaces)!

Although it is, of course, possible to simply assign a basic price for a service, the application offers elaborate features for defining calculation rules for service pricing. In a calculation process for standard services, these rules then check actual events (e.g. a flight for which services have been provided) and the appropriate conditions for the pricing.

Example: One and the same standard service – e.g. "De-icing" – might have a different basic price for different aircraft types. In addition to this, a surcharge might be required if the service is rendered during the night. Conditions like these can be designed with the price calculation system and are then taken automatically into account whenever the service is rendered for a specific event.

Using the price formula features makes it necessary to use multiple data records for defining the price rules accordingly. Another option offered by the availability of multiple records is the keeping of a price history based on the Valid From… – Valid Until… fields.

The basic process behind the condition management for the pricing is as follows: First of all, a data record for actual prices is created in the dependent table Services → Price Configurations. Here, an actual price is entered in the field Price/Value, and the entry UNIT PRICE (= price for one unit of the service) is selected from the pull-down menu Parameter. In the field Position*, a numerical value is entered which is based on the number of conditions you want to cover (see below). This combination of Services, Parameter and Position defines the basic identification which is required to specify a condition for the service price in the master data module Price Formulas.

Now you can create a new data record with a different Price/Value and a Position* with a value one counter below the original – this new position defines that a different condition is set in the module Price Formulas for the new price to become applicable. This process is continued until you reach the Position* "0", which should then represent a basic price which is valid without any conditions.

Important: As a basic requirement for assigning a price to a service, each service must have at least one data record for price definition! This record must

1. feature a basic price in the field Price*

2. be of the Parameter category UNIT PRICE (= price for one unit of the service)

3. have the Position* value "0" (= no conditions are applied). This entry is required as a default price for the service recording and billing modules.

The numbering in the field Position* creates a "sequence" of conditions which are automatically checked from the highest to the lowest value during the price calculation in the operative service recording/billing. As soon as the checking routine finds a Position* where all conditions apply to the actual event for which the service has been provided, the corresponding price is selected.

The following example illustrates this somewhat complex process:

Example 1: For the service "Landing Fee", different prices shall be applied depending on the MTOW of the landing aircraft. Three different categories shall be created: aircraft with more than 136 t – 300€, aircraft between 136-20 t – 200€ and aircraft below 20 t – 100€.

In a first step, a price data record is created for the service "Landing Fee" which is assigned the values 300 for Price/Value, Position* value "3" and the Parameter entry Unit price. In the table Price Configurations → Rules, this data record is then assigned the condition "MTOW>136 t". Now a second data record is created which is assigned the values 200 for Price/Value, Position* value "2" and also the Price Catalogue entry Unit price. Correspondingly, in the table Price Configurations → Rules this data record is assigned the conditions "MTOW<136 t & >20 t". Finally, a last record is created with the values 100 for Price/Value*, Position* value "3" and the Parameter entry Unit price and the appropriate condition under Price Configurations → Rules.

For the automatic price calculation of the actual landing of an aircraft, the complete event data (times, aircraft type, passengers, MTOW etc.) is available. Let's assume an aircraft with an MTOW of 100 t would land. During the calculation process for the "Landing Fee", the calculation software would then find the Unit price variants with conditions based on "MTOW" and start checking the available Position* values from the highest (in this case "3") to the lowest.

Although the condition type refers to the MTOW, the values set here only include aircraft with "MTOW >136 t". Thus, the calculation mechanisms would search for the next lower position. Here, in Position* "2", the values are "MTOW <136 t >20 t". This includes the actual aircraft weight of 100 t (see above), and the corresponding Price/Value* of 200€ would be applied.

This example illustrates the principle of basic price calculation in connection with a specific condition referring to actual events (note that it is also possible to assign more than one condition to a position – this is explained in the chapter The Table Services > Price Configurations > Rules).

In addition to basic pricing, a variety of other parameters can also be used for modifying the resulting price. All available parameters are listed in the pull-down menu Parameter*. As with the basic price (Unit price), each kind of parameter can also be structured in a Position*-based hierarchy of conditions.

Example 2: In addition to the MTOW-based price calculation for the service "Landing Fee" described in Example 1 above, the time of the day shall also be taken into account for the pricing. In this case, a night surcharge of 30% shall be applied for landings between 22:00-06:00.

This is done with two additional pricing data records – Position* "1" and "0", both with the parameter Percentage for cancellation. The data record with Position* “1” is assigned the value “-30” in the field Price/Value* (the parameter Percentage for cancellation is counted as a percentage value, as a price reduction if unsigned, as a surcharge if signed with a minus “-“). For the data record with Position „1" the condition "between 22:00-06:00" is defined in the table Price Configurations → Rules while for the data record with position "0" no condition is defined. The value in the field Price* for Position* "0" is zero "0", because no modification is applied here.

In the price calculation process, the billing software now finds these conditions for the parameter Percentage for cancellation, in addition to the normal pricing conditions Parameter entry Unit price (see Example 1). By checking the data from an actual flight event – in this case the landing time – the software now also includes a query concerning a possible surcharge depending on time conditions.

The Table Services → Services AHM

This table is used for establishing the relation between the services (in table Services) and the official AHM services available in the SGHA catalogues.