[ Charging Rules ]

Fields #

As will be apparent from the introduction above, transaction fields are fundamental to the operation of the charging rules. This section discusses fields in detail.

Names #

Each field is identified by its name. Field names can be up to thirty characters long They are case sensitive, that is, soaring-fee, Soaring-Fee and SOARING-FEE are all different names.

The field names defined by Max2 are typically all lower case. Individual words within the name are separated by hyphens, e.g, landing-time. It is recommended that any names created follow this pattern.

Whenever a field name is used it is selected from a list of existing field names. Therefore there is never any need to remember the exact spelling for names. The only exception to this is, of course, when a new field name is created.

Types #

Each field has a type which says what sort of information is stored in it.

The types are described in Appendix A - Data Types. Those can be directly referenced in a charging rule are:

Special rule codes can only be tested for in existing fields (i.e., intrinsic or intrinsic rule fields). Headings can only be set in new computed fields.

In addition, Properties can be tested for using Has Property Condition Clauses

Intrinsic and Computed Fields #

The fields which are stored directly in a transaction are called intrinsic fields. They cannot be changed by the charging rules.

Computed fields are created when a charging rule set is applied. First a set of "intrinsic" rules are applied by Max2 to set a few computed fields directly. Then the rules in the rule set are applied in turn to set the remaining computed fields.

The intrinsic fields and fields set by the intrinsic rules are listed in Appendix B - Flight Transaction Fields.

Later rules can change the computed fields set by earlier rules.

Defined and Undefined Fields #

Sometimes a rule set is applied to a transaction before all of the intrinsic fields have been filled in.

For example, the rule set is applied as each field in the flight transaction is input, so that the computed fields can be displayed for checking as soon as possible. This means that the remaining fields which have not been input are left undefined.

Some rules can set computed fields but do not always do so. For example, rules might set a glider-owner field for gliders operated by the club which belong to other groups (such as the BBC or BGA) but leave the field undefined for all other gliders.

Rule sets must be written to take undefined fields into account. This is generally quite easy as any rule which depends on a field which is found to be undefined is simply ignored. This is discussed in more detail below.