Hi, There is a potentially severe problem when paying the replacement charge for an item if the item is still checked-out to a patron. For example, if your cronjob is set to mark an item lost and you charge patrons for lost items, using anything other than the 'pay' button will not remove the item from the patron's checkouts after the charge has been paid. 'Pay selected,' 'Pay amount,' Write off,' or 'Write off all' will take care of the charge, but the item will remain checked-out and marked as 'Long Overdue / Lost' on the patron's record. Additionally, it is difficult to identify these erroneous items if staff does not catch it them immediately, making it hard to correct lingering problems. To replicate: 1.) Set preference WhenLostChargeReplacementFee to 'Charge' 2.) Edit the record of a checked-out item to the lost status indicated by your DefaultLongOverdueChargeValue. Note: To keep the item checked-out, this must be done by opening and editing the item's record (not directly from the items tab of the bibliographic record). You can also use an item that your longoverdue cronjob marked. 3.) Confirm that the item is still checked-out to the patron and that the replacement fee was charged. 4.) Use pay selected, pay amount, write off, or write off all with the replacement charge and confirm the action as you normally would. 5.) The charge will be removed but the item will still be checked-out to the patron's record.
Our library just migrated to Koha and we already run into this bug and the problems associated with items not properly getting removed from the patron's account. Is this bug on the radar to get fix anytime soon? The work around of using only the "pay" button per lost item is tedious and difficult to enforce when we have a large group of PT employee on the front desks using the system.
If Koha has X ways to set an item to lost And X ways to pay for the lost fee Then shouldn't the result be the same: fee paid > item off the patron account Our library cares about this bug. Having to use the 'pay' button for each fee on a patron account is tedious and time consuming.
Some conditions that could cause this were eliminated in bug 22982, which was backported into 19.05.01. However, I've got an example from a lost item payment made in 19.05.06.
Hi Andrew, As I'm working on bug 24474 which refines and corrects some issues introduced in bug 22982 I'd be interested to know if you can replicate any of these issues against master at the moment? I was about to mark this one as RESOLVED FIXED as I felt 22982 covered all cases... but if there's still ways to get into this state which I'm unaware of then it needs to stay open and we need to clarify what cases are still open to lead to this situation. Thanks in advance, Martin
I have not been able to recreate this on master or 19.05. The example we've got is pretty mystifying.
I believe that one of the bugs shown in the See Also section (8016, 22982, 24474) may have corrected this. This bug was submitted as a related but separate issue to 8016.
Filed a new more specific bug, pushing this into that one. *** This bug has been marked as a duplicate of bug 24855 ***