Funded Payments: recording how payments have been spent

[bobintetley]

This is a ticket to consider how we might record how donations have been spent.

We had a user who received large donations from people. When poorer folks would adopt animals, they would charge them a token amount like $25 and take the rest from one of these donations. They were doing it by breaking the payment up into smaller payments so they could see where that donation had been spent. Obviously, by doing this though, the original receipt of the donation was lost, and it looked like that person had made lots of payments for adoptions fees on different animals.

From an auditing/data loss point of view, this is pretty bad. But it would be nice if there were a way to record what a payment had been spent on.

As a first stab/thought at it:

1. Use a simple self-join in the ownerdonation table for a new FundedByOwnerDonationID column. This would allow you to pick a payment that the current payment was funded from.
2. In order to stop double counting, all of the payment reports would need to exclude payments where this field was set.
3. Choosing a funding payment would make the screen hide the payment method, check no, tax and other fields that don't make sense for a funded payment.
4. Funded payments would also not create matching transactions in the accounts.

Given how little of the payment info is needed, would a new table/screen be better? Probaby not, but worth considering.

These funded payments should be displayed differently in the list so it's clear what they are.

Consideration needs to be given as to how funded payments can be chosen. I'm thinking an autocomplete widget where the user types the receipt number of the funded payment and the dropdown list has some basic info (the receipt number, payment amount and payee)

Since this might potentially cause confusion, this feature should be gated behind a config option and off by default.

Needs documenting clearly in the manual and a callout next to the "funded by" field.

[bobintetley]

We could also add reports to show what donations a person has made has funded, and similarly how much is "left unspent" of a donation.

[JayS67]

This could also be good use in instances where adopters take 2 animals and but pay both adoption fees in one transaction.

And perhaps in instances where multiple costs for the same supplier with different invoices are paid out in one bulk transaction.

[adamdspencer77]

I've been thinking about this and wondered if this simple(ish) way to use the existing tools to create the data required would be preferable.

• A large donation is made by Eric Boot that you would like to track as described above
• A new Account is created labelled "Bank::Eric Boot Fund"
• The large donation is paid into this account from Eric Boot's person record.
• A Payment Type is created labelled "Eric Boot Adoption Fund" with the Account set to "Bank::Eric Boot Fund"
• As animals are adopted and the payments are made, users can choose "Eric Boot Adoption Fund" to fund any adoptions that they would like to draw from the large donation.
• Similar Payment Types that draw from this account could be created for "Eric Boot Welfare Assistance", "Eric Boot Neutering Voucher" to allow tracking of other ways that the fund may be used.
• The transactions for this account then provide the breakdown of where the original donation ended up and how much is left.

[bobintetley]

I've been thinking about this and wondered if this simple(ish) way to use the existing tools to create the data required would be preferable.

While this could work, it means that users (or the system) would have to create a new payment type and nominal account for every large donation. This would quickly get pretty unwieldy and you'd end up with many accounts. It still requires changes to the system as well. Also, the use of the physical bank account type could cause confusion as they generally represent real transactions.

I think the method outlined with a self join on ownerdonation could solve the issue fairly well, as these transactions then don't become "real" ones and it's easy to report on.

We could try building this as a prototype to see whether it's worth it.