Bug 11458

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

(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..

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

(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 ;)

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>

Patch pushed to master.

Thanks Katrina!

Pushed to 3.20.x will be in 3.20.2

Pushed to 3.18.x will be in 3.18.09

Contains string changes, holding till 3.16.14