[ Charging Rules ]

Hints #

The previous sections have described how the charging rules work but have not given any guidance on the practical matter of creating and changing rule sets.

Max2's ability to allow rule sets to be edited by the operator without recourse to changing the program is a very powerful tool. Like any powerful tool it must be treated with some care.

This section discusses various topics which should help to make changing the rules a safer and less troublesome activity.

Print A Rule Report #

Before trying to design a change, print a report of that rule set and study it carefully. In particular, make sure your are familiar with the exact meaning of each of the intrinsic and computed fields.

Consider All Cases #

When changing a rule set it is important to consider all of the possible cases of transactions which can be affected by the change. For example, a rule change on the way aerotow charges are calculated for ordinary members must not have an adverse effect on the way in which course flights are processed.

Undefined Fields #

Having fields undefined can be both a pitfall and a very useful feature.

There are two reasons why a field might not be defined. First, during entry of a transaction the rules are applied as each field is entered allowing the result of the transaction "so far" to be displayed. All intrinsic fields which have not yet been entered are undefined as this is done.

Secondly, a computed field might not be defined because no rule to define it applies in the circumstance. For example, the aerotow-fee field which contains the amount of money charged for the aerotow might be left undefined for a course flight where there is no separate aerotow fee charged.

These two reasons can combine, of course. A field may be undefined because it would be set by a rule which uses another field which is itself undefined.

Be very careful to distinguish between a field which is undefined and one which is zero.

Use of Properties #

If a rule is to apply to some but not all members of the club then use of a property on the appropriate accounts is a good method of indicating which accounts the rule is to be applied to.

Testing #

The best way to test the effect of a change to the charging rules is to try a few transactions. This should be done on a test copy of the database, rather than the live database, though in many cases there is no need to actually post a transaction to try out a change.

The best way to test the effect of a change to the charging rules is to try a few cases to exercise as many of the combinations as possible.

If a transaction actually needs to be posted to do the test then it should be done on a test copy of the database - rather than the live database. However, it is often possible to test the effects of changes to the rules without actually posting a transaction, in which case the testing can be done on the live database.

For example, a change to the glider flight rules can be tested by typing appropriate cases into the Glider Flight Entry form. The results can be checked without posting the transaction by observing the summary results in the bottom part of the form. If more detail is required the Transaction Details button can be used to display the Transaction form.

Debugging #

Inevitably, rule changes will occasionally have unexpected results.

The Transaction window can be used to see what is happening. This form shows details of the transaction including each of the fields.

The controls at the top of the window show information about the way in which the transaction is currently stored - its position in the transaction file (if it has been posted) and its position in memory - and the type of the transaction.

The main part of the window is a grid giving the details of each of the fields. The grid columns are:

No #

The number of the field within the transaction. All of the intrinsic fields appear, followed by the fields computed by the intrinsic rules and then those computed by the charging rules.

Name #

The name of the field.

State #

The current state of the field, a combination of the following letters:

Type #

The type of data which is or can be stored in the field.

Len #

The length of the field. For most types this is fixed (e.g, for Integer and Time it is always four) but for strings it is the actual length. For intrinsic fields the lengths of strings are fixed - if a shorter string is assigned extra spaces are added to the end. For computed string fields the length depends on the value assigned by the rule.

Value #

Is the actual value of the field. For undefined fields the text "(undefined)" is displayed.