[Koha-bugs] [Bug 17140] Incorrect rounding in total fines calculations, part 2

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17140

--- Comment #9 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
(In reply to Jonathan Druart from comment #8)
> Prices should be stored with a big precision (6 is largely enough) and
> displayed with 2 decimals.

Hm, maybe charges / fines should be treated a bit differently.. When there is a
fine like 1.342, and it displays as 1.32, how do you know what exact amount to
enter to make account balanced? Doing a math (comparisons etc.) with amounts
casted to .2f would solve some kinds of this problems (I think that's like
accountants do it [on Discovery Channel]) to solve < .01 difference problems on
invoices etc.

Fine calculations in Koha a mostly done in floating-point - it's probably good
enough for 99.9(9) of cases (~16 significant decimal digits precision with
64bit floats) as long as you are doing a casting (btw, to .2f or .6f ?) in most
important places.

Mysql calculations for decimal(x,y) are allegedly precise, though, and fine
calculations in koha are not always floating-point, e.g. in
GetMemberIssuesAndFines():

    SELECT SUM(amountoutstanding) FROM accountlines

Storing all fines/charges amounts rounded to .2f and doing most of the math in
.2 precision is tempting (but that alone would not be enough to prevent all
kinds of such problems) - hopefully nobody is using bitcoin as a main currency
in Koha..

-- 
You are receiving this mail because:
You are watching all bug changes.