Floating point math and a strict "if amountoutstand=0" result in things not getting marked as returned when they should. I've had a hard time figuring out exactly when this will go wrong, so I've got some very specific steps to recreate.
- set MarkLostItemsAsReturned to never mark items returned
- turn on Fines log
- find/create a patron with no outstanding fees or fines
- manually apply 8 overdue charges of $4.10
- create an item with a replacement cost of 6.99
- check item out to patron
- mark item lost, generating 6.99 lost fee for patron
- pay off entire balance using the Pay Amount button
- confirm patron no longer owes any fees, but item has not been marked as returned when fee was paid off
- check fines log, see that the accountline for this lost fee recorded a payment of "6.98999999999999" and a new amountoutstanding of "7.105427357601e-15"
While we round these values to 4 decimal places in accountlines, that rounding happens *after* Koha checks if amountoutstanding=0 when deciding whether or not to mark the lost item returned.
*** Bug 18895 has been marked as a duplicate of this bug. ***
I did some testing here, the fines log issue is easily recreated by adding a few fines of $0.10 and then a 6.99 fine, but the checkout is still returned.
Interesting! I tried it with a few fines of $1.00 and a 6.99 lost item and it didn't recreate. Makes sense that even dollars v. some cents would make the difference.
I do recreate using the steps from comment 0.
However I am not sure how to fix this, the "pay amount" button does not take care of the line we selected (as far as I understood).
The "Pay selected" button does, and the problem exists as well here.
I think we should fix that in Koha/Account/Line.pm and Koha/Account.pm where we compare $debit->amountoutstanding and $new_amountoutstanding with 0 (==0 vs sprintf %.2f for instance), but it appeared it's not enough so there may be something else...
An additional note here: while Koha records amounts out to 6 decimal places, it appears this issue can occur with fractional cents even smaller than that, resulting in items not being returned even though the accountlines entry says the amountoutstanding is 0.000000.
Again, recreating the issue requires some very specific values and actions:
- have an item type that charges a $10 processing fee
- have two items of that item type, one with replacement price 125.68 and the other with replacement price 33.95
- mark both items as lost, confirm patron owes you 179.63
- take payment of 179.63 for all fees using the Pay Selected button
- the 33.95 item is not marked as returned, but the fee shows 0.000000 outstanding
Is this possibly a duplicate of bug 28482?
*** This bug has been marked as a duplicate of bug 28482 ***
Totally is, thanks Katrin!