Incorrect allocation of payment on an edited multi-line item event registration
On default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
- Create event with priceset with two fields, first with financial Type Event fees, second with FT of Event Fees 2.
- Register in event with payment of say $25 for first ticket (Event Fees) and $10 for second ticket (Event fees 2), total $35.
- Edit Event registration. Click Change selections. Change quantity for second field from 1 to 5, line item total of $50, contribution total of $75, total paid $35. Save. Balance is $40.
- Click Record Payment.
To review the database records that would be sent to accounting applications, you can:
- Navigation to Contributions > Accounting Batches > New Batch, create a batch, assign the relevant transactions of $35 (original payment), $40 (edit with implied purchase with pay later) and $40 (payment of outstanding balance) to the new batch and export to csv.
- At Contributions > Accounting Batches > Open Batches, select the batch just created and export as csv, open and view the resulting transactions: Financial_Transactions_3_20180807210702.csv
The initial purchase (first two lines) and the edit of the order to increase the number of event fees from $10 to $50 are (the third line) are all correct. However, the payment of the outstanding balance is incorrect. Instead of a single line with a $40 payment (Debit Bank Account 1150, Credit Accounts Receivable 1200), there are two lines:
Debit Bank Account 1150, Credit Accounts Receivable 1200: $16.67, Item description: Member Debit Bank Account 1150, Credit Accounts Receivable 1200: $23.33, Item description: Guest
It seems the payment is being equally allocated to the two line items in proportion to their current line item total. If there had been a simple partial payment, this would be correct. The algorithm for determining the allocation should not be based on the line item totals (or more accurately, their corresponding financial_item.amount), but on the amount of each financial item that has been paid so far (entity_financial_trxn.amount for the entries linking financial_trxn records to these financial_item records.
We should first verify that the entity_financial_trxn.amount fields are being properly recorded. Then it will be apparent that sum(entity_financial_trxn.amount) pointing to first financial_item is $25, the same as its financial_item.amount, while sum(entity_financial_trxn.amount) pointing to second financial_item is $10, which is $40 less than the financial_item.amount. So all of the second payment would be allocated to a single new entity_financial_trxn.amount of $40 pointing to the second financial_item.
This is not a high priority since the two entries add up to the same as the proposed single entry from an accounting perspective. Having two general journal entries is confusing, and the item description of one is inaccurate, so a fix would be good.