Kathy and Michele,

Thank you for the thoughtful responses!

First, I want to point out that I share Dan's opinions, pretty much to a T.  That said, though, I want to address some specific points you bring up (not in order):

> I concur that flaws exist in the current voiding logic. Voiding means it
> never happened - that makes logical sense. But combining “that never
> happened” with payments doesn’t make logical sense.

I disagree that Evergreen is trying to combine them.  The fact that the library received money for an event they agree they should not have doesn't mean (from a logic standpoint) that the event now should exist.

However, if the policy is that there can be no refunds, even in the face of "mis-payment", then that is a separate conceptual issue from voiding.  Perhaps the implementation of a "shouldn't have happened, but did, and we'll stop trying to accept any more payments on the billing" payment type is more correct (and that's effectively what Jason implemented, IIUC), but that is not voiding from an accounting perspective.  In other words, what Dan suggests -- void when you can, but apply a "billing reversal" payment (read: voidish-credity-thing-of-some-sort) when you can't -- seems most correct.

> Voiding bills that have been forgiven does’t make logical sense. This
> action credits a patron account for money that the patron never paid.

I agree completely.  In fact, I would say that the forgive payment should likewise be voided.  The problem is, of course, that we don't have a direct, persistent link between billings and payments, because there is no one-to-one equivalence ("we billed $0.10 200 times" and "we accepted $20 to cover the balance").

Jeff Godin has been polishing a branch of some of my 1.2-era reporting-oriented code to assist with that linking, and it could certainly be leveraged to logically rectify the problems here.  There's much more to the problem than that, but it does provide part of the way forward.

As an alternative, imagine in the "forgive voided billings" case that instead of simply leaving the forgives alone, or removing or voiding them, we void the billings (as today) and then shrink any forgives to the point of $0 (and then remove them) until we either run out of forgives to shrink or the balance hits $0.  I think refining the definition of "forgive" to mean a cap instead of fixed amount makes sense, especially in light of the voided-forgiven problem.

This does not cover all cases, certainly, but it would address the forgive-causing-credit issue.

> Yet another “credit” payment type while still keeping the existing
> void functionality would likely make dealing with bills harder rather
> than easier for staff.

I agree that "credit" would be a bad name... but "void" is not right either.  What about "billing reversal"? That seems unambiguous and self-explanatory to me ... but, I was involved in naming "conjoined items" and "vandelay", so what makes sense to me may not be useful to front-line librarians. ;)

> When a lost item is currently returned to the library and there are
> no negative balance scenarios, the billing transaction simply
> disappears from the patron's record. If a patron, who has received
> the bill, then pays for it or brings it to the circ desk with a question,
> the circ person can't easily pull up the patron record to see what
> happened with the bill. 

I can certainly see what you mean, but if being able to see the voided billings in billing timestamp order is an issue (and I can certainly understand if it is) then minor development to allow showing/hiding these rows in-line, in the item history and billing detail UIs, seems do-able.

Having said all of this, I think there is implementable middle ground.  As Dan suggests, separating the concepts of "void early" with "stop payment requests late" could probably leverage a good bit of what Jason has done.  I might even suggest taking it a step further and suggest a setting that switches between the two.  This would avoid your concerns about void-vs-voidy_credit causing confusion, and would also avoid redefining current semantics.

And, finally, I have one very big, practical maintenance warning to raise about the current implementation as offered: it will absolutely break existing reports, and potentially local and third party tools.  There may be ways to mitigate the problems, but I'm not sure we can provide even 80% coverage in reality.

We saw this recently with the redefinition of the "floating" field on asset.copy to mean a depth instead of an on/off flag.  I'm very disappointed that that change slipped through, and I would have yelled STOP if I'd seen it, at least so we could discuss it, but I can't look at every database commit.  This one is a bigger change, and likely to break much more "invisible" code.

Thanks, all, for your time and effort (especially Jason and Dan) on this.  I'm confident we'll end up with something that everyone can work with.