[Koha-bugs] [Bug 11458] Confusing description for syspref gist

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11458

Jacek Ablewicz <abl at biblos.pk.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abl at biblos.pk.edu.pl

--- Comment #2 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
(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..

-- 
You are receiving this mail because:
You are watching all bug changes.