To recreate: 1 - Checkout an item to Patron A, backdate the due date and run fines to generate an overdue 2 - Return the item 3 - Checkout the item to Patron B, mark it lost and ensure a fine is generated 4 - In the DB set the date i=on the lost fine to yesterday 5 - Writeoff the fine for Patron A 6 - Return the item 7 - It is no longer lost, but the lost fine is not refunded
Do you have the rule defined? It seems that it is not created on install.
(In reply to Jonathan Druart from comment #1) > Do you have the rule defined? It seems that it is not created on install. Which rule? I believe the problem is in the code for _FixAccountForLostAndReturned my $accountlines = Koha::Account::Lines->search( { itemnumber => $itemnumber, accounttype => { -in => [ 'L', 'Rep', 'W' ] }, }, { order_by => { -desc => [ 'date', 'accountno' ] } } ); We order by date and accountno - so a more recent writeoff will be found insetad of the lost fine
Bug 22563 could be very helpful here.
On second thoughts.. why do we look for 'W' at all in that query?.. 'W' = Writeoff == Credit.. should we not be looking solely for the 'L' (and/or 'LR') debt line?
I'm working on a test for this at the tip of my accounts branch over here: https://github.com/PTFS-Europe/koha/compare/accounts_all...PTFS-Europe:bug_22377 Currently however I'm struggling to replicate the problem.
Created attachment 87605 [details] [review] Bug 22377: Add test case
Attached my attempt to write a test for this.. anyone is welcome to take over as I couldn't replicate the issue.
Would like to see this move forward. This is an active problem.
Test still applies and I still can't replicate the issue... Reducing severity for now until someone can come up with a failing test case.
The tests are constructed correctly, however, the problematic code has changed. The search as I describe has been removed, it now looks for a status of undef or '!= returned' AND specifically for lost fines Additionally, a write-off no longer gets an itemnumber, so we can't accidentally get the wrong fines. Fixed by bug 22563