Bug 9626 - can't pay FU fines without messing things up
Summary: can't pay FU fines without messing things up
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-15 16:42 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
5 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 Nicole C. Engard 2013-02-15 16:42:17 UTC
The glitch happens when a patron pays their overdue fine before the item is checked in. When they pay their fine and we mark it down as paid, Koha marks the fine as paid--but as soon as their overdue item is checked in, Koha pops up with a notice that a) the fine was not paid off, and b) is now twice the amount it originally was.

Sounds to me like if you pay off a fine that is FU it's changing it to PAID instead of leaving it as FU. Maybe we need the code to look at the code and not change the accounttype if it's FU - only if it's F or something else.
Comment 1 wajasu 2014-02-24 03:20:27 UTC
I played around trying to reproduce.
I would check in checking the book drop mode, since I saw some code call CalcFines.  

--- walkthrough 1:
If I checkout a book, setting its overdue date to 5 days ago, and according to my circ rules, I would have an accountline entry:
accounttype=Rent  amount=$5.00

Then I would run fines.pl and get a new entry:
accounttype=FU amount=$2.00

I make a payment and get another entry:
accounttype=Pay amount=$7.00
AND my amountoutstanding columns become 0.00 for the two above entries.

When I check in, I get no notice. But its intersting, the accounttype for the FU/2.00 entry became  F.  (possibly because of some historical breaking of the accrual code, as I saw a comment somewhere mentioning that ).
I saw no notice and no duplicate fine.

----- walkthrough 2:
If I checkout a book, setting its overdue date to 5 days ago, and according to my circ rules, I would have an accountline entry:
accounttype=Rent  amount=$5.00

Then I would run fines.pl and get a new entry:
accounttype=FU amount=$2.00

I make a payment ONLY to the FU entry and not the Rent entry and get another entry:
accounttype=Pay amount=$2.00
AND my amountoutstanding columns become 0.00 for the FU entry.

When I check in, I get "Patron has outstanding fines of $5.00 notice. 
The accounttype for the FU/2.00 entry became  F.  
I saw no notice and no duplicate fine.

===========  Notes
circa 2014-02-23 master
This might have been fixed somewhere.
It might  be the case that your circulation rules are generating a Rent accountline like mine, and the FU entry as well, possibly being the same amount, let's say $2.00, and you pay off one but the other shows up in the notice.  But you probably would have seen that in the pay fines tab. The FU entries disappear from the pay fines tab once paid.

It might have to do with the FU -> F account type, or that might have been the fix.

Or it might have to do with other staticfines.pl generated accountlines entries.
Or it might have to do with historical fine entries and fine update logic not being able to find a unique entry, or just the first.
I could not find the code that updates the accounttype from FU to F.

I think I noticed another issue, where if a fine entry existed from an historical checkout on an item, and I checked it out again, and it became overdue, fines.pl did not create a new fine entry.  That might be because I used the same due date, or because the code looks for  an existing fine on an item and only creates one if one doesn't exist. So the logic might need to consider that, or deal with F/FU changing. But that might be another issue.
Comment 2 Owen Leonard 2016-06-22 16:23:53 UTC
Is this bug still valid in master? If so, please update the version information.
Comment 3 Chris Cormack 2016-08-14 20:19:32 UTC
Can not reproduce in master