The allocation table links together transactions so that the system can track which payments were allocated to which charges. This also means that payments can be de-allocated from charges, and reallocated dynamically, should situations change on the account.
The KSSA_ALLOCATION table is the table of record for allocation information. The TRANSACTION data structure contains grouped information on allocations, but only the ALLOCATION table contains the actual reference of payments and charges. If for whatever reason, the two were to become unsynchronized, the ALLOCATION table would be the table to verify.
Examples of re-allocation would include the posting of charges to the account that are of higher priority than earlier transactions, or the refund of a transaction that had previously been paid.
Tracks allocations between different transactions.
Autonumbered PK for the allocation.
Transaction identifier for the first transaction. This transaction is the "payer" – that is to say that the transaction identified in this key is the credit balance that will pay off a debit balance.
Transaction identifier for the second transaction. This transaction is the "paid" transaction. That is to say that the transaction identified by this key will have its debit balance a paid with funds from transaction 1.
If this is a locked allocation (that is to say that the payment allocation routine is not allowed to deallocate the payment) then this value will be true.
Boolean indicated that the allocation is internally locked (administrative lock).
This value can be derived from either of the transactions, as allocations can only occur on a single account. However it is included to permit easier tracking of allocations to accounts. It points to the account identifier as referenced in the ACNT table.
The amount of the allocation. This is recorded in the default system currency. There may be many allocations from a payment that are used to pay off a single charge, and many charges may be paid off by a single payment.