A continuous accounting resource assessment system can be created in Source to replicate the resource assessment system used in the Gwydir and Namoi in NSW. There are a number of defining features of a continuous accounting system which differentiate it from continuous sharing and annual allocation systems:

Assessments of whether a new allocation can be made occur intermittently (based on triggers defined within the plan) with a new allocation resulting in an additional volume of water added to user’s accounts. With continuous accounting, there is no end of year forfeiture of allocation. There are, however, limits on the volume that can be held in a general security account at any one time and usage limits may also apply;
An account is maintained for the system as a whole to meet transmission and operation losses (TOL) for delivery of regulated water. An accounting process is followed to determine whether any of the available storage volume is unallocated. The unallocated volume remains after the following have been deducted from the active storage volume:
- reserve required for storage losses;
- reserve required for high security uses including an allowance for transmission losses to deliver these supplies;
- existing volume allocated to the generic system share/s;
- existing volumes allocated to general security entitlements in this system; and
- the volume required to be held in the system’s transmission and operation loss account.
High security accounts are assigned an allocation based on a defined relationship between percentage of the high security reserve met and allocation to accounts. The reserve set aside for high security uses is generally greater than the volume that is allocated to the high security accounts. Whilst the full reserve volume is set aside at each resource assessment prior to making an additional allocation, the accounts are only assigned an allocation on an annual basis.

The enhancements to continuous accounting in Source over IQQM are:

Ability to simulate more than one type of resource allocation and accounting method in the one scenario and to link one system to another;
Ability to specify data to calculate the initial balance of the usage limit;
Better simulation of management during dry periods including the ability to:
- Restrict allocations to high security accounts during dry periods where the required reserve cannot be met;
- Define the TOL factor as a variable depending on account balances. This allows a higher factor to be defined when balances are low, as a higher proportion of the allocations will be required to cover transmission losses; and
- Represent the rules which may reduce the required high security reserve.

System configuration

A continuous accounting system can be added to a particular scenario in a project using the Resource Assessment Explorer (Edit » Resource Assessment...). Right click on the scenario and choose Add Continuous Accounting from the contextual menu (as shown here). The parameters to configure are described in Table 1.

When you add a continuous accounting system, the following account types and triggers are automatically loaded:

Storage Loss Reserve - define the reserve required for evaporation and seepage losses from storage;
High Security Group 1 - define the reserve required for high security users. Also allows you to define accounts which relate to this reserve and the method for allocating water to these accounts;
- Trigger Write-Off
High Security Group 2 - same as for High Security Group 1 but relates to a separate, lower priority group of high security users;
- Trigger Write-Off
Generic System Share 1 - used to allocate water to another Resource assessment system;
General Security 1 - allows you to define accounting rules and shares for general security accounts;
- Usage Limit One Year; and
- Usage Limit Three Years.
General Security 2 - same as General Security 1 but can be prioritised and paramaterised separately.
- Usage Limit One Year; and
- Usage Limit Three Years.

Note: IQQM includes a number of inbuilt triggers which are not replicated in Source. For this reason, the Timesteps per assessment parameter may need to be set to 1. Additionally, to replicate IQQM, the TOL Share parameter on the high security account type should be zero.

Figure 1. Continuous accounting, Configuration

Table 1. Continuous Accounting, Configuration parameters

Item Name	Description
Owner	Volume of water available for the system based on the ownership share of any assigned storages. Ignore if ownership is not enabled.
Debit Type	Determines how water is deducted from all accounts associated with this continuous accounting system; based on either order or extractions.
Timesteps per Assessment	Defines number of time-steps between assessments.
Start of Water Year	Day-month that the water year starts for the continuous accounting system. Relevant for high security accounts as they are treated as annual accounts. The water year is also applicable to usage limits for the general security accounts.
No further resource assessments from this date	Day-month after which no further resource assessments should be conducted.
Assigned Storages Table	Lists all storage scenarios. These can be included as resources for the Resource Assessment System if required.

The Resource Allocation Table defines the allocation priority when there is more than one account type:

