Bug 18895 - Lost Items Not Removed From Patron's Account When Charge is Paid
Summary: Lost Items Not Removed From Patron's Account When Charge is Paid
Status: RESOLVED DUPLICATE of bug 24855
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low major with 20 votes (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-05 15:03 UTC by Chris Slone
Modified: 2020-03-11 20:11 UTC (History)
8 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 Chris Slone 2017-07-05 15:03:36 UTC
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.
Comment 1 Azucena Aguayo 2019-08-02 18:38:26 UTC
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.
Comment 2 Azucena Aguayo 2020-01-23 18:28:23 UTC
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.
Comment 3 Andrew Fuerste-Henry 2020-02-06 16:04:28 UTC
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.
Comment 4 Martin Renvoize 2020-02-11 10:32:59 UTC
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
Comment 5 Andrew Fuerste-Henry 2020-02-11 14:59:53 UTC
I have not been able to recreate this on master or 19.05. The example we've got is pretty mystifying.
Comment 6 Chris Slone 2020-02-11 15:05:32 UTC
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.
Comment 7 Andrew Fuerste-Henry 2020-03-11 20:11:52 UTC
Filed a new more specific bug, pushing this into that one.

*** This bug has been marked as a duplicate of bug 24855 ***