[OPEN-ILS-GENERAL] Negative balances and void payment types

[Kathy Lussier]

Hi all,

Following up on a suggestion Chris Sharp made to the Evergreen 
developers list that more development discussion happen on the public 
lists - http://markmail.org/message/cueotsw7ck7crkvd, I would like to 
bring forward a discussion that has been taking place on 
https://bugs.launchpad.net/evergreen/+bug/1198465.

MassLNC contracted with Jason Stephenson to do several projects in the 
area of billing, including this project that would give libraries more 
control over whether negative balances appear on user's record. As many 
of you know, if you configure Evergreen to void a bill when a lost item 
is returned and the patron has already paid for that lost item, a 
negative balance is applied to the patron's record. Some libraries will 
refund these lost fees, so the negative balance makes sense, but most of 
our libraries are unable to issue refunds. Jason shared his plans 
regarding the project on this list back in July - 
http://markmail.org/message/rbz6atf7j2zhe2k3.

I don't think there is any disagreement that fixing the negative balance 
issue is a good thing, but there have been disagreements about the 
approach taken.

To approach this problem, Jason changed the way voiding works in 
Evergreen. Instead of entirely voiding a payment, the system would start 
using a void payment type, similar to the cash, credit, and forgive 
payment types that are already in use. This would allow the system to 
partially void bills that would otherwise show a negative balance. 
Quoting from his original specs:

> I believe that a new payment type will need to be added to handle 
> voiding of bills. This new payment type will replace the current void 
> logic that simply flags bills as voided.
>
> This new payment type is needed because the current way that Evergreen 
> voids bills requires that all voids happen in the same increments as 
> the bills themselves. This prevents voiding of a partial bill or a 
> bill that has had a partial payment applied.
>
Upon a week's worth reflection on the original code and the alternate 
approaches that have been suggested, I would like to advocate for the 
approach that Jason originally proposed for this project. The void 
payment type makes sense to me for several reasons:

- As was mentioned in the Launchpad discussion, it provides something 
akin to an accounting ledger of credits and debits. No bills simply 
disappear because they have been voided.

- The void payment type works the same way as other credits on the 
patrons' records, providing a level of consistency to the end user.

- There have been suggestions to rename things to fine_reversal or 
account_adjustment. However, I think "void" is the term that is most 
understandable to our users. Conceptually, when a lost book is returned, 
the billing shouldn't have happened and therefore should be voided. For 
our circ desk staff, there is no distinction in the terminology used for 
bills that are fully voided or partially voided.

- After spending many hours testing this development, I can say the 
learning curve for this new approach is small. Since void payments is 
using the same logic as our other payment types, it is something I 
believe staff can easily understand. When a bill is voided, it no longer 
disappears on the patron record, but remains  with a clear indication 
that the bill was voided, making it very easy for staff to track the 
history of a bill. I have some screenshots at 
http://www.screencast.com/t/ETwr4HCz0 and 
http://www.screencast.com/t/7zgMIiQqu if anyone is interested in seeing 
how it looks to the end user.

I also am concerned about an approach that would make voids work one 
with in a certain set of circumstances and in another way for another 
set of circumstances. One thing that can be confusing for our users is 
when the system does things in a particular way in some cases, but not 
in others. It also makes training and documentation more difficult. I 
wouldn't want to exacerbate this problem.

I agree that there are bugs with this code that needs to be fixed. 
However, having been involved in multiple development project over the 
past few years, I can't say this code has more bugs than other code when 
it is first submitted. Those are fixable. I also understand from the LP 
discussion that the code may affect existing reports. I hope there are 
ways to mitigate this issue, but am I correct in assuming this is likely 
to happen whenever there is an infrastructure change? This bug submitted 
to Launchpad yesterday regarding another recent infrastructure change 
makes me think it isn't unique - 
https://bugs.launchpad.net/evergreen/+bug/1287967. Does this mean we 
shouldn't sometimes look at infrastructure changes when there is an 
overall benefit to the change?

Thank you all for hearing me out on this issue. This functionality is 
something our users are looking forward to seeing in Evergreen, and I 
hope we can come to some kind of agreement.

Kathy

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier