The following is an example gstrate for a real library 0|.08625|.0863|.085|.09|.0825|.0875|.075|.07625 Note the .08625 and .0863 Both of those rates show up as 8.6% for the order line editor ( acqui/neworderempty.pl ). There is no reason to force these numbers to be rounded and in fact makes the label not match the value!
Created attachment 41031 [details] [review] Bug 14541 - Tax rate should not be forced to an arbitrary precision The following is an example gstrate for a real library 0|.08625|.0863|.085|.09|.0825|.0875|.075|.07625 Note the .08625 and .0863 Both of those rates show up as 8.6% for the order line editor ( acqui/neworderempty.pl ). There is no reason to force these numbers to be rounded and in fact makes the label not match the value! Test Plan: 1) Set you gstrate pref to 0|.08625|.0863|.085|.09|.0825|.0875|.075|.07625 2) Edit an order line 3) Note that the tax rate pulldown lists 8.6% twice 4) Apply this patch 5) Refesh the page 6) Note the pulldown now lists the actual tax rate values
Upping severity as this deals with money. It's possible for a librarian to accidentally select the wrong tax rate due to this bug!
Patch applied cleanly and works as expected, signing off
Created attachment 41075 [details] [review] Bug 14541 - Tax rate should not be forced to an arbitrary precision Work without error.
Kyle, The tax rate is displayed at several places, at least acqui/supplier.tt. The change should affect all the places where it is displayed. You should also have a look at how I display them on bug 13323 using a template plugin: [% order.gstrate * 100 | $Price %] I can provide a patch on top of bug 13323 if you can wait for it to be pushed.
Hm, is the Price plugin the right one there? Because it's not an amount but a percentage value?
(In reply to Katrin Fischer from comment #6) > Hm, is the Price plugin the right one there? Because it's not an amount but > a percentage value? I'd say yes, we could add an option to the plugin later (something like "display as %").
For me Price feels not right - and only 2 decimals I think? not enough for the percentage?
(In reply to Katrin Fischer from comment #8) > For me Price feels not right - and only 2 decimals I think? not enough for > the percentage? It's better than 1, and the patch suggested to set it to 2, what the plugin does.
Hm, but is 2 enough? Int wouldn't be for Kyle's example. Maybe we should just display 'as it is configured' and not cut it off. .07625 would be 7.625 I think?
(In reply to Jonathan Druart from comment #5) > Kyle, > The tax rate is displayed at several places, at least acqui/supplier.tt. > The change should affect all the places where it is displayed. > You should also have a look at how I display them on bug 13323 using a > template plugin: [% order.gstrate * 100 | $Price %] > > I can provide a patch on top of bug 13323 if you can wait for it to be > pushed. That works for me Jonathan!
Jonathan, now that bug 13323 has been taken care of, can you follow up on this? Thanks! (In reply to Kyle M Hall from comment #11) > (In reply to Jonathan Druart from comment #5) > > Kyle, > > The tax rate is displayed at several places, at least acqui/supplier.tt. > > The change should affect all the places where it is displayed. > > You should also have a look at how I display them on bug 13323 using a > > template plugin: [% order.gstrate * 100 | $Price %] > > > > I can provide a patch on top of bug 13323 if you can wait for it to be > > pushed. > > That works for me Jonathan!
Created attachment 57363 [details] [review] Bug 14541: Do not truncate tax rate values Tax rates are stored in decimal(6,4) fields which means that 4 decimals are allowed. If a tax rate is 8.42%, it is stored as 0.0842 If a tax rate has more precision than that, Koha won't deal correctly with it. We will need to update the DB structure. With this patch, the tax rate will be displayed with the same precision as in the DB. So if you enter 8.42, you will see 8.42% instead of 8.4% without this patch. Test plan: Do a full acquisition workflow with a tax rate like 8.42% and confirm that it is correctly displayed.
*** Bug 10253 has been marked as a duplicate of this bug. ***
Created attachment 57872 [details] [review] Bug 14541: Do not truncate tax rate values Tax rates are stored in decimal(6,4) fields which means that 4 decimals are allowed. If a tax rate is 8.42%, it is stored as 0.0842 If a tax rate has more precision than that, Koha won't deal correctly with it. We will need to update the DB structure. With this patch, the tax rate will be displayed with the same precision as in the DB. So if you enter 8.42, you will see 8.42% instead of 8.4% without this patch. Test plan: Do a full acquisition workflow with a tax rate like 8.42% and confirm that it is correctly displayed. Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
This works, one issue is that the pref allows you to enter any number of decimals. These are then displayed in full on the dropdowns, however, they are saved into the db truncated. Example: In gist preference: .12345 Shows in dropdowns as: 12.345% Saves to db as: .1235 Shows in order/basket tables as: 12.35% We should either truncate the dropdowns or add a warning in the system preference
(In reply to Nick Clemens from comment #16) > This works, one issue is that the pref allows you to enter any number of > decimals. These are then displayed in full on the dropdowns, however, they > are saved into the db truncated. > > Example: > > In gist preference: .12345 > > Shows in dropdowns as: 12.345% > > Saves to db as: .1235 > > Shows in order/basket tables as: 12.35% > > > We should either truncate the dropdowns or add a warning in the system > preference The database is limited to 4 digits of precision. I think for the time being a warning on the system preference should be sufficient. I *do* think the order/basket tables should show 12.345%. We should not be rounding where we don't need to.
> The database is limited to 4 digits of precision. I think for the time being > a warning on the system preference should be sufficient. I *do* think the > order/basket tables should show 12.345%. We should not be rounding where we > don't need to. Had a brain fart there. 12.245% would be truncated because of the db limit. As such, only the warning is necessary.
Created attachment 58050 [details] [review] Bug 14541: Do not truncate tax rate values Tax rates are stored in decimal(6,4) fields which means that 4 decimals are allowed. If a tax rate is 8.42%, it is stored as 0.0842 If a tax rate has more precision than that, Koha won't deal correctly with it. We will need to update the DB structure. With this patch, the tax rate will be displayed with the same precision as in the DB. So if you enter 8.42, you will see 8.42% instead of 8.4% without this patch. Test plan: Do a full acquisition workflow with a tax rate like 8.42% and confirm that it is correctly displayed. Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 58051 [details] [review] Bug 14541 (QA followup) Add warning to gist system preference Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Pushed to master for 17.05, thanks Jonathan, Nick!
These patches have been pushed to 16.11.x, will be in 16.11.01.
Pushed to 3.22.x for 3.22.14