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.

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

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.

I like that solution, Andrew. It sounds super customizable or ignorable, for those systems that wouldn't need it.

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.

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).

This would be a good way to smooth the process out for both front line staff and on the back end.

(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.

I think this would be a helpful new feature.  A sys-pref for this for those of us that want this would be great!

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?

(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.

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)

Specification: https://docs.google.com/document/d/1fV1U2a2CfVr2RkKl5g9mUa5JOE63GAevDXOcdpAZ_nE/edit?usp=sharing

(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.

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?

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).

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.

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.

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.

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>

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>

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.

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.

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>

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>

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.

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>

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>

Pushed for 24.05!

Well done everyone, thank you!

Not backported to 23.11.x