Marking a Long Overdue transaction Lost adds a second bill to the patron record

Another approach would be that if an item is marked Lost that has already been marked Long Overdue, that it voids the previous Long Overdue bill & Long Overdue Processing Fee, and adds the Lost bill and Lost Processing Fee. In most cases, the total owed would end up being the same, but it might make the history shown in the full bill details easier to understand.

Adding a link to a relevant IRC discussion:

http://irc.evergreen-ils.org/evergreen/2016-05-25#i_250217

Adding a link to a related bug:

https://bugs.launchpad.net/evergreen/+bug/1661754

A quick fix which only prevents a staff member from marking a Long Overdue item Lost in the client (xul and webby).

My working branch is here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1562061_fix_double_billing_when_long_overdue_becomes_lost

This fix removes the pop up that prevents a Long Overdue item from being marked Lost. It then voids or zeroes the Long Overdue billing when the Lost bill is applied. It does not address processing fees, however. If anyone feels that's an issue, I can take another look.

Michele, thank you for your work on this. Looking over this code, it appears it would work, but I have more general concerns that "Long Overdue" vs. "Lost" is becoming a bit of a push-me-pull-you with a variety of bugs (this one and a few others) seemingly coming from different mental models about what these terms mean, and how they are meant to be used, either in tandem or as functional alternatives.

In this particular case, I am imagining a more judicious use of stop-fines might solve the problem in a more generalized way. In essence, "OVERDUE" might function as a something like a "soft" stop-fines, while "LONG-OVERDUE" or "LOST" could be a "hard" or "final" stop fines. If we can agree to these more conceptual ideas, then the code becomes more resilient for any future case without needing to create and propagate exceptions all over. What do you think?

At any rate, I am going to start drafting a poll to see where we are at as a community on our collective needs, and what points (if any) might benefit from hashing out. It feels like there would be value in that, but it's hard to tell for sure without trying.

Dan, Thanks for reviewing this. I certainly agree that there are various interpretations and implementations out there of the currently available states for a circulation transaction, and I'm all for a larger discussion to develop some clearly defined processes that manage overdue circs and allow an abandoned transaction to die a natural death. I don't think this bug fix goes against that, it's intended to fix existing functionality that never played well together.

My understanding about "Long Overdue" was that it grew out of a need to distinguish between items declared "Lost" by patrons and items that weren't returned. It's certainly not unusual for a Long Overdue item to be declared Lost at some point, and this proposed fix allows that to happen.

Judicious use of stop-fines could certainly better define the state of a transaction, but it's not highly visible. Use of the Long Overdue and Lost processing provides many options for controlling catalog visibility of overdue items, blocking of patron privileges when necessary, and providing clearly understandable account information to staff users as they serve their patrons.

I'll briefly describe the process we have developed in our mixed consortium of public and academic libraries as a possible discussion starter:

At six weeks overdue:

- Mark items Long Overdue.
- Block some patron privileges based on the long overdue item.
- Staff can easily distinguish mildly overdue items from long overdue items when serving their patrons.
- Patrons can restore their privileges themselves by paying the bill via credit card while logged into their account.
- If checked in, the Long Overdue billing is adjusted and overdue fines reinstated.

At one year overdue:

- Mark items Lost.
- Status Lost items are not opac visible.
- If checked in, the Lost billing will be adjusted and overdue fines reinstated.

At five years overdue:

- Items are checked in and deleted.
- Associated patrons have been long expired at this point and are purged.

Just adding a screenshot of the Full Details of a transaction where a Long Overdue item was made Lost. This shows the adjusted Long Overdue billing.

And one more for a transaction with overdue fines and a payment.

