---- Reported by nengard@gmail.com 2009-12-20 22:27:28 ---- I have gist sys pref set to .09 and I have my vendor's GST set to 12% -- but the order is using the value from the sys pref and ignoring the vendor value. I would think that the sys pref should be the default -but should be overridden by the vendor value if one exists. If you can't have both set then we should make it so that you can't set a vendor gst if there is a sys pref value set. ---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-18 18:02:18 ---- The initial intention in the code appears to be that the vendors gst rate should override the syspref which is logical. (i.e. UK vatrate on books is 0% other EU countries vary) But I don't think it handles overriding it to zero and we need to confirm that it is being consistently applied. Rules need spelling out so that Nicole has a chance to document them. ---- Additional Comments From colin.campbell@ptfs-europe.com 2010-02-19 14:29:41 ---- Additionally: You cannot set a vendor GST/Tax Rate unless the system preference is set to non-zero. It's not clear how these are supposed to mutually operate. ---- Additional Comments From nengard@gmail.com 2010-02-19 14:45:46 ---- If GST (the preference) is set to zero it is supposed to disable GST across the board - that was my understanding. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:21 UTC --- This bug was previously known as _bug_ 3980 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3980 Actual time not defined. Setting to 0.0 Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
I just ran across this today - the difference between a vendor's GST and the syspref GIST. The behaviour I experienced was exactly similar to what is described here. Additionally, if you set the vendor GST with the syspref set, no matter what you put in the vendor (.15, 15.0) it always does .15, which if you are trying to get 15%, is not right. Using the syspref GST, it's always right, and you can put in multiple values, so I'm not sure if there's really a reason to keep the vendor specific GST (there may be, I may just not be thinking of it). Thoughts?
(In reply to comment #1) > I just ran across this today - the difference between a vendor's GST and the > syspref GIST. The behaviour I experienced was exactly similar to what is > described here. > > Additionally, if you set the vendor GST with the syspref set, no matter what > you put in the vendor (.15, 15.0) it always does .15, which if you are > trying to get 15%, is not right. > > Using the syspref GST, it's always right, and you can put in multiple > values, so I'm not sure if there's really a reason to keep the vendor > specific GST (there may be, I may just not be thinking of it). > > Thoughts? There definitely is, and the vendor GST should override the syspref. Differing places have differing sales tax, so different vendors might have different one, the syspref should be a fall back if you have set vendor charges sales tax, and don't have one set, otherwise the vendor specific one should be used. The syspref is a recent(ish) addition which has caused a regression in that vendor specified values no longer work.
It's basically 3 levels now and even if that sounds insane, it makes sense: gist system preference vensor gst gst on order line For example in Germany you pay different taxes for serials and monographs. So if you have a vendor where you buy mostly serials, you will want to set the tax rate to another default then for a vendor you buy mostly monographs. And if you don't want to have multiple vendor entries for the same vendor and different materials, you need the order line gst. I imagine there are places where things are more simple.
What I understand about the way it should be is that : - In system preferences, you can define all the authorized gist, that you will be able to choose in vendor or order - In vendor, you can choose on gist value, which is used mostly by the vendor - In the order, the gist value should be by default the one chosen in the vendor, but you can change it if you want. Do you agree with this ?
(In reply to Koha Team Lyon 3 from comment #4) > What I understand about the way it should be is that : > - In system preferences, you can define all the authorized gist, that you > will be able to choose in vendor or order > - In vendor, you can choose on gist value, which is used mostly by the vendor > - In the order, the gist value should be by default the one chosen in the > vendor, but you can change it if you want. > > Do you agree with this ? I do; moreover, unless I'm very much mistaken, it already works that way (i.e., by default, tax rate for order is the one chosen in vendor)?
Yes, It works that way today in master... But I've done some tests 2 weeks ago and it wasn't like that. It's fine for me. Do we change as "resolved" this bug ?
Yes, this one in no more valid.