Allocations

Allocations hold links from funds Source Transactions that pay other Source Transactions. They also record who created the allocation of when this was done. In some cases, the creation of an allocation will also post ledger transactions to balance funds in ledger accounts.

A set of Allocation Rules define which source transactions can act as funds or paid items and what can pay what. i.e. A +ve deposit line can pay +ve invoice line, but it cannot itself be paid.

There can be multiple positive and negative allocations between funds and paid items.

• Funds items can pay multiple other items as long as in total there is not an Over Allocation or Under Allocation.
• Paid items can be paid by multiple funds items as long as in total there is not an Over Payment or Under Payment.
• Part paid items are those that have allocations between zero and the Line_Total.

Here are some abbreviations used to represent allocations:

Allocation Abbreviations

D50 --20-->I50	$50 deposit pays $20 to a $50 invoice
ICN50 --20-->I50	$50 invoice credit note pays $20 to a $50 invoice
E50 --20-->B50	$50 cheque pays $20 to a $50 bill
BCN50 --20-->B50	$50 bill credit note pays $20 to a $50 bill

Allocations can be reversed, and the reversal is linked to the allocation that it reverses.

Allocations normally have +ve values unless they are reversals of other allocations.

Allocation Reversals cannot themselves be reversed. Instead, a new +ve allocation must be created. This avoids allocations being chained into allocation-->reversal-->reversal of reversal etc which required complex recursive processing and is slow.

Allocations are only ever created by a single am_allocate stored procedure which enforces all of the Allocation Rules. It also adjusts the status of the funds and paid items according to the rules so that allocation/payment status can be quickly determined.