Bug 18736

Summary: Problems in order calculations (rounding errors)
Product: Koha Reporter: Nick Clemens <nick>
Component: AcquisitionsAssignee: Bugs List <koha-bugs>
Status: In Discussion --- QA Contact: Testopia <testopia>
Severity: critical    
Priority: P5 - low CC: francois.charbonnier, jonathan.druart, koha, kyle, laurence.rault, nicolas.legrand, severine.queune, sonia.bouis, veron
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18639
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17140
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15741
Whiteboard:
Change sponsored?: --- Patch complexity: ---
Bot Control: --- When did the bot last check this:
Who signed the patch off: Text to go in the release notes:
Bug Depends on: 13321    
Bug Blocks:    
Attachments: Bug 18736 - Problems in order calculations (rounding errors)
Bug 18736: Correctly handle rounding

Description Nick Clemens 2017-06-06 14:36:49 UTC
The way we are calculating and/or storing our prices in acquisitions is causing some odd issues.

For example:

Place an order (no tax, let's not even deal with that right now please)
 listprice/rrp = 16.99
 discount = 42%
 quantity = 8

estimated calculated at 9.85

but order total is 78.83, but 8 times 9.85 = 78.80
Comment 1 Nick Clemens 2017-06-06 14:38:32 UTC
Created attachment 64061 [details] [review]
Bug 18736 - Problems in order calculations (rounding errors)

Unit tests to highlight the issue

To test:
Prove t/db_dependent/Budgets.t
Comment 2 Nick Clemens 2017-06-06 14:46:37 UTC
The issue we need to decide here is whether we store the extra digits and correct calculations based on these, or store the price with 2 digits precision
Comment 3 Marc VĂ©ron 2017-06-06 14:53:26 UTC
We have a similar issue with fines:
Bug 15741 - Incorrect rounding in total fines calculations 
(see comment #12)
Bug 17140 - Incorrect rounding in total fines calculations, part 2
Comment 4 Jonathan Druart 2017-06-06 19:11:33 UTC
Created attachment 64065 [details] [review]
Bug 18736: Correctly handle rounding

The values displayed should be the sum of the rounded values, not the
reverse.

In ModReceiveOrder, i am wondering if:
  tax_value_on_ordering = quantity * format(ecost_tax_excluded) * format(tax_rate_on_ordering)

is correct or if it must be:
  tax_value_on_ordering = quantity * format(ecost_tax_excluded * tax_rate_on_ordering)

Note: the second form is used in 16.06.00.042 (bug 13321)
Comment 5 Jonathan Druart 2017-06-06 19:14:35 UTC
Here is my try, for discussion.
We must understand and fix everything in one go, we need people that have been involved in bug 13321 and related to confirm the correct behaviours.
See also bug 18639.
Comment 6 Nick Clemens 2017-06-07 12:53:56 UTC
I think we shouldn't round the tax rates - they should be applied with as much precision as possible

you have one ROUD where you want ROUND

spent.pl will need an update too
Comment 7 Koha Team Lyon 3 2017-06-20 12:03:04 UTC
Hi,
what we need in our library is to have the more precise price for order and the exact invoice price. So we sould surely store precise result rather than rounded price.
But, people will not understand if we display rounded prices and if the total is calculated on prices with 4 decimals...
Perhaps, we souhld display more precise price (4 decimals ?)...

I'm not really sure to help in this discussion because I feel that I miss some technical points.

Sonia