https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35114
--- Comment #9 from Thibaud Guillot <[email protected]> --- The first fix I proposed was to correct the behavior of basket group, in order to base itself on the calculation of actual cost if it is defined, otherwise it remains on ecost. This is in fact currently the case with basket detail. Except that if I go back to the behavior and error of my second step, I can already see a price difference (of one cent). To understand this, when adding the order (from neworderempty.pl) the shaded lines are calculated lines, with 6 decimal places, whereas the actual cost value, if not defined, will be retrieved by javascript (acq.js updateCosts function), keeping only two decimal places, which distorts the calculations. The ecost is rounded down to the nearest integer (Math.floor), so this logic doesn't fit with the rest of the calculations, which round up to the nearest integer using a get_rounded_price method, plus Math.round to draw a parallel. Except that in our case (test plan example), even this rectification wouldn't change a thing... Let's take a look at the basic data: unitprice : 14.460000 unitprice_tax_excluded: 14.460000 unitprice_tax_included: 15.255300 ecost: 14.46 ecost_tax_excluded: 14.469000 ecost_tax_included: 15.264795 Accounting calculations can't be imprecise, so what I'm proposing is to use only the ecost to obtain the right calculations. The behavior of the unit price (when adding a line from neworderempty.pl for example), on the other hand, can be corrected to match the correct values: Math.round usage -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
