{{ model.title }}
This page is currently being edited by {{ model.editingBy }}.Recent Change:
6.48 - Fixed bugs related to rebuilding ar012a and commission payouts when running the distribute processor through data validation.
The distribute processor creates transaction distributions for each payment. If the distribute payments system setting is enabled, the single payment transaction will be divided into multiple payment transactions, and each of the new transactions will be associated with the Payment code to distribute to setting on a non-payment transaction's transaction code, provided that the payment transaction has not been posted to ledger.
The only exception is any transaction associated with an exemption transaction code that has been configured with some charge transaction code; this will be handled by the Payment Processor (more to come?).
Distribute processor always creates transaction distribution records regardless of whether distribute payments system setting is on or off. We always create transaction distribution records for all unprocessed payments.
The distribute processor only processes transactions for the UB and TX modules.
Workflow
- Load all payments ordered by date ascending (oldest payment first).
- Load all unpaid charges based on the order of charges.
- Distribute negative charges against positive charges with matching transaction codes.
- Distribute the unprocessed payments to the charges.
- Distribute the original payment transaction to multiple payment transactions.
- Any left over balance is an over payment.
Order of Charges
Charges are loaded in preparation of being paid off. The order of charges loaded is determined in the Utility Billing General Settings file. The selectable options are:
- By transaction date then by payment priority
- By payment priority then by transaction date
Either choice will be further filtered by Transaction Number, a value assigned when the charge is created.
Exceptions
- Payments that are negative charges will pay off charges that share the same transaction code first.
- Charges that have transaction codes with priority 0 will always take priority even when ordering date first. See scenarios 11-14 for examples.
Payment
A payment is defined as:
- a transaction with a relationship to a payment transaction code
- a negative charge (not payment) where the amount value of less than zero
All payments also have the Lpaid flag initially set to "false" (0).
Charge
A charge is defined as:
- a transaction with a relationship to a transaction code that has been configured as non payment transaction code
- has a balance of greater than or equal to 0
All charges also have the Lpaid flag initially set to "false" (0).
Overpayment
- A payment transaction that does not have any charges that it can relate to is considered an overpayment.
- If a module that uses distribute processing is set to track overpayments separately, overpayment transactions will have their transaction code altered to the designated overpayment transaction code.
- Overpayments can be tracked separately in the Accounts Receivable, Utility Billing, and Tax Collection modules, as they are the only modules that currently use the distribute processor.
Exemption Transactions
Exemption transaction codes configured a specific way with change charge transactions into payment transactions.
An exemption transaction is a transaction has been configured with a relationship to another charge transaction code. Currently these types of transaction codes are only used in tax and can only be configure external to SmartFusion (aka conversion).
This allows SmartFusion to treat these unpaid exemption transaction charges as payments instead.
Transaction Distribution
A transaction distribution record allows SmartFusion to take partial payment and also to allows a single transaction to be associated with one or more other transactions.
Payment Transaction Code
Payment transaction code by setting the payment property to "true" (1) on the Transaction Code.
Scenarios
For our example scenarios we'll use two tables and walk through each work flow. The transaction code format is [Description (code, priority, payment distribution code)]. If the distribute payments system setting is not on then the payment will use the [ReceiptCode]'s transaction code of the receipt code use when accepting the payment. Transactions are order by date of oldest to newest.
Receipt Code -> Transaction Code UBPAY
- Two Charges, One Complete Payment, Not Distributing Payments, Priority then Date
- Two Charges, One Complete Payment, Distributing Payments, Priority then Date
- Two Charges, One Partial Payment, Not Distributing Payments, Priority then Date
- Two Charges, One Partial Payment, Distributing Payments, Priority then Date
- Two Positive Charges, One Negative Charge, One Payment, Not Distributing Payments, Priority then Date
- Two Positive Charges, One Negative Charge, One Payment, Distributing Payments, Priority then Date
- Next month after Scenario 3, Two Charges, One Payment, Not Distributing Payments, Priority then Date
- Zero Balance, One Charge, One Payment, Distributing Payments, Priority then Date
- Negative Balance, One Charge, One Existing Over Payment, One Payment, Distributing Payments, Priority then Date
- One Charge, One Adjustment (negative charge), One Payment, Not Distributing Payments, Priority then Date
- Three Positive Charges, One Negative Charge, One Payment, Distributing Payments, Date Then Priority
- Three Positive Charges, One Negative Charge, One Payment, Not Distributing Payments, Date Then Priority
- Three Positive Charges, One Negative Charge, One Payment, Distributing Payments, Priority Then Date
- Three Positive Charges, One Negative Charge, One Payment, Not Distributing Payments, Priority Then Date
1. Two Charges, One Complete Payment, Not Distributing Payments, Priority then Date
Initial Balance: 30 Payment Amount: 30
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|----------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
3 | -30 | Payment (UBPAY,1) | Yes |
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 2 | 15 |
2 | 3 | 1 | 15 |
The payment was able to be associated with both charges and all were able to be paid.
2. Two Charges, One Complete Payment, Distributing Payments, Priority then Date
Initial Balance: 30 Payment Amount: 30
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|----------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
4 | -15 | Payment (PWTR,1) | Yes |
5 | -15 | Payment (PSWR,2) | Yes |
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 4 | 2 | 15 |
2 | 5 | 1 | 15 |
The payment was able to be associated with both charges and all were able to be paid. The original payment was able to be divided across the charges as new payments.
3. Two Charges, One Partial Payment, Not Distributing Payments, Priority then Date
Initial Balance: 30 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|----------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | No |
3 | -25 | Payment (UBPAY,1) | Yes |
Balance: 5
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | 15 |
2 | 3 | 2 | 10 |
The payment was able to be associated with both transactions and some transactions were able to be paid. The transaction for the water transaction code was not able to be fully paid off therefore it was not marked as paid.
4. Two Charges, One Partial Payment, Distributing Payments, Priority then Date
Initial Balance: 30 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|----------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | No |
4 | -15 | Payment (PSWR,1) | Yes |
5 | -10 | Payment (PWTR,2) | Yes |
Balance: 5
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 4 | 1 | 15 |
2 | 5 | 2 | 10 |
The payment was able to be associated with both transactions and some transactions were able to be paid. The transaction for the water transaction code was not able to be fully paid off therefore it was not marked as paid.
5. Two Positive Charges, One Negative Charge, One Payment, Distributing Payments, Priority then Date
Initial Balance: 25 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|------------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | Yes |
3 | -5 | Garbage (GRB,2,PGRB) | Yes |
5 | -10 | Payment (PSWR,1) | Yes |
6 | -15 | Payment (PWTR,2) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -5 |
2 | 5 | 1 | 10 |
3 | 6 | 2 | 15 |
The payment was able to be associated with all transactions and all transactions were able to be paid.
6. Two Positive Charges, One Negative Charge, One Payment, Distributing Payments, Priority then Date
Initial Balance: 25 Payment Amount: 30
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|------------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | Yes |
3 | -5 | Garbage (GRB,2,UBPAY) | Yes |
4 | -5 | Payment (OVERPAY,1) | No |
5 | -10 | Payment (PSWR,1) | Yes |
6 | -15 | Payment (PWTR,2) | Yes |
Balance: -5
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -5 |
2 | 5 | 1 | 10 |
3 | 6 | 2 | 15 |
The payment was able to be associated with all transaction and all transaction were able to be paid. There is a $5 over payment remaining. This will be use first on the next payment distribution.
7. Next month after Scenario 3, Two Charges, One Payment, Not Distributing Payments, Priority then Date
Previous Balance: 5 Initial Balance: 25 + 5 = 30 Payment Amount: 30
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|----------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | Yes |
3 | -25 | Payment (UBPAY,1) | Yes |
4 | 10 | Sewer (SWR,1,PSWR) | Yes |
5 | 15 | Water (WTR,2,PWTR) | Yes |
6 | -30 | Payment (UBPAY,1) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | 15 |
2 | 3 | 2 | 10 |
3 | 6 | 4 | 10 |
4 | 6 | 2 | 5 |
5 | 6 | 5 | 15 |
The payment was able to be associated with all unpaid charges and some were able to be paid. The transaction for the water transaction code was not able to be fully paid off therefore it was not marked as paid.
8. Zero Balance, One Charge, One Payment, Distributing Payments, Priority then Date
Initial Balance: 5 Payment Amount: 40
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|------------------------|------|
1 | 5 | Sewer (SWR,1,PSWR) | Yes |
2 | -35 | Payment (OVRPAY,1) | No |
3 | -5 | Payment (PSWR,1) | Yes |
Balance: -35
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | 5 |
The payment was able to be applied to the single charge. There is a $35 over payment remaining. This will be use first on the next payment distribution.
9. Negative Balance, One Charge, One Existing Over Payment, One Payment, Distributing Payments, Priority then Date
Initial Balance: -35 Payment Amount: 15
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|------------------------|------|
1 | -20 | Payment (OVRPAY,1) | No |
2 | 15 | Sewer (SWR,1,PSWR) | Yes |
3 | -15 | Payment (OVRPAY,1) | No |
4 | -15 | Payment (PSWR,1) | Yes |
Balance: -35
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 4 | 1 | 15 |
The existing over payment was able to be applied to the single charge. The new payment was marked as an over payment. There is a $20 and $15 over payment remaining. The original payment will be use first on the next payment distribution then the newest 15 payment next.
10. One Charge, One Adjustment (negative charge), One Payment, Not Distributing Payments, Priority then Date
Initial Balance: 0 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|------------------------|------|
1 | 15 | Sewer (SWR,1,PSWR) | Yes |
2 | 15 | Water (WTR,2,PWTR) | Yes |
3 | -5 | Water (WTR,2,PWTR) | Yes |
4 | -25 | Payment (UBPAY,1) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 2 | -5 |
2 | 4 | 1 | 15 |
3 | 4 | 2 | 10 |
The water adjustment was applied to the current existing water charge. The new payment was distributed to existing charges based on priority.
11. Three Positive Charges, One Negative Charge, One Payment, Distributing Payments, Date Then Priority
This scenario is demonstrating the OrderOfCharges exception when using a priority 0 transaction code.
Initial Balance: 25 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|--------------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
3 | -10 | Sewer (SWR,2,PGRB) | Yes |
4 | 5 | Convenience Fee (CFE,0) | Yes |
6 | -5 | Payment (UBPAY) | Yes |
7 | -5 | Payment (PSWR,1) | Yes |
8 | -15 | Payment (PWTR,2) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -10 |
2 | 6 | 4 | 5 |
2 | 7 | 1 | 5 |
2 | 8 | 2 | 15 |
The payment was able to be associated with all transactions and all transactions were able to be paid. The sewer adjustment was applied to the sewer charge. The convenience fee was paid off first even though we are processing payments by date the priority due to the fact that the charge transaction code has a priority of 0 which overrides the sort setting. This allows the convenience fee to be paid first. Then all remaining charges are paid off base on the system setting of "Date then Priority".
12. Three Positive Charges, One Negative Charge, One Payment, Not Distributing Payments, Date Then Priority
This scenario is demonstrating the OrderOfCharges exception when using a priority 0 transaction code.
Initial Balance: 25 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|--------------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
3 | -10 | Sewer (SWR,2,PGRB) | Yes |
4 | 5 | Convenience Fee (CFE,0) | Yes |
6 | -25 | Payment (UBPAY) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -10 |
2 | 6 | 4 | 5 |
2 | 6 | 1 | 5 |
2 | 6 | 2 | 15 |
The payment was able to be associated with all transactions and all transactions were able to be paid. The sewer adjustment was applied to the sewer charge. The convenience fee was paid off first even though we are processing payments by date the priority due to the fact that the charge transaction code has a priority of 0 which overrides the sort setting. This allows the convenience fee to be paid first. Then all remaining charges are paid off base on the system setting of "Date then Priority".
13. Three Positive Charges, One Negative Charge, One Payment, Distributing Payments, Priority then Date
This scenario is demonstrating the OrderOfCharges exception when using a priority 0 transaction code.
Initial Balance: 25 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|--------------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
3 | -10 | Sewer (SWR,2,PGRB) | Yes |
4 | 5 | Convenience Fee (CFE,0) | Yes |
6 | -5 | Payment (UBPAY) | Yes |
7 | -5 | Payment (PSWR,1) | Yes |
8 | -15 | Payment (PWTR,2) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -10 |
2 | 6 | 4 | 5 |
2 | 7 | 2 | 15 |
2 | 8 | 1 | 5 |
The payment was able to be associated with all transactions and all transactions were able to be paid. The sewer adjustment was applied to the sewer charge. The convenience fee was paid off first even though we are processing payments by date the priority due to the fact that the charge transaction code has a priority of 0 which overrides the sort setting. This allows the convenience fee to be paid first. Then all remaining charges are paid off base on the system setting of "Priority then Date".
14. Three Positive Charges, One Negative Charge, One Payment, Not Distributing Payments, Priority then Date
This scenario is demonstrating the OrderOfCharges exception when using a priority 0 transaction code.
Initial Balance: 25 Payment Amount: 25
Transactions
ID | Amount | Transaction Code | Paid |
---|--------|--------------------------|------|
1 | 15 | Sewer (SWR,2,PSWR) | Yes |
2 | 15 | Water (WTR,1,PWTR) | Yes |
3 | -10 | Sewer (SWR,2,PGRB) | Yes |
4 | 5 | Convenience Fee (CFE,0) | Yes |
6 | -25 | Payment (UBPAY) | Yes |
Balance: 0
Transaction Distributions
ID | Pay ID | Charge ID | Amount |
---|--------|-----------|--------|
1 | 3 | 1 | -10 |
2 | 6 | 4 | 5 |
2 | 6 | 2 | 15 |
2 | 6 | 1 | 5 |
The payment was able to be associated with all transactions and all transactions were able to be paid. The sewer adjustment was applied to the sewer charge. The convenience fee was paid off first even though we are processing payments by date the priority due to the fact that the charge transaction code has a priority of 0 which overrides the sort setting. This allows the convenience fee to be paid first. Then all remaining charges are paid off base on the system setting of "Priority then Date".
Notes
- todo: Currently tax does not do "over payments". Where do we place over payments for tax? Right now we are simply creating an over payment.