An Overview Of The Payment Event Creation & Allocation Process
When a payment event occurs, the system stores a tender for each form of remittance (e.g., cash, check, charge). It then allocates the sum of the tenders to one or more accounts.
By default, the system allocates the sum of the tenders to the account that remits the tenders. You may override this default and specify any number of accounts and their respective payment allocation amount. This is useful, for example, when a social service agency pays for many accounts. If applicable, you may also configure the system to use your own payment event distribution rule(s).
Refer to Distributing A Payment Event for more information.
The system distributes a payment amongst an account's service agreements based on the age of each service agreement's debt AND distribution priority. The system creates a payment segment for each service agreement that receives part of the payment.
Refer to Distributing A Payment Amongst An Account's Service Agreements for more information.
You may manually redistribute the payment amount amongst the account's service agreements before you commit the distribution. When the distribution is acceptable, you freeze the payment. Freezing a payment causes the system to create a financial transaction for each related payment segment. It is the financial transaction(s) that causes the service agreements' payoff and current balances to be reduced. The financial transaction also contains the journal details that debit "cash" and credit some other GL account.
And that's it. The remaining topics in this section provide more information about the creation and allocation of payment events.
Batch and real-time payment event creation / allocation. There is only one payment event creation / allocation routine and therefore anything the batch payment process does for whole batches of payments, you can do to a payment on-line.