|[ < Prev | Contents | Next > ]|
[ Overview ]
Max2 organizes the storage of its data on a month by month basis. This is reflected in the user interface. The operator selects which month is to be processed in the Max2 main window.
Many changes to the Max2 data which have a wide reaching effect (such as changes to the rules used to decide how much is charged for each flight) can only be applied on a month by month basis. That is, the rules cannot be changed in the middle of a month, although a rule could include a condition based on the day of the month such that it only applies for part of a month.
Almost all of the information which is input into Max2 is stored in transaction files. The only exceptions to this are minor administrative items such as changes to the list of authorized operators.
There are two transaction files for each month. One is called the start-of-month file which contains the transactions which apply across the whole month, such as changes to the charging rules and creation or deletion of accounts.
The other transaction file is the daily file which contains transactions which apply to a specific day in the month, such as glider flights, cash receipts, account credits and debits and sales of trial lesson tickets, courses and memberships.
Each month has a state file. This contains a snapshot of the state of all the accounts, charging rules and other objects processed by Max2 up to the end of the transaction files for that month.
The state file for a month is created by copying the state file from the previous month and then applying all of the transactions for its month. The state file can be rebuilt in this way at any time.
As new transactions are added to the transaction files for a month they are applied so that the state file for the month is kept up-to-date.
Sometimes the state file has to be rebuilt. If a transaction is input for an old month then all of the following months' state files can be affected and so must be rebuilt. Also, if a start-of-month transaction is input which can change the effect of later daily transactions in the same month then the state file must be rebuilt. An example would be a change to the charging rules.
Max2 automatically keeps track of when the state file needs to be rebuilt and prevents the operator from accidentally using an out-of-date state file. If an operator selects a month with an out-of-date state file then Max2 prompts them asking whether the state file should be rebuilt. This is always safe to do but takes a few minutes.
Objects in the state file such as accounts are never deleted. Instead they are marked for deletion which will cause them to be skipped when the state file is copied to form the state file of the following month. In effect, the deletion is deferred until the end of the month in question. On lists such objects are often shown with the text "(to be deleted)" after their name.
Once all of the transactions for a month have been entered and validated (e.g., statements have been printed and complaints of any errors dealt with) the month can be closed. This prevents further transactions from being entered.
The advantage of closing a month is that it prevents the accidental entry of transactions which would invalidate reports which have been printed and used for other purposes - e.g., the club's bookkeeping.
In emergency, a month may be reopened but this should be done with extreme caution.
|[ < Prev | Contents | Next > ]|