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
[email protected]
Twitter: http://www.twitter.com/kmlussier
