Bug 22740 - Automatically change lost status when item is paid for
Summary: Automatically change lost status when item is paid for
Status: Pushed to main
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: Nick Clemens (kidclamp)
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-05-08 14:46 UTC (History)
22 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission: Sponsored by Cuyahoga County Public Library
Text to go in the release notes:
Version(s) released in:
24.05.00


Attachments
Bug 22740: Automatically change lost status when item is paid for (10.75 KB, patch)
2024-04-30 14:16 UTC, Jacob O'Mara
Details | Diff | Splinter Review
Bug 22740: Write unit tests for automatic lost status switching (8.88 KB, patch)
2024-04-30 14:16 UTC, Jacob O'Mara
Details | Diff | Splinter Review
Bug 22740: Automatically change lost status when item is paid for (10.82 KB, patch)
2024-04-30 21:18 UTC, Laura Escamilla
Details | Diff | Splinter Review
Bug 22740: Write unit tests for automatic lost status switching (8.95 KB, patch)
2024-04-30 21:18 UTC, Laura Escamilla
Details | Diff | Splinter Review
Bug 22740: Automatically change lost status when item is paid for (14.85 KB, patch)
2024-05-01 13:50 UTC, Jacob O'Mara
Details | Diff | Splinter Review
Bug 22740: Write unit tests for automatic lost status switching (8.97 KB, patch)
2024-05-01 13:50 UTC, Jacob O'Mara
Details | Diff | Splinter Review
Bug 22740: Automatically change lost status when item is paid for (14.99 KB, patch)
2024-05-01 15:31 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 22740: Write unit tests for automatic lost status switching (9.11 KB, patch)
2024-05-01 15:31 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 22740: Automatically change lost status when item is paid for (15.04 KB, patch)
2024-05-01 15:53 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 22740: Write unit tests for automatic lost status switching (9.16 KB, patch)
2024-05-01 15:53 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

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.
Comment 18 Jacob O'Mara 2024-04-30 14:16:01 UTC
Created attachment 165906 [details] [review]
Bug 22740: Automatically change lost status when item is paid for

This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid"
that allow you to specify the status to change an item to when the outstanding balance of
a lost item is paid or written off. These preferences are tied to the LOST authorised values set.

Test Plan:
 - Set one of the system preference to any of the available values
 - Set an item as lost
 - Make a manual invoice for your desired user and assign it to the
   barcode of the above item
 - Save and Pay
 - Select Pay/Write Off depending on the system preference you selected
   above
 - Pay
 - Note that the status of the item has changed to the status you set
   with the system preference
 - Repeat for all values of both system preferences
 - Check that when the system preference is left blank and no option is
   chosen, the lost status does not update.
Comment 19 Jacob O'Mara 2024-04-30 14:16:05 UTC
Created attachment 165907 [details] [review]
Bug 22740: Write unit tests for automatic lost status switching

This patch adds the unit tests for the new system preferences that will automatically change an items lost status to an authorised value defined in these preferences on payment or write off of outstanding balance.
Comment 20 Laura Escamilla 2024-04-30 21:18:15 UTC
Created attachment 165932 [details] [review]
Bug 22740: Automatically change lost status when item is paid for

This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid"
that allow you to specify the status to change an item to when the outstanding balance of
a lost item is paid or written off. These preferences are tied to the LOST authorised values set.

Test Plan:
 - Set one of the system preference to any of the available values
 - Set an item as lost
 - Make a manual invoice for your desired user and assign it to the
   barcode of the above item
 - Save and Pay
 - Select Pay/Write Off depending on the system preference you selected
   above
 - Pay
 - Note that the status of the item has changed to the status you set
   with the system preference
 - Repeat for all values of both system preferences
 - Check that when the system preference is left blank and no option is
   chosen, the lost status does not update.

Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Comment 21 Laura Escamilla 2024-04-30 21:18:19 UTC
Created attachment 165933 [details] [review]
Bug 22740: Write unit tests for automatic lost status switching

