Summary of Creating a Contract with Price configurations

This chapter gives a comprehensive summary of the creation of price configurations for contracts. For specific details, please refer to the chapters covering the individual tables used for price configuration management.

Basically, price configurations allow you to define parameters and rules for a contract which are linked to specific prices and/or price adaptations. Thus, a single contract (e.g. for an airline) and the services included therein can be used for a variety of different handling situations: During the automatic contract assignment to an actual flight, the applicable contract's price configurations are checked based on the actual flight data for the parameters and rules which apply. After the rules have been defined, the prices for the contractual services are also automatically calculated.

Example 1a: You want to assign to a specific contract two parameters which influence the price to be paid for the services included therein: the aircraft type and a possible surcharge depending on date and daytime a flight takes place.
In this context, the aircraft type will be used as a basis for the basic price of the complete contractual services. This will be explained first in the following chapter. Later, the addition of a percentage surcharge based on date/daytime will be added to this.

The following figure illustrates the general principle of how the basic price calculation is handled under Contract. It refers to the definition of a basic price based on the aircraft type and does only take the central aspects into account. The tables required for this process are Contract -> Price Configurations and the dependent table Price Configurations -> Rules.

Example for a condition cascade of price configurations

As price configurations are math-based formulas, it is important to understand some basic terms and the concept behind these first:

Parameter: A basic definition of a parameter to be taken into account for pricing. The options for this parameter are predefined and made available in a pull-down menu. The most important one is a basic price for a contract, Unit price, others are price modifications like Percentage for delay, Percentage for night time etc. Note that for each Parameter multiple data records can be defined. Each record is linked to one or more rules in the table Price Configurations -> Rules (represented by the block arrows in the figure above, where only one rule is defined for each Parameter*). These rules define the conditions which have to apply for the parameter variant to become valid.

Position: Upon contract assignment to a specific flight, the price configurations are checked for parameters and their rules which might apply to the actual flight data. As said above, each Parameter can have multiple records, each related to different conditions. The Position* entry is a numerical value used to define in which order the variants of an identical parameter are checked by the software: The highest number is checked first, the second highest next etc. It is generally recommended for most parameters to create a record with the Position* value zero '0'. This record is not assigned any rules/conditions and will be used as default if none of the otherwise defined rules applies.

Price: A Parameter*/Position/Rules combination can be assigned a Price/Value which is used if the combination is applicable for a specific flight event. This numerical entry represents a net price for all standard services included in a contract (optional/additional services are not included!). Note that the price is used only for parameters which define net prices (i.e. Unit price).

Surcharge: Analogous to the Price/Value, a Parameter*/Position/Rules combination can be assigned a Surcharge/Discount value which is used if the combination is applicable for a specific flight event. This value represents a percentage modifier to the applicable price and can only be used for those parameters which define percentage surcharges/percentage for cancellations (e.g. Percentage for delay, Percentage for holiday or sunday etc.). A normal value represents a surcharge, a negative value (preceded by a minus '-') represents a discount.

Example 1b: Referring to Example 1a and the figure above, the basic price for a contract is to be defined based on the rule Aircraft Type. Assumed that the customer airline mainly uses 3 different aircraft types (i.e. 738, B733 and 320), 4 data records for the parameter Unit price are created, which are assigned the positions 3, 2, 1, 0 (remember the record with Position* '0' is required to be used as a default price if none of the other parameter rules is applicable).
In a next step, the data record with Position '3' is marked, and the table Price Configurations > Rules is accessed. Here, the rule Aircraft Type is selected, the mathematical operation equal is selected, and the aircraft type definition '320' is entered in the field Low Level (note that for an equal operation, the corresponding value is always entered in the field Low Level – if the rule definition uses a between operation, both the fields Low Level and High Level are used to define a specific span, e.g. for defining a time period for a delay surcharge). This step is repeated for the other two aircraft types as well. For the last record featuring the Position '0', no rules are defined.

Please note: Multiple entries for the mathematical Operation 'in' have to be entered comma-separated in the field Low Level – for example, if a variety of aircraft types has to be defined.
Finally, the Price Configurations are defined for each aircraft type and the default Position record in the table Contract -> Price Configurations.
Whenever the contract is checked for assignment to a specific flight event, the price configurations are also taken into account. The software finds the Parameter* entry Unit price and starts checking the applicability of the available variants from the highest Position to the lowest (represented by the curved arrows in the figure). As soon as the aircraft type used for the flight matches one of the conditions defined in the table Price Configurations -> Rules, the corresponding price is assigned to the handling of the flight event. The same is done for all other Parameter* variants (e.g. Percentage for delay), which have not been covered in this example.

Basically, all other price configuration definitions follow this procedure. More details about the individual parameters and the rules and operations used in the table Price Configurations -> Rules are available in the following chapters.