The total_est_gste or gsti is computed on the total_rrp_gste or gsti. But in the budget this amount is the sum of discounts computed for each line. Due to the rounding to 2 decimal places this produces a difference in Funds view with Total sublevels spent.
Created attachment 4005 [details] [review] proposed patch
Christophe, this patch doesn't apply anymore, can you rebase it pls ?
Created attachment 4124 [details] [review] new proposed patch Paul, I hope this one is ok.
When I try to access an existing basket I get following perl error: Global symbol "$i" requires explicit package name at /home/katrin/kohaclone/acqui/basket.pl line 255. Execution of /home/katrin/kohaclone/acqui/basket.pl aborted due to compilation errors. After switching back to my master branch it works ok.
Step to reproduce: * customer with a discount (10%) * add a line with a decimal price, qty 10 (10.25€, qty 10) * the total is wrong
Paul, there was a perl error - I think we need a new patch first.
Created attachment 4223 [details] [review] updated and signed-off patch Please another signoff requested. The total is now the sum of the individual lines, it's no more the discount of the total. Without this patch, the total can be X on basket.pl and a different value on budget pages, resulting in a difference between baskets and budget spended !
Created attachment 4240 [details] screenshot 1: adding new order I am not convinced the calculation is right. I tried your example: 10 copies for 10.25 each with a 10% discount from the vendor. I calculated a total of 92.25. What Koha calculates depends: The value calculated on the entry form is 92.25 The value shown in my basket summary table and when modifying my order line is 92.20
Created attachment 4241 [details] screenshot 2: modifying same order
OK, I think we should investigate a little bit more what should be the behaviour. If you order 10 items, 5.25 each, with a 10% discount, how much will it cost ? Must the rounding be applied on the discounted total, or a discount calculated to the total ? IE : 10*5.25*0.90 is 10*4,72 = 47.2 or 52.50*0.9 = 47.25
Hi Paul, you are right, we have to agree on one calculation and make it work the same everywhere.
I've asked my accountant to know what is the legal rule (at least in France)
"bad" news from my accountant : there is no rule, we can choose whatever we want. So, what do we want ? (should I send a mail to koha-dev ?)
Apparently vendors can do both on their bills, so there is no real solution to this without making it overly complicated. I am not sure, but I think by the way we save prices calculating the discount per book might be easier to realize? So when receiving books prices will always add up correctly to the calculated sum without running into rounding problems. IE : 10*5.25*0.90 is 10*4,72 = 47.2 Could you send a follow-up for the entry form?
Created attachment 4469 [details] [review] Signed off patch
Created attachment 4470 [details] Screenshot showing wrong totals on basket summary page
Patch does what it says - it corrects the totals on the basket summary page. Before patch: Entry form: 9.22, total 92.25 Basket summary page: 9.22, total 92.20 AND 92.25 (!) Budgets on acq home page: 92.20 After patch: Entry form: 9.22, total 92.25 Basket summary page: 9.22, total always 92.20 Budgets on acq home page: 92.20 Still 2 things: 10.25 - 10% is calculated as 9.22 almost everywhere now. Exact price is: 9.225 - why not round to 9.23? The entry form should also calculate 92.20. Follow-up needed.
Created attachment 4532 [details] [review] follow up patch for the form
katrin, can you sign-off my follow-up too please. it's a one line patch
Created attachment 4555 [details] [review] BZ6268 follow-up for the form This follow up fixes cait request to calculate the form like the budget Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch is minor. I've not written it despite what is stored in the patch owner (written by Christophe) Marking passed QA just before the string freeze, Chris, object if you want
Signed off by Katrin, who knows acquisitions well. I have no issues with pushing it
There have been no further reports of problems so I am marking this bug resolved.