Bug 6268 - Bad Total in basket.pl
Summary: Bad Total in basket.pl
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: Paul Poulain
QA Contact: Bugs List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-26 08:51 UTC by Christophe Croullebois
Modified: 2013-12-05 20:04 UTC (History)
3 users (show)

See Also:
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:


Attachments
proposed patch (4.11 KB, patch)
2011-04-26 08:53 UTC, Christophe Croullebois
Details | Diff | Splinter Review
new proposed patch (4.02 KB, patch)
2011-05-16 10:20 UTC, Christophe Croullebois
Details | Diff | Splinter Review
updated and signed-off patch (4.04 KB, patch)
2011-05-23 09:45 UTC, Paul Poulain
Details | Diff | Splinter Review
screenshot 1: adding new order (19.82 KB, image/png)
2011-05-23 20:34 UTC, Katrin Fischer
Details
screenshot 2: modifying same order (20.02 KB, image/png)
2011-05-23 20:35 UTC, Katrin Fischer
Details
Signed off patch (4.15 KB, patch)
2011-06-15 07:14 UTC, Katrin Fischer
Details | Diff | Splinter Review
Screenshot showing wrong totals on basket summary page (27.22 KB, image/png)
2011-06-15 07:15 UTC, Katrin Fischer
Details
follow up patch for the form (979 bytes, patch)
2011-06-29 19:11 UTC, Paul Poulain
Details | Diff | Splinter Review
BZ6268 follow-up for the form (1.01 KB, patch)
2011-07-04 23:08 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Croullebois 2011-04-26 08:51:30 UTC
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.
Comment 1 Christophe Croullebois 2011-04-26 08:53:42 UTC Comment hidden (obsolete)
Comment 2 Paul Poulain 2011-05-09 16:02:24 UTC
Christophe, this patch doesn't apply anymore, can you rebase it pls ?
Comment 3 Christophe Croullebois 2011-05-16 10:20:28 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2011-05-18 06:03:19 UTC
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.
Comment 5 Paul Poulain 2011-05-23 09:16:25 UTC
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
Comment 6 Katrin Fischer 2011-05-23 09:17:17 UTC
Paul, there was a perl error - I think we need a new patch first.
Comment 7 Paul Poulain 2011-05-23 09:45:11 UTC Comment hidden (obsolete)
Comment 8 Katrin Fischer 2011-05-23 20:34:24 UTC
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
Comment 9 Katrin Fischer 2011-05-23 20:35:07 UTC
Created attachment 4241 [details]
screenshot 2: modifying same order
Comment 10 Paul Poulain 2011-05-30 11:33:32 UTC
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
Comment 11 Katrin Fischer 2011-05-30 11:37:59 UTC
Hi Paul, you are right, we have to agree on one calculation and make it work the same everywhere.
Comment 12 Paul Poulain 2011-05-30 12:01:11 UTC
I've asked my accountant to know what is the legal rule (at least in France)
Comment 13 Paul Poulain 2011-06-06 12:49:39 UTC
"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 ?)
Comment 14 Katrin Fischer 2011-06-15 06:01:46 UTC
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?
Comment 15 Katrin Fischer 2011-06-15 07:14:08 UTC
Created attachment 4469 [details] [review]
Signed off patch
Comment 16 Katrin Fischer 2011-06-15 07:15:00 UTC
Created attachment 4470 [details]
Screenshot showing wrong totals on basket summary page
Comment 17 Katrin Fischer 2011-06-15 07:22:25 UTC
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.
Comment 18 Paul Poulain 2011-06-29 19:11:36 UTC Comment hidden (obsolete)
Comment 19 Paul Poulain 2011-06-29 19:12:25 UTC
katrin, can you sign-off my follow-up too please. it's a one line patch
Comment 20 Chris Cormack 2011-07-04 23:08:26 UTC
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>
Comment 21 Paul Poulain 2011-10-06 11:47:40 UTC
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
Comment 22 Chris Cormack 2011-10-06 22:11:36 UTC
Signed off by Katrin, who knows acquisitions well. I have no issues with pushing it
Comment 23 Jared Camins-Esakov 2012-12-31 00:06:24 UTC
There have been no further reports of problems so I am marking this bug resolved.