https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17140
--- Comment #9 from Jacek Ablewicz <a...@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.
_______________________________________________
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
