Bug 24855 - Lost items not marked returned when floating-point math causes amountoutstanding to be not-quite-zero
Summary: Lost items not marked returned when floating-point math causes amountoutstand...
Status: RESOLVED DUPLICATE of bug 28482
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
: 18895 (view as bug list)
Depends on:
Reported: 2020-03-11 20:10 UTC by Andrew Fuerste-Henry
Modified: 2021-06-04 12:06 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2020-03-11 20:10:36 UTC
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. 

To test:
- 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.
Comment 1 Andrew Fuerste-Henry 2020-03-11 20:11:52 UTC
*** Bug 18895 has been marked as a duplicate of this bug. ***
Comment 2 Nick Clemens 2020-03-12 16:20:03 UTC
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.
Comment 3 Andrew Fuerste-Henry 2020-03-12 16:22:18 UTC
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.
Comment 4 Jonathan Druart 2020-08-10 11:09:08 UTC
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...
Comment 5 Andrew Fuerste-Henry 2021-04-09 13:15:47 UTC
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
Comment 6 Katrin Fischer 2021-06-03 23:45:49 UTC
Is this possibly a duplicate of bug 28482?
Comment 7 Andrew Fuerste-Henry 2021-06-04 12:06:26 UTC

*** This bug has been marked as a duplicate of bug 28482 ***
Comment 8 Andrew Fuerste-Henry 2021-06-04 12:06:44 UTC
Totally is, thanks Katrin!