Bug 22740 - Automatically change lost status when item is paid for
Summary: Automatically change lost status when item is paid for
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement with 9 votes (vote)
Assignee: Jacob O'Mara
QA Contact: Testopia
URL: https://docs.google.com/document/d/1f...
Keywords:
Depends on:
Blocks: 36460
  Show dependency treegraph
 
Reported: 2019-04-18 18:56 UTC by Martha Fuerst
Modified: 2024-03-28 19:53 UTC (History)
18 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martha Fuerst 2019-04-18 18:56:11 UTC
When patrons pay for a lost item, our staff change the Lost status of the item from "Lost" or "Long overdue Lost" to "Lost and Paid For." This helps make distinctions in reports and in other workflows.

With the advent of online payment options (PayPal), it adds what feels like extra work for us to hunt down these items and make this change.

In both cases it would be beneficial if paying for an item resulted in the item's Lost status being changed to a specified authorized value.
Comment 1 Kim Robbins 2019-05-10 12:59:32 UTC
I would like to see this change as well. Right now, if our circ staff doesn't change the item's status to Lost and Paid For when the patron pays for the item, I have to spend time later trying to sort out the problem and correct the status.
Comment 2 Martha Fuerst 2019-05-10 13:30:44 UTC
I'm not sure, but this could play into Bug #20262 as well, maybe?

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20262
Comment 3 Andrew Fuerste-Henry 2020-12-17 15:46:18 UTC
As much as "let's add a yaml syspref" gets to be a cliche ... I can see this as a yaml syspref. UpdateItemLostStatusWhenPaid or something similar, give pairs of lost values like "1: 3" to say "when an item with lost=1 hits amountoutstanding=0, change its status to 3."

I anticipate issues in cases where a library's policies allow multiple patrons to concurrently have lost fees for the same item.
Comment 4 Martha Fuerst 2020-12-17 16:30:53 UTC
I like that solution, Andrew. It sounds super customizable or ignorable, for those systems that wouldn't need it.
Comment 5 Rebecca Coert 2020-12-21 20:13:05 UTC
It would be helpful to have the ability to have a Long Overdue (Lost) items convert to Lost and Paid upon payment.  A sys-preference seems the easiest way to make this available for those of us that want it.
Comment 6 Jeff Gaines 2020-12-21 20:50:11 UTC
It would make sense to set the system to handle this for payments that are not staff mediated. Even for staff-mediated payments, it's one less thing for staff to do (or forget to do).
Comment 7 Sarah Daviau 2020-12-21 23:55:12 UTC
This would be a good way to smooth the process out for both front line staff and on the back end.
Comment 8 Martha Fuerst 2020-12-22 12:23:33 UTC
(In reply to Jeff Gaines from comment #6)
> It would make sense to set the system to handle this for payments that are
> not staff mediated. Even for staff-mediated payments, it's one less thing
> for staff to do (or forget to do).

Even for Paypal payments - if the payment is for a lost item, the lost status should be changed to lost and paid for. Otherwise, it is very unlikely that staff will (without looking for it via a report or somehow stumbling on it) will know the item was paid for and the status should be changed.
Comment 9 Carolyn Hughesman 2021-03-11 16:09:28 UTC
I think this would be a helpful new feature.  A sys-pref for this for those of us that want this would be great!
Comment 10 Wally DesChamps 2021-06-02 04:04:16 UTC
This would be an invaluable enhancement.  With all that goes on at our circ desk, and the steps involved in handling money, updating Koha, credit card terminal, etc.,e tc., etc., changing the item to Lost and Paid For is often missed and becomes an exercise in frustration to balance in the accounting reports, especially when one payment covers multiple items.  Has there been any progress with this Bug?
Comment 11 Katrin Fischer 2021-06-02 11:42:24 UTC
(In reply to Wally DesChamps from comment #10)
> This would be an invaluable enhancement.  With all that goes on at our circ
> desk, and the steps involved in handling money, updating Koha, credit card
> terminal, etc.,e tc., etc., changing the item to Lost and Paid For is often
> missed and becomes an exercise in frustration to balance in the accounting
> reports, especially when one payment covers multiple items.  Has there been
> any progress with this Bug?

At the moment this bug has no Assignee (someone working on a patch) and has not been marked as "Sponsored". I can only assume that there is no ongoing work on this. As there seem a lot of people interested in it, maybe you could join forces to get this funded and developed.
Comment 12 AspenCat Team 2021-09-27 20:04:58 UTC
We would like to see this get funded and developed, so our organization can contribute some money into making it happen. - Bob Bennhoff (Colorado Library Consortium bbennhoff@clicweb.org)
Comment 14 Andrew Fuerste-Henry 2024-03-27 14:05:26 UTC
(In reply to Martin Renvoize from comment #13)
> Specification:
> https://docs.google.com/document/d/
> 1fV1U2a2CfVr2RkKl5g9mUa5JOE63GAevDXOcdpAZ_nE/edit?usp=sharing

Your spec suggests possible options for defining which lost value(s) items should be set to. I think hardcoding this feature to use a lost value of 3 ("Lost and paid for" in default data) will prove unusable for many libraries where their local lost values differ from the defaults.

I like the idea of distinct values for paid vs. written off. Defining different values for different credit types is more complexity than we need here.
Comment 15 Andrew Fuerste-Henry 2024-03-27 14:07:07 UTC
What happens is a payment or writeoff is voided or refunded, causing the amountoutstanding on the LOST charge to go back above zero? Does the item status revert to lost?
Comment 16 Cheryl 2024-03-27 14:30:32 UTC
I agree with Andrew's comment on Martin's options: it should NOT hardcoded to a specific value. 
Libraries should have the ability to pick a local value for it to be updated FROM and TO (including multiple "from"s and probably multiple "to"s).
Comment 17 Lisette Scheer 2024-03-28 19:50:19 UTC
I think 2 system prefs (lost->paid & lost->written off/voided) would be better than hardcoding. 

Additionally, I think Andrew's question about voiding and refunding would be a separate bug, which I'm filing and I'll add as a see also.