Bug 3980 - Vendor GST being ignored
Summary: Vendor GST being ignored
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: PC All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Bugs List
URL: cgi-bin/koha/acqui/basket.pl?basketno=8
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-20 10:27 UTC by Nicole C. Engard
Modified: 2014-12-07 20:03 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:21:43 UTC


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

Comment 1 Liz Rea 2012-11-21 02:53:36 UTC
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?
Comment 2 Chris Cormack 2012-11-21 04:08:53 UTC
(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.
Comment 3 Katrin Fischer 2012-11-21 07:41:22 UTC
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.
Comment 4 Koha Team University Lyon 3 2014-03-12 09:14:02 UTC
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 ?
Comment 5 Jacek Ablewicz 2014-03-12 10:18:59 UTC
(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)?
Comment 6 Koha Team University Lyon 3 2014-03-12 10:49:16 UTC
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 ?
Comment 7 Jonathan Druart 2014-03-19 14:15:10 UTC
Yes, this one in no more valid.