[OPEN-ILS-GENERAL] Negative balances and void payment types
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
Re: [OPEN-ILS-GENERAL] Negative balances and void payment types
Kathy, I'm trying to make my response here as in-depth as your email deserves. Please bear with me as I work through my thought on this. I've considered it quite a bit in isolation, and I have been following along with the conversation over the last few weeks, but it is a complicated issue that requires a great deal of focused attention to reason about correctly. I apologize in advance if I misrepresent anyone's position or goals, but I've tried my best to make my understanding of the desired result the focus of my response here. On Wed, Mar 5, 2014 at 12:18 PM, Kathy Lussier kluss...@masslnc.org wrote: 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. This presupposes a definition for void which (from a historical perspective) does not match the intent of the code, though the statements about voiding are, in themselves, completely correct. I will address that below, but I just want to put a pin in this point. 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. Please, all, take this with a big pinch of pedant-flavored salt (and feel free to skip this paragraph if you'd rather not see more pedantry from me), but there's just no such thing as partially voided. It's correct to say that in a double-entry ledger you can use a balancing credit to partially or completely cancel a debit, as Jason mentions in the LP thread, but that's not voiding. Voiding, as it exists in double-entry accounting, means exactly strike through this, because it was a mistake (or premature or incorrect) and does not match reality, so we will ignore its effects. For instance, in QuickBooks (only because I happen to have the docs for that handy), voiding zeros the effective amount of the ledger entry. Now, QB is no paragon of industrial strength double-entry accounting software, but it's certainly more right than wrong. (And, while I hesitate to cite them, MS Office's docs say basically the same thing about voiding ... though I'm not sure that helps my case. ;) ). My point is that void has a well-defined meaning, and in all cases where we could compare what Evergreen does to another accounting software package,
Re: [OPEN-ILS-GENERAL] Negative balances and void payment types
Thanks, Dan. I see where my thinking went astray. I was imagining (as a final implementation) a design where we leverage the payment-by-billing-type code to walk backwards through the line items of a transaction, voiding anything with no payments (where appropriate) until we hit a billing with a payment, at which point we have to start using balancing credits. So, I was jumping to a version of your (2), basically. I think I agree with your assertion about overdues being adjusted instead of voided -- that really is a credit the patron situation which is separate from both credit (not card) and forgive payment types. Un-adjusting those billings when the item is found would probably be best done as a void of the adjustment from a logical standpoint, but simply deleting them might be easier to deal with. Obviously, credit-style payments are the only kind that should be delete-able, so perhaps a new level in the inheritance hierarchy would be in order, which could also serve as the level at which the billing link might be added to those credit type payments. And now I've digressed far into implementation details and should stop (on this thread, at least) ... but, suffice it to say, I do certainly see an internally self-consistent and manageable path forward to address not just the specific issue of negative patron balances, but a host of currently-circuitous workarounds and oddities with complex billing situations. My misunderstanding (and belief that (2) would be the ideal) aside, and addressing your branch specifically with regard to the core point of this discussion, I maintain that reimplementing void is the primary danger -- for the reasons I listed up-thread -- and I really want to see if my belief that your adjustments to Jason's work fill the needs of MassLNC. I'm pretty confident that they will, even more so now that you've clarified that the adjust behavior does effectively replace the current void behavior. Again, thanks, Dan and all! On Wed, Mar 5, 2014 at 5:10 PM, Dan Wells d...@calvin.edu wrote: Mike and Kathy, thanks for taking the time it took to craft your thorough responses. It really helps outline many of the areas of contention. I want to point out, though, that my current branch doesn't do quite what is stated in Mike's email. There are really three ways we could go when applying the new logic: 1) Always* do voids (old way) 2) Do voids where you can, adjust where you need to (mixed way) 3) Always* do adjustments (new way) My current code lets you pick between 1 and 3, rather than go the extra mile and try to be context sensitive (the mixed way). (*It also lets you set a different always-ness for lost vs overdue, if desired.) Not saying we can't or shouldn't work in a direction where the code is context sensitive, but it seemed like early adopters were putting a high value on sameness of the transactions, so the first crack went that route. Also, I want to highlight something else about my branch which I noted in one of my long comments on the LP bug: c) * The one place where the code now always adjusts (never voids) is for overdue-lost behavior. Overdue fines are adjusted to zero (if the option is on), not voided. I think this makes sense logically (they still happened, we are just not charging for them), and it makes it much easier to accurately reinstate these fines if the lost item is returned (if *that* option is on). Basically, I believe that voiding overdues when marking an item lost is a grey area for our technical definition of void (especially if plan to possibly reinstate them), so I took it the other direction in that one case. This is primarily an implementation choice, and not particular crucial to the discussion, but since it is used in a couple of Mike's examples, I wanted to point it out. Thanks again, Dan -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
