Bug 7495

Summary:	Tax calculations problem for new orders.
Product:	Koha	Reporter:	Frédérick Capovilla <fcapovilla>
Component:	Acquisitions	Assignee:	Bugs List <koha-bugs>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P5 - low	CC:	jonathan.druart, mathsabypro, veron, viktor.sarge
Version:	3.6
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
Bug Depends on:	5335
Bug Blocks:
Attachments:	A new mobile.css with the positioning top:0px of div#top-bar

Description Frédérick Capovilla 2012-02-02 21:12:26 UTC

When creating a new order, the automatic tax calculations may sometimes be wrong because of loss of precision.

Example :
With gist=0, create a new order and put 18.99 into the "Vendor price" field.
The "Budgeted cost" and "Total" fields are automatically set to 18.98 when they should be 19.99
The same happens with 16.99 .

Possible cause of the problem :
http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

Here are some utility functions that could be used to correct the problem :
function to_Cents(val) {
    return Math.round(val*100);
}

function to_Dollars(val) {
    return (Math.round(val)/100).toFixed(2);
}

Comment 1 Marc Véron 2012-04-19 08:05:06 UTC

I do not think that rounding will really help because with double or float you loose precision in an almost arbitrary way.

The most solid resolution would be to make use of BigFloat for all currency calculations.

http://perldoc.perl.org/Math/BigFloat.html

Comment 2 Frédérick Capovilla 2012-05-18 16:11:32 UTC

BigFloat is for perl. The problem I'm mentioning is in a tax calculation done in javascript.

The rounding solution seems to be acceptable for currency calculations. 
By rounding, you convert the amount into an int so you don't suffer from the precision loss of floats.

Comment 3 Jonathan Druart 2012-06-14 13:43:54 UTC

Please verify that this issue is not fixed by patch for Bug 5335 before continuing the workflow of this bug. Bug 5335 has already been rebased a lot of time and it is very difficult to do it.

Comment 4 Jonathan Druart 2013-07-19 08:23:13 UTC

Frédérick, could you check if the issue still exists on master please?

Comment 5 Viktor Sarge 2013-09-16 19:33:58 UTC Comment hidden (obsolete)

Created attachment 21128 [details]
A new mobile.css with the positioning top:0px of div#top-bar

If mobile.css is a static file then this one might do the trick for this bug.

Comment 6 Viktor Sarge 2013-09-16 19:36:41 UTC

Sorry peope - the previous got posted on the wrong bug somehow and I can't find any way to delete my comment and/or attachment from this bug.

Comment 7 Mathieu Saby 2013-09-20 09:00:35 UTC

By the way, the problem described in this bug is still existing!

Mathieu

Comment 8 Jonathan Druart 2014-03-06 09:23:28 UTC

I don't reproduce this bug on master. Please reopen it if I am wrong.