[Koha-bugs] [Bug 35114] Total on basketgroup can be different than basket details total

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35114

--- Comment #9 from Thibaud Guillot <thibaud.guillot at biblibre.com> ---
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.