[Bug 41741] New: UpdateItemLostStatusWhenPaid should not apply to cancelled charges
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41741 Bug ID: 41741 Summary: UpdateItemLostStatusWhenPaid should not apply to cancelled charges Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs@lists.koha-community.org Reporter: sbrown@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org If a library is using UpdateItemLostStatusWhenPaid to automatically update items' lost status when accepting payment, the status change also happens for charges that are cancelled from the Transactions tab of a patron's account. A separate system preference could be created for cancelled charges, but at a minimum, lost items whose charges are cancelled (not paid) shouldn't have their status automatically updated by UpdateItemLostStatusWhenPaid. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41741 --- Comment #1 from Sara Brown <sbrown@bywatersolutions.com> --- This status change happens even if the item already has a status of 'Available'. This may be a somewhat niche set of circumstances, but it is an issue for some libraries whose payments are handled by centralized offices (such as school/university libraries). Settings: -UpdateItemLostStatusWhenPaid is set to 'Lost and paid for' -Lost item charges are *not* automatically removed from patron accounts when items are returned Scenario: -Patron checks out an item -Item is marked lost -The account charge is reported to the centralized billing office -Before the charge has been paid, the item is returned - this changes its status to 'Available' -When the library cancels the charge from the patron's Transactions tab, the item status flips to 'Lost and paid for'. The same thing happens if the charge is discounted from the Transactions tab. Note that this library uses writeoffs for items that are still lost but whose full cost will not be charged, so they don't want to use it for returned items whose charges should be entirely cleared. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41741 pearl.desure@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pearl.desure@gmail.com Priority|P5 - low |P2 --- Comment #2 from pearl.desure@gmail.com --- I want to second Sara's comments and reiterate that payments and cancellations should be handled separately. Our library uses an external application (ctcLink) to manage fines, so we rely on lost-item charges staying on the patron account when a long-lost overdue item is checked in. We have Koha configured this way intentionally because staff need to review the return, remove the fine in ctcLink, and then clear the charge in Koha. Our workflow uses a report to flag returned items that need this review, and it works well for us. The issue is when cancellations are treated as payments. If a charge is removed automatically, staff may not realize they still need to reverse the fine in ctcLink. Since we rely heavily on student workers at the circulation desk, it's easy for these discrepancies to be missed. We would also prefer not to use the write-off function as a workaround. To us, a write-off implies that the item is still in the borrower's possession but we've decided to waive the charge. That's a different situation from a returned item, and the terminology should reflect that distinction. On principle, the language and workflows for write-offs/waivers, cancellations, and payments should remain consistent because these are three different processes with different meanings and staff actions attached to them. Treating cancellations as payments creates extra cleanup work, increases the risk of fines remaining on student accounts when they should have been removed, and makes it harder for staff to accurately track what actually happened. For libraries that manage fines outside of Koha, this is a significant workflow issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org