Account Type - Lists the account types available by default in a continuous accounting system;
Allocation Priority - Determines the order in which account types will be credited during a resource allocation; and
TOL Share - defines the TOL allocations for each eligible system account type.
TOL Min Share - if the TOL falls below TOL min, water will be borrowed from the users to restore TOL to at least this level. Water is borrowed from the lowest priority users first.

Although the TOL Min Share is restricted to a minimum of zero by the Source function, TOL is still possibly going to negative. In this situation, a general waning message will be displayed in Log Reporter. The user need to pay attention to Log Reporter, and then can turn this scenario off or change (e.g. to a warning) via the Assurance Rules. This issue may arise if the TOL is not large enough to cover delivery losses (e.g. during dry periods where tributary inflows are low and hence delivery losses are high).

Allocation priority can be edited within an account class (ie high-security types can be rearranged using allocation priorities) however, errors will be generated if priorities are rearranged outside of a class (eg. a general security type is set higher than a high security type).

Accounts

The Accounts tab (Figure 2) provides a summary of the accounts that have been added to the system. A description of the parameters in this tab is provided in Table 2.

Figure 2. Continuous Accounting, Accounts

Note: In IQQM, Number of shares is named Licence Volume. Additionally, the Initial balance parameter is not available.

Table 2. Continuous Accounting, Accounts parameters

Item Name	Description
Name	Account name
Account host	Type of water user node which is associated with the account
Account type	The type of account
Number of Shares	Defines the entitlement of the water user in terms of number of shares in the system.
Initial balance	Initial account balance. If you are going to use the initial account function, you need to ensure that there is sufficient water in storages to cover the total initial balances as well as the required reserves and TOL balance. If the initial balances are set too high a warning message will be generated and the results may not follow the required logic.

Trigger Priority

The Trigger priority tab (Figure 3) shows how triggers have been prioritised in the system.

Figure 3. Continuous Accounting, Trigger Priority

Storage Loss Reserve

The storage loss reserve (Figure 4) is a volume which is required to account for expected evaporation and seepage losses from the storage. The reserve is debited from the available resource prior to making any other allocations. It may be made a function of the current storage volume or area, which can be specified using a function. A minimum percentage of the required reserve that must be maintained can also be specified; restrictions are applied to general security accounts (or lowest priority account type) to achieve the required minimum reserve.

The following parameters must be specified:

Minimum to cover storage losses - Defines the percentage of required reserve below which borrowing occurs. This parameter is not available in IQQM, so it must be set to zero; and
Storage Loss Reserve Requirement - the reserve required to cover storage evaporation and seepage losses. Note that in IQQM, this requirement is defined through the number of months that evaporation is take into account. In some cases the storage loss is combined into the carryover reserve.

Figure 4. Continuous Accounting, Storage loss reserve

High Security Groups

High Security Groups (Figure 5) define the reserve which is required for high security users (may also be referred to as essential supplies). The high security reserve requirement may be defined using two groups - a higher and lower priority group. In the case where only one group is required, you can delete the other by right clicking on the item and choosing Delete. Additional groups may also be added (right click on the Continuous Accounting system and choose the desired system to be added). This can be specified as a fixed value or as a function. The latter can be used where there are rules that vary the high security reserve requirement.

Figure 5. Continuous Accounting, High Security Group

High Security accounts are treated as annual accounts with no carryover. In other words, at the start of a water year (as defined at the system level page), all accounts have their existing balance deleted and a new allocation is made. Allocation to high security accounts can be defined using a time series file or simulated based on whether or not the reserve requirement has been met. The Allocation Rules table allows you to define restrictions on allocations to high security accounts if the reserve requirement has not been completely met. The high security shares held by each water user is defined in Accounts. For example, if 1ML is the total reserve, and only 20% of the required high security reserve has been met, then high security accounts will only be given 0.3ML per entitlement share. Table 3 describes the parameters that must be specified.

Table 3. Continuous Accounting, High Security Groups parameters

