Bug 11458 - Improve description for syspref gist
Summary: Improve description for syspref gist
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Katrin Fischer
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-29 22:56 UTC by mathieu saby
Modified: 2016-06-21 21:38 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: String patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 11458: Improve confusing description of syspref 'gist' (1.81 KB, patch)
2015-06-09 22:14 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 11458: Improve confusing description of syspref 'gist' (1.86 KB, patch)
2015-06-10 03:57 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 11458: Improve confusing description of syspref 'gist' (1.93 KB, patch)
2015-06-19 13:13 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description mathieu saby 2013-12-29 22:56:50 UTC
The description of "gist" is:

"Default tax rates are .............. (enter in numeric form, 0.12 for 12%. First is the default. If you want more than 1 value, please separate with |) "


The use of "default" is confusing here.

It should be "Authorized (Possible ?) tax rates are...."




M. Saby
Comment 1 mathieu saby 2014-02-17 19:18:05 UTC
We should also describe the behavior if no value is entered.

I am not sure of my english...
What do you think of

"Possible tax rates are .............. (enter in numeric form, 0.12 for 12%. If you want more than one value, separate them with |. First value is the default one. Keep blank if no tax rates are usable at all."

?

Mathieu
Comment 2 Jacek Ablewicz 2014-02-18 19:28:06 UTC
(In reply to mathieu saby from comment #1)

> What do you think of
> 
> "Possible tax rates are .............. (enter in numeric form, 0.12 for 12%.
> If you want more than one value, separate them with |. First value is the
> default one. Keep blank if no tax rates are usable at all."

I'm not a native speaker, but:

   s/usable/used/

or

   s/no tax rates are usable at all/you don't want to use any tax rates at all/

may be a little better wording IMO. 

Additionally, 'gist' variable in systempreferences 'explanation' field seems to be outdated as well:

   gist     | 0|0.05|0.08|0.20|0.23 |         | Default Goods and Services tax rate NOT in %, but in numeric form (0.12 for 12%), set to 0 to disable GST | Integer 

'Integer' type for this variable may also be not quite right any longer (= it has 'type' set to 'Float' for a little while too), but I don't think it does have any visible impact on the practical side (?).

This part

> We should also describe the behavior if no value is entered

got me thinking: right now, if the default value (which is still '0' by default for the new installations - I'm not so sure it's the best possible default choice any more ???) is changed from '0' to '' / blank:

1) some scripts in acqui/* (supplier.pl, neworderempty.pl) will behave a lot better (tax related settings will not appear on order / supplier record edit at all - so far, so good)
2) some other acqui/* scripts (basket.pl. invoice.pl, ..) may throw extra warnings in *error*.log ("Use of uninitialized value ... in [addition|multiplication] in blah blah") - maybe not all that good, but I think the actual tax calculations will (mostly ?) remain unchanged after setting 'gist' to blank; in any case, tax calculations in those particular scripts are currently somehow questionable anyway (depending of the settings in vendor records) - generally speaking, I think they all should take into account the "more granular" tax rates from the order records, and NOT the "default" tax rate from the vendor record / "default" gist system preference.

For many libraries (perhaps the *wast* majority IRL ?) which are not willing to enter/use/maintain a whole lot of different tax rates etc. for the individual order/vendor/... records (i.e.: those ones just wanting to simply enter *actual* prices they pay for the items, *anywhere* in the acquisition - never mind if the prices are with, or without tax = what they pay is what actually counts for them!), ALL tax-related functionality ideally should be (optionally = e.g., if the gist setting is blank) disableable and/or hidden *anywhere* in the acquisition. But it would require a lot of changes in great many places..
Comment 3 mathieu saby 2014-02-18 21:05:42 UTC
Wooo, there are more problem than I thought...


> 
> For many libraries (perhaps the *wast* majority IRL ?) which are not willing
> to enter/use/maintain a whole lot of different tax rates etc. for the
> individual order/vendor/... records (i.e.: those ones just wanting to simply
> enter *actual* prices they pay for the items, *anywhere* in the acquisition
> - never mind if the prices are with, or without tax = what they pay is what
> actually counts for them!), ALL tax-related functionality ideally should be
> (optionally = e.g., if the gist setting is blank) disableable and/or hidden
> *anywhere* in the acquisition. But it would require a lot of changes in
> great many places..


Why not, but I assure you that in France, every library really need to have several gst rates, because tax rate for books and other documents (serials, dvds...) are not the same.
So, our first priority regarding tax rate would be to fix current behavior on some pages, which is sometimes wrong (see bug 10613, bug 11681, bug 10461, bug 11062, bug 7686, bug 7495, bug 3980, bug 2865 )

Mathieu
Comment 4 Jacek Ablewicz 2014-02-19 08:37:23 UTC
(In reply to mathieu saby from comment #3)

> 
> Why not, but I assure you that in France, every library really need to have
> several gst rates, because tax rate for books and other documents (serials,
> dvds...) are not the same.

We have just ;) 4 tax rates for different kinds of materials: 0% 5% (used to be 0%) 8% 23% (used to be 22%). This is what happens when our beloved, democratically selected leaders have way to many field days revising tax code.

> (see bug 10613, bug 11681, bug 10461, bug 11062, bug 7686,
> bug 7495, bug 3980, bug 2865 )

Not to mention bug 11733, bug 11680, bug 11520 and maybe bug 11755 too..

I say we take off and nuke the entire site from orbit. It's the only way to be sure ;)
Comment 5 Katrin Fischer 2015-06-09 22:14:26 UTC Comment hidden (obsolete)
Comment 6 Aleisha Amohia 2015-06-10 03:57:09 UTC Comment hidden (obsolete)
Comment 7 Jonathan Druart 2015-06-19 13:13:36 UTC
Created attachment 40369 [details] [review]
Bug 11458: Improve confusing description of syspref 'gist'

The description of "gist" was:

"Default tax rates are ... (enter in numeric form, 0.12 for 12%.
First is the default. If you want more than 1 value, please
separate with |) "

The doubled use of "default" is confusing here.

With the patch it reads:

Tax rates are ... Enter in numeric form, 0.12 for 12%.
The first item in the list will be selected by default.
For more than one value, separate with | (pipe)

To test:
- Verify that the gist system preference description is
  correct.

The use of "default" is confusing here.

Signed-off-by: Aleisha <aleishaamohia@hotmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Comment 8 Tomás Cohen Arazi 2015-06-22 14:40:27 UTC
Patch pushed to master.

Thanks Katrina!
Comment 9 Chris Cormack 2015-06-29 09:50:48 UTC
Pushed to 3.20.x will be in 3.20.2
Comment 10 Liz Rea 2015-07-20 22:05:39 UTC
Pushed to 3.18.x will be in 3.18.09
Comment 11 Mason James 2015-07-25 10:41:30 UTC
Contains string changes, holding till 3.16.14