Allocations
Allocations hold links from funds Source Transactions that pay other Source Transactions. They also record who created the allocation and when this was done. In some cases, the creation of an allocation will also post ledger transactions to balance funds in ledger accounts.
There can be multiple positive and negative allocations between funds and paid items.
Allocations are never altered or deleted. This is required because they need to act as a audit trail of the financial allocations.
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.
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.
Allocation Abbreviations like D50 --20-->I50 may be used to represent allocations:
Allocations normally have +ve values unless they are reversals of other allocations. If there is only a -ve allocation between two transaction lines, this is an error. Examples of allocations are:
- +ve cheque line pays +ve bill line (allocation is +ve)
- -ve bill credit note lines pays +ve bill line (allocation is +ve)
- +ve deposit line pays +ve invoice line (allocation is +ve)
- -ve invoice credit note lines pays +ve invoice line (allocation is +ve)
An Allocation Batch is where multiple allocations are created together and linked by a Batch_Id. This would occur when a single deposit is partially allocated to multiple invoices in order to consume all of its funds. Similarly, multiple allocations from smaller deposits may be required to completely pay a large invoice amount.
Allocation Errors can be corrected by reversing them.
When allocations are reversed, their value is completely reversed. For example, a $200 allocation is cancelled by creating another -$200 allocation. No partial reversals are permitted so as to reduce data complexity. If partial reversals were permitted, we would need to sum all reversals to see how much remained, causing slow performance and more complex database logic.