| Summary: | Vendor GST being ignored | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
| Component: | Acquisitions | Assignee: | Bugs List <koha-bugs> |
| Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | abl, chris, colin.campbell, jonathan.druart, koha, liz |
| Version: | Main | ||
| Hardware: | PC | ||
| OS: | All | ||
| URL: | cgi-bin/koha/acqui/basket.pl?basketno=8 | ||
| See Also: |
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11680 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11733 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Chris Cormack
2010-05-21 01:21:43 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? (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. |