Item Name	Description
High Security Reserve Requirement	Defines the required reserve. May be a function.
Required Reserve Below Which Borrowing Occurs	The percentage of required reserve below which borrowing occurs from general security accounts.
Time series allocation to accounts	If selected, the Allocation to accounts field is enabled, which allows you to define the allocation using a function.
Simulate Allocations to accounts	Enables the Using Account Rules table. Account allocations are automatically calculated. Note that the allocation to the reserve is always simulated regardless of whether this is selected or not.
Using Account Rules	Choosing Interpolate results in the allocation rate being determined based on interpolation between the specified rows. If you choose Thresholds, HS Reserve Met in the allocation table is treated as a threshold that has to be exceeded for the allocation rate to apply.
Allocation to accounts	Defines the allocation to accounts per share in that High Security group.

The Accounts tab provides an overview of the accounts and their associated hosts (as shown in Figure 6). The parameters are similar to those listed in Table 2.

Figure 6. Continuous Accounting, High Security Group, Accounts

Generic system share

The generic system share (GSS) is used to allocate water to another resource assessment system. Water user accounts cannot be added directly to the GSS account from within the Resource Assessment Explorer. The accounts associated with the GSS are configured as part of the linked system. The GSS is credited as part of the continuous accounting allocation method and is debited when accounts in the linked Resource assessment system are debited. If an allocation is made to the GSS, this volume is distributed to users as part of the resource assessment phase of the linked system. The configuration dialog is shown in Figure 7.

Figure 7. Continuous Accounting, Generic system share

The following parameters must be specified for a GSS:

Time Series Allocation - Enables the entry of a function for allocating to the GSS;
Simulate Allocation - Define a function to allocate to GSS. The value of the function is treated as a volume to be added to the GSS account subject to available water limitations; and
Total Volume Initial Balance - Initial balance in the GSS account.

GSS is generally used with resource assessment system linking to an annual accounting system where a portion of the resource assessment system is determined by the output of another system.

General Security

Here, you can define accounting rules for accounts. The general security shares held by each water user is defined using the Accounts tab. The parameters that must be specified are described in Table 4. In the example shown in Figure 8, allocations have been defined to general security account should be simulated using the in-built continuous accounting functionality. There has been no restriction set on the minimum or maximum balance volumes. If, for example, there is a maximum balance of 2ML per entitlement share. This means that if a water user has an entitlement of 200 shares, their maximum account balance is 400ML. Two usage limits have been defined. The first says that no more than 1.25 ML can be used per entitlement share in any water year. The second says that no more than 3ML can be used per entitlement share in any three consecutive water years. These rules replicate the conditions for the Namoi river system.

Figure 8. Continuous Accounting, General Security

Table 4. Continuous Accounting, General Security parameters

Item Name	Description
Time series Allocation	Allows you to define a time series file of volume to be allocated per unit share at that time-step. This volume is added to user’s accounts based on their number of shares. It also allows you to specify a function for allocation to GS.
Simulate Allocation	Determines the allocations to general security accounts which assess water availability.
Maximum Balance	Defines the maximum volume of water which can be held in an account. If an allocation results in this limit being exceeded, then the excess amount is redistributed to other accounts. Choose **Volume Per Unit Share** to define the maximum balance as a volume per share. In IQQM, it is referred to as maximum proportion of entitlement that can be in storage.
Minimum Balance	If a minimum balance is defined, then order or extractions will not be allowed if it will cause the balance to drop below the minimum specified. This is not included in IQQM.

Usage limits

Click Usage Limit One Year to place a limit on account usage within one year (as shown in Figure 9). You can configure this for three years as well using the Usage Limit Three Years item. Table 5 shows the parameters that must be configured for both.

Figure 9. Continuous Accounting, General Security, Usage limit

Table 5. Continuous Accounting, General Security, Usage limit parameters

Item	Description
Period	Time period that the limit applies to - *Moving Water Year, Moving Window* or *Water Year. If a usage limits relates to a single water year, choose Moving Water Year* and set Years to 1. Where a "rolling years" usage limit has been defined in IQQM for general security accounts, these should be defined as *Moving Water Year* limits in Source.
Quantity	Specify if the limit is **Volume per Unit Share or an Absolute quantity. To replicate IQQM, set this parameter to Volume per Unit Share**.
Years	For a moving water year, enter the number of years the usage limit applies to. For a moving window, define the number of days that the usage limit applies to.
Quantity	Usage limit over the period that is to be applied to all accounts.

Browser not supported