This patch adds the unit tests for the new system preferences that will automatically change an items lost status to an authorised value defined in these preferences on payment or write off of outstanding balance.

Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Comment 22 Jacob O'Mara 2024-05-01 13:50:09 UTC
Created attachment 165973 [details] [review]
Bug 22740: Automatically change lost status when item is paid for

This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid" that allow you to specify the status to change an item to when the outstanding balance of a lost item is paid or written off. These preferences are tied to the LOST authorised values set.

Test Plan:
 - Set one of the system preference to any of the available values
 - Set an item as lost
 - Make a manual invoice for your desired user and assign it to the barcode of the above item
 - Save and Pay
 - Select Pay/Write Off depending on the system preference you selected above
 - Pay
 - Note that the status of the item has changed to the status you set with the system preference
 - Repeat for all values of both system preferences
 - Check that when the system preference is left blank and no option is chosen, the lost status does not update.
Comment 23 Jacob O'Mara 2024-05-01 13:50:13 UTC
Created attachment 165974 [details] [review]
Bug 22740: Write unit tests for automatic lost status switching

This patch adds the unit tests for the new system preferences that will automatically change an items lost status to an authorised value defined in these preferences on payment or write off of outstanding balance.
Comment 24 Martin Renvoize 2024-05-01 15:31:36 UTC
Created attachment 166003 [details] [review]
Bug 22740: Automatically change lost status when item is paid for

This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid" that allow you to specify the status to change an item to when the outstanding balance of a lost item is paid or written off. These preferences are tied to the LOST authorised values set.

Test Plan:
 - Set one of the system preference to any of the available values
 - Set an item as lost
 - Make a manual invoice for your desired user and assign it to the barcode of the above item
 - Save and Pay
 - Select Pay/Write Off depending on the system preference you selected above
 - Pay
 - Note that the status of the item has changed to the status you set with the system preference
 - Repeat for all values of both system preferences
 - Check that when the system preference is left blank and no option is chosen, the lost status does not update.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Comment 25 Martin Renvoize 2024-05-01 15:31:40 UTC
Created attachment 166004 [details] [review]
Bug 22740: Write unit tests for automatic lost status switching

This patch adds the unit tests for the new system preferences that will
automatically change an items lost status to an authorised value defined
in these preferences on payment or write off of outstanding balance.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Comment 26 Martin Renvoize 2024-05-01 15:32:40 UTC
For a simple re-tidy for the QA script you don't need to loose the original signoff Jacob.

I've restored it and added my own for the internal review we did.

Setting to Signed off and throwing it at the QA queue.
Comment 27 Nick Clemens (kidclamp) 2024-05-01 15:53:14 UTC
Created attachment 166010 [details] [review]
Bug 22740: Automatically change lost status when item is paid for

This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid" that allow you to specify the status to change an item to when the outstanding balance of a lost item is paid or written off. These preferences are tied to the LOST authorised values set.

Test Plan:
 - Set one of the system preference to any of the available values
 - Set an item as lost
 - Make a manual invoice for your desired user and assign it to the barcode of the above item
 - Save and Pay
 - Select Pay/Write Off depending on the system preference you selected above
 - Pay
 - Note that the status of the item has changed to the status you set with the system preference
 - Repeat for all values of both system preferences
 - Check that when the system preference is left blank and no option is chosen, the lost status does not update.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 28 Nick Clemens (kidclamp) 2024-05-01 15:53:17 UTC
Created attachment 166011 [details] [review]
Bug 22740: Write unit tests for automatic lost status switching

This patch adds the unit tests for the new system preferences that will
automatically change an items lost status to an authorised value defined
in these preferences on payment or write off of outstanding balance.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 29 Katrin Fischer 2024-05-03 17:32:33 UTC
Pushed for 24.05!

Well done everyone, thank you!