Mixed use of Account Adjustment payments creates inconsistency

Bug #1671856 reported by Bill Erickson
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

Evergreen 2.12 (as of 2.9).

Sites that allow negative balances largely behave the same in EG 2.9+ as they did prior to 2.9 with respect to voiding bills. There is, however, one notable exception. From the 2.9 release notes:

"The account adjustment payment type will also be used for all libraries, regardless of the state of negative balance settings, in cases where overdue fines are adjusted when an overdue item is
marked lost."

So, for example a circulation that's overdue, then checked in with a back-date, will have its overdue fines marked as voided. The same circulation marked lost instead will have its overdue fines remain intact, but balanced with account adjustment payments.

My preference for using account adjustments notwithstanding, requiring two ways of undoing a billing creates a potentially confusing inconsistency, not only for staff but also for those cooking^H^H^H^H^H^Hreviewing the books.

Some possibilities:

1. Revert to traditional voiding for mark-lost for those not using negative balance settings.

I have tested this (by removing force_zero=>1 from AssetCommon:818) with success. I'll push a branch.

2. Support the use of Account Adjustment payments as a wholesale replacement for all automated voiding, regardless of negative balance settings. (I think there may still be cases where true voiding makes sense -- e.g. bills created by human error). I have not considered the implications of this beyond this paragraph.

Tags: circ-billing
Revision history for this message
Bill Erickson (berick) wrote :

Code for option #1 above:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1671856-lost-od-void-not-adjust

I could also see adding a setting to retain the account-adjustment approach for lost overdue voiding, since it could be doubly confusing to go from voiding to adjustments, then back to voiding, for sites already running 2.9+ (i.e. practically everyone). I'll wait on feedback before I do that.

Revision history for this message
Kathy Lussier (klussier) wrote :

Thanks Bill! I like providing a more consistent experience for staff. I think #1 is the path that probably would cause the least disruption at this point, even though I was in favor of #2 way back when the new code was first introduced as it provides a consistent experience across all libraries, no matter how they adjusted their negative balance settings.

As far as an option to retain existing behavior for those sites that have become accustomed to it, I don't think this is the first time the inconsistent behavior has caused confusion at sites that allow negative balances. See bug 1593815. My inclination is to not provide that additional setting. However, all of our libraries prohibit negative balance settings, and it would be good to hear from those that have been experiencing this inconsistent behavior. Perhaps April Durrence, who weighed in on the previous bug, would be a good person to reach out to.

Revision history for this message
Dan Wells (dbw2) wrote :

I remain open-minded about it, but at this point would not want see this behavior reverted. The goal has always been for adjustments and voids to usefully coexist (now and into the future), and our library successfully uses both even though it *does* allow negative balances / refunds. If an "adjustment" better models what we are doing when we make these overdues "go away", then the issue isn't really with the underlying structures, so reverting this doesn't really address the problem.

I've got my own ideas about how to proceed (i.e. billing UI changes), but I am always interested in seeing more sides of a problem. Bill, when you say "requiring two ways of undoing a billing", do you mean two ways to try and undo what the system has already done, or two ways to zero-out a bill in the first place? Or something else? Also, how do you see this being a point of pain for your staff (perhaps other than the initial exposure to the adjustment feature)?

Even if we adopt this proposal, there are still other ways for staff to create adjustments. As close as we might be to having it already (through various options and permissions), I think we should resist the temptation for a "big switch" to turn all adjustments (or voids) off. I believe the end result would inevitably mean one or the other becoming less than fully supported by the community, and that is precisely what I hope to avoid.

Thanks!

Revision history for this message
Bill Erickson (berick) wrote :

Thanks, Dan! I'm not exactly sure how to answer your undo question. My concern for now is only that when an overdue fine needs to be, er, disabled by the system, sometimes it's voided, sometimes it's adjusted.

1. Back-dated checkin overdues are voided.
2. Claims-returned overdues are adjusted.
3. Amnesty checkin overdues are voided.
4. Mark-Lost overdues are adjusted.

Why the variation? Setting aside staff concerns for the moment, I'd just like to make sure I understand it.

If I were to implement a feature tomorrow that required overdues to be undone, which would I use and why (assuming no negative fines settings in place)?

I also agree we shouldn't turn anything off, but for me that's assuming adjustments and voids each serve distinct purposes. The 4 events listed above are very similar and should, I would think, all be addressed in the same way.

Revision history for this message
April Durrence (april-durrence) wrote :

Adding my comments here and in bug 1593815 to say that Bill's argument seems sound to me that the behavior for all the different "void" scenarios should be consistent, either always use void or always use account adjustment.

The issue I continue to have with the account adjustment feature is that it displays as a payment in the patron account. That is not a factual or true representation of the transaction since no payment was ever made (and certainly not by the patron) which causes significant confusion and frustration on the part of staff, since they would have to go deeper into billing to recognize that an account adjustment is in play.

Revision history for this message
Kathy Lussier (klussier) wrote :

I wanted to bring attention back to this bug to see if we can reach a decision on Bill's proposal. Although our libraries are all using the Prohibit Negative Balance settings, I can see where libraries that continue to use voiding would want the behavior to be consistent whenever a fine or fee is removed. With that in mind, I support the idea behind Bill's proposed change.

Although UI changes will help (we are very excited to see what they look like), but I think those could be done regardless of what happens with this branch. I also am not too concerned about one approach receiving less support than the other. Based on other discussions I've seen around negative balances, there seem to be a balanced mix of libraries in the community using both options.

Revision history for this message
April Durrence (april-durrence) wrote :

