what is the intent of contribution batches listing financial line items instead of contribution total

Question

To see what I'm referring to:

• create a contribution record
• edit the record and alter the amount
• create a new accounting batch
• observe the record in the contribution search

Instead of displaying the contribution record, it displays the financial line items, which in this case is two records. For example, if you initially created the contribution with an amount of $50 and later changed to $25, you would see:

contact   $50
contact  -$25

What is the reasoning behind this? It seems overly complicated and is confusing for users. Simply modifying the total amount for a contribution is not necessarily a formal bookkeeping action where there is money in/money out -- it may simply be fixing a data entry mistake.

My inclination was to treat this as an error, but I'd like to understand the reasoning behind it.

Update/Additional Thoughts

I had a situation shortly after posting this that helped explain the possible value; but I think it also highlights some shortcomings.

The scenario was a contribution that had been created and batch processed, but was later found to be recorded in error. The user could edit the contribution to adjust the amount, and then when creating another accounting batch, the difference (adjustment) was available for processing.

That is a useful and accounting-significant workflow. However, I still think the scenario where a person simply creates a contribution and then modifies it should not be reflected in this way. There is no accounting impact by that action, and listing the change history only confuses things.

So (IMHO) a preferred behavior would be to only create new line item adjustments if the contribution has been batch processed; otherwise it's sufficient to simply edit the record.

More Thoughts

One more issue related to this that I really don't think should be how things function --

If you return at any point to edit a contribution -- for example to add a check number or alter some other value other than the amount -- it results in a positive and negative line item adjustment for the full amount. So if the contribution was $100 and you edit to add the check number and save, when you create an accounting batch you will see:

contact   $100
contact  -$100

That is totally unnecessary and very confusing (also creates a lot of extra records).

Answer 1

Yes, in some cases a change is just a correction of a data entry error, and in others it is an 'actual' business transaction change.

A primary objective of the CiviAccounts effort was to make the system audit-able so that certain generally larger organizations could start using CiviCRM. This requires that all changes are recorded. So for example, if a $50 cash contribution is received and recorded, then it is later changed to $25, the system will have recorded this change. This allows one to track what might be a significant change.

Generally, to prevent cooking the books like this to the benefit of a rogue employee, it is desirable to require a second person to sign-off or approve changes.

I think it would be reasonable feature request or perhaps new extension request to either not record bookkeeping entries for any changes made before a batch is exported or to allow a second person to approve them being deleted before the batch export. It might be more appropriate for certain types of batches, eg ones involving initial data entry, and not for others, eg online transactions.

This would be ideal for use cases like tiny orgs with less formal financial workflows, and for larger orgs that close data entry batches every day after reconciling with a tally of cheque amounts done with a calculator.

With respect to edits creating bookkeeping transactions that reverse then repost the same amount: that was an undesirable outcome of (re-)factoring the code to make it more modular and maintainable. The bookkeeping transaction for an edit can vary extensively based on changes to various fields in the contribution, and to various fields in each of the line items. I agree this leads to undesirable bloat of bookkeeping transactions. In defense of this implementation approach, popular accounting packages do the same thing when saving a change to the cheque number associated with a transaction.