For background (and, I don't think this should stop the fix here going in), Long Overdue was originally designed as a sort of "soft lost" on the way to declaring complete Lost-ness. This comes from a (IIRC) PINES workflow where an item would go Long Overdue after 90 days, and then Lost after 180. There would be different fees assessed at each step. Obviously the feature(s) have grown in use cases since then, but I wanted to give the history. Software is a living document... :)

I can't speak to the original intentions of the development of Long Overdue, but in PINES we basically use it as an automated form of Lost. If someone tells us that they lost an item or if they claim they've returned it but we can't find it after a set amount of time, we will manually mark an item Lost. If they simply don't return it, it automatically gets marked Long Overdue at 180 days.

In both cases, we bill the full item price plus processing fee and we generate an automated notice via action triggers. (And in most cases, the patron is blocked because they'll exceed the fine threshold.)

We direct our libraries not to change the status from Long Overdue to Lost, but if we could do so without triggering a double-billing or triggering another action trigger notification or triggering something else I haven't considered, then I could see it being useful.

I am testing the patch for this bug.

First, sorry for sitting on this bug since spring!

This is one of two bugs I am hoping to move forward for bug-squashing this week, but since Dawn has taken over testing on it, I figured I better give an update on where we we are at with this locally.

In short, as Michele anticipated, we are seeing issues with how processing fees are handled, and ending up with duplicates. I am preparing a simple branch with an alternative strategy, and will post that for consideration later today.

Dan

I can retest this after Dan updates the bug. Currently, when I mark a longoverdue item "lost by patron" nothing changes. The item stays in the status of longoverdue and no further billings are added.

I just found out the patch was not applied when I tested. I will test again.

Okay, I pushed a branch here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1562061_avoid_lost_rebilling

The branch is two commits, one with minimal changes for easier reading, then a second with some general code reformatting/refactoring/commenting to clean things up. Commit one shows the concept, but you really want both.

In essence, it takes the tack of making lost and long-overdue billing exclusive events; once one has happened the other cannot. Any attempt to mark something lost after it is already long-overdue will change the item status and potentially process other lost-based events and penalties (configuration dependent), but it will not touch the billing.

I think this strategy has a great advantage in it's simplicity while still covering known use cases. We do not need to concern ourselves with every possible interaction lost fines/fees/voids/payments/credits and long-overdue fines/fees/voids/payments/credits, as you just get one or the other.

Dan

Thanks, Dan. I will test this tomorrow and update the bug.

Hi Dan,

I tested this and did not see the status change from longoverdue to lost. It appeared as nothing happened except the screen refreshed. Maybe if a popup message that states longoverude cannot be changed to lost because they are in essence the same? The item still remains longoverdue and the bills remain the same. I will be happy to test again if I need to.

Thanks, Dawn

Hello Dawn,

Thanks for testing!

Are you sure the item status did not change? The default columns do not actually show the Copy/Item status, only the stop fines reason, which in my branch will not change. If you add the Copy Status column to the items out view, or look at the item itself using Item Status, you should see the new 'Lost' status.

Please let me know if you do not. It is unfortunate that, by default, stop_fines is prominently displayed while item status is not, so maybe that needs to be reconsidered a bit.

Sincerely,
Dan

Hi Dan,

Yes, you are correct. The status did change and I was looking at the stop
fine reason on the items out screen. That being said staff are still going
to think nothing happened if they do not have the item status column
displayed. Maybe a wish list would be for a popup message to confirm the
change was made.

Thank you for all your work on this, Dan. I will sign off on the bug fix.

Dawn Dale
PINES Services Specialist, Circulation
Georgia Public Library Service
1800 Century Place Suite 150
Atlanta, GA 30345
404-235-7136
<email address hidden>

** The GPLS office is in the midst of relocating offices. We may be reached
by all of the current mechanisms during the transition, but to ensure the
most prompt response, please use the Help
Desk: https://help.georgialibraries.org
<https://www.google.com/url?q=https://help.georgialibraries.org&sa=D&source=hangouts&ust=1531922186441000&usg=AFQjCNEd0qVYxcDyllXYUKTaXz6p7bPNRA>*

On Fri, Sep 14, 2018 at 3:11 PM, Dan Wells <email address hidden> wrote:

> Hello Dawn,
>
> Thanks for testing!
>
> Are you sure the item status did not change? The default columns do not
> actually show the Copy/Item status, only the stop fines reason, which in
> my branch will not change. If you add the Copy Status column to the
> items out view, or look at the item itself using Item Status, you should
> see the new 'Lost' status.
>
> Please let me know if you do not. It is unfortunate that, by default,
> stop_fines is prominently displayed while item status is not, so maybe
> that needs to be reconsidered a bit.
>
> Sincerely,
> Dan
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1562061
>
> Title:
> Marking a Long Overdue transaction Lost adds a second bill to the
> patron record
>
> Status in Evergreen:
> Confirmed
> Status in Evergreen 3.0 series:
> New
>
> Bug description:
> If a patron has been billed for an item using a Mark Long-Overdue
> action trigger, it is possible to add a second bill to the patron's
> record for the item in a couple of ways.
>
> First, marking the long overdue item Lost by patron will add a second
> bill. To reproduce:
>
> - Retrieve a patron record that has an item that is Long Overdue.
> - Select the Long Overdue transaction and choose Mark Item Lost(by
> patron) from the actions menu.
> - On the patron's bills screen, select the now Lost transaction and view
> the Full Details.
>
> Under the billings, you will see a bill for the cost of the item with
> the billing type Lost Materials as well as a bill with billing type
> Long Overdue Materials.
>
> Note that the client will not allow "Mark Lost(by patron)" if an item
> has already been marked Lost.
>
> Second, using the Mark Lost action trigger after the item is already
> Long Overdue will add a second bill, one with the billing type "Long
> Overdue Materials" and another with the billing type "Lost Materials"
>
> Once the patron has been billed for the cost of the item, a second
> system generated billing for the cost should not be allowed.
>
> To manage notifications about this bug go to:
> https://bugs.launchp...

After further testing the patch does work. The item status column must be displayed to see the change in the patron account.

I have tested this code and consent to signing off on it with my name, Dawn Dale and my email address, <email address hidden>

I also did some testing of this code, and I like the idea that it makes Lost and Long Overdue billings exclusive, so that the patron can only be billed once.

Some observations about when a Long Overdue item is marked Lost:

- As Dan said, the billings are not touched.

- The row in action.circulation does not change in any way. The stop_fines retains the value LONGOVERDUE.

- The copy fields: editor, edit_date, status, and status_changed_time all get updated as the Lost status is assigned to the copy.

This all makes good sense and leaves a clear trail to help in understanding the history of the transaction.

Unfortunately, I found problems with the ou settings that dictate how to handle Lost/Long Overdue billings should the long-overdue-marked-lost item be checked in:

circ.void_lost_on_checkin - Void lost item billing when returned
circ.void_longoverdue_on_checkin - Void Long-Overdue Item Billing When Returned

Even with both of these set to TRUE (as we have in our consortium), the billing for the long-overdue-marked-lost item will not be voided. The status is Lost, but there is no Lost billing to void since the Long Overdue billing remains.

Perhaps combining the mirrored settings related to voiding billings we currently have for Long Overdue and Lost could solve this problem - and have the added benefit of shaving off a few YAOUS's.

Thanks for your work on this, Dan. I would love it if we could get this to a state where we could put it in production.

Removing the pullrequest tag due to Michele's testing.