Bug 7495 - Tax calculations problem for new orders.
Summary: Tax calculations problem for new orders.
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: 3.6
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on: 5335
Blocks:
  Show dependency tree / graph
 
Reported: 2012-02-02 21:12 UTC by Frédérick Capovilla
Modified: 2014-12-07 20:02 UTC (History)
4 users (show)

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

Attachments
A new mobile.css with the positioning top:0px of div#top-bar (13.25 KB, text/css)
2013-09-16 19:33 UTC, Viktor Sarge 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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)
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.