These automated voids still seem to be functioning in addition to the account adjustment feature, which means that patrons are credited too much when fines are voided in addition to the account adjustments for a double credit, causing an incorrect reduced amount owed or a negative balance on the patron account. The account adjustments have the addition drawback of being mischaracterized as payments.

Here is a recent patron transaction that demonstrates the problem automated behavior:

8/12/17 – Patron checks out a book
9/2/17 – Item is due, but not returned
9/3/17 – Overdue fines of $ .25/day begin to accrue up to a total of $8.75
10/15/17 – item is marked LOST, $16 billed to patron (cost of book) and $8.75 in fines voided
11/13/17 – Item is returned by patron - $16 lost billing voided and $8.75 in fines reinstated
11/14/17 – Item marked damaged, patron billed $16 for cost of item; overdue charges voided again because replaced by damage billing

At some point in this process, the account adjustments also occurred, meaning that the patron received an unwarranted additional offset of $8.75, leaving an outstanding balance of $7.25 instead of the correct amount of $16. Therefore, patron only paid $7.25, when she should have paid $16. Because the account adjustments show as a payment, the patron’s Bill History inaccurately shows a $16 total payment.

I don't know if the negative balance settings would have made a difference in this case, since no negative balance was created due to the amount owed. The billing and account adjustments occurred before our recent upgrade from 2.9.4 to 2.12.7, so I am unsure if the behavior would be the same in 2.12.

Revision history for this message
Dan Wells (dbw2) wrote :

Quoting Bill:
"1. Back-dated checkin overdues are voided.
2. Claims-returned overdues are adjusted.
3. Amnesty checkin overdues are voided.
4. Mark-Lost overdues are adjusted.

Why the variation? Setting aside staff concerns for the moment, I'd just like to make sure I understand it."

First, sorry for not replying when this was asked. I will do my best to answer well.

The intended distinction is that a void is used where an entry should be considered invalid, while an adjustment is used where an entry is valid, but the library is opting to not enforce it. By that logic, I think all of these four cases would be correct in the current state with the exception of #3, which I think would be better applied as an adjustment.

In essence, one might think of void as a very close cousin to the deleted flag.

I can understand how one might argue against this subtle distinction, but it does have real benefits:

1) If generating a billing statement view, it makes sense to hide voids, but to show adjustments. This is particularly true if the view is patron-facing, as it makes little sense to show the patron our mistakes which we have deemed invalid, but it makes a lot of sense to show them how we have credited an account to their benefit.

2) A library may wish to better understand how its policies are affecting revenue. A voided billing should never be considered as "lost" revenue, while most adjustments could be considered in that light.

3) Voiding should be a binary decision, while adjustments can be circumstantially more flexible. It makes no more sense to "partially void" a single event any more than such a thing can be partially deleted or partially declared invalid. Adjustments are more flexible and allow for greater subtlety, but on the examination end thus require more scrutiny.

I know I have been given more than enough time to implement a more UI oriented fix, but I am hoping to be granted a little more time to get something finished for the 3.1 beta. I am also concerned with how this bug and a few others interact, and so am creating a 3.1 roadmap wiki page dedicated to organizing around billing improvements, and taking an active role in a variety of proposed improvements.

Sincerely,
Dan

Revision history for this message
April Durrence (april-durrence) wrote :

Hi everyone, I am going hope that I am not causing anybody heartburn by chiming in again. :) We have had another help ticket today from a library director regarding the understandable misinterpretation caused by account adjustments being calculated as payments and displayed in the Total Paid column in the patron account. On the main billing screen, it appears to staff that these are payments made by the patron unless they take the time to go to the Full Details screen for each and every line item, see whether account adjustment is the payment type, and understand what that means (the patron hasn't paid that amount). I am wondering if, in the discussion of the laudable intent of account adjustments, whether there is room to discuss an alternate option, such as displaying account adjustments in their own separate column? Perhaps it would even make sense to calculate Forgive, Goods, and Work "payments" in the Adjustments column, as those also cause staff to think patrons have paid something when no money has actually changed hands.

Perhaps something like:

Total Billed = original amount due
Total Paid = only monetary payments (cash, check, credit card)
Non-monetary Adjustments = account adjustments, forgive, goods, and work "payments"
Balance Owed = remaining balance after monetary and non-monetary "payments" are subtracted

If that is too radical (or requires too much change to code), even having account adjustments listed in their own column (leaving aside other forms of non-monetary payment) would be a big help to give front line staff a clearer picture.

Revision history for this message
Dan Wells (dbw2) wrote :

April, thank you for chiming in again. It does cause me a little heartburn to see this come up again, but I deserve it :)

I think what you are proposing is exactly the right direction for bringing clarity, and some variation of these thoughts will be part of the branch I put forward. With beta deadlines fast approaching, it is time for me to "put up or shut up", and I remain hopeful for the former.

Revision history for this message
April Durrence (april-durrence) wrote :

Thanks, Dan, and I am sorry for the heartburn. I wish you much coding success. Anything you are able to achieve that allows staff to easily distinguish non-monetary offsets/adjustments from monetary payments (actually made by patrons) will be a huge UX win!

Revision history for this message
Dawn Dale (ddale) wrote :

Hi All,

I agree with April. In order to know what the patron actually paid and what was voided or adjusted having a separate place for adjusted to show up makes sense to me and would solve confusion on the part of staff. Even if we just added a new column in the bill full details that shows adjustments beside voids. Adjustment could be true or false the same as voids. Then the amount actually billed would remain in the billed full details. Adjustments would not be mistaken for payments.

Revision history for this message
Bill Erickson (berick) wrote :

Just popping in for a belated Thanks Dan for the reply to my questions.

Changed in evergreen:
importance: Undecided → Medium
status: New → Confirmed
tags: added: circ-billing
removed: billing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.