Closed (fixed)
Project:
UberPOS
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
21 Feb 2010 at 19:07 UTC
Updated:
13 Apr 2010 at 01:30 UTC
Jump to comment: Most recent file
Comments
Comment #1
slip commentedNot sure but this seems like it might be a configuration error. We don't use VAT so testing is a bit of a hassle. Maybe paulgrimshaw or another VAT user can confirm?
Comment #2
techypaul commentedHi,
I can confirm this is working a-ok on my system. ludde_t, are you using the latest uc_vat? Any other VAT/tax related modules installed?
P.
Comment #3
techypaul commentedComment #4
ludde_t commentedHey,
Thanks for the replies.
Using UC_VAT 1.x-dev 2009-dec-02. Upgrading to the latest dev release did not solve the problem (2010-mar-05).
No other vat/tax related modules..
Still not able to get this right.. Any ideas on what config options could cause this?
It's not critical for me, as it's shown correctly when ringing up the order but I would like to fix it as it confuses the cashier.
Since it's working for paulgrimshaw I'll go at it again and try to find the cause..
Thanks,
//Ludvig
Comment #5
techypaul commentedquickly posting on tube so might miss something, but here are my settings. Everything is unticked except:
Tax rate and settings / Overview:
Standard 17.5% Any product
> edit > Apply tax to any product regardless of its shipability. Only thing ticked.
Tax rate and settings / VAT Settings:
Inclusive: List/Cost ticked
Keep VAT prices same ...
Cant think of anything else which has an effect. Is the item you are using have attributes?
P.
Comment #6
techypaul commentedI have just upgraded to the latest version, actually not done any updates for a while. I made no changes to the DB apart from running update.php and I made no changes to any other ubercart modules or settings as far as I am aware.
All of a sudden I now get prices exluding VAT where before it was working fine. For example, if I enter 1.00, e.g. 100SP999 I used to get 1.00 as the final figure, now I get 1.18 so it is taking the entered price as vat exclusive rather than vat inclusive.
I am marking this as critical as whilst I cannot be 100% sure its not something I have done, it is similar to this other problem and its rather important for us in VAT areas - anyway to someone else can test this? Can I downgrade safely to a previous version for testing?
Thanks,
Paul.
Comment #7
techypaul commentedfyi, just opened an old order using the OR command and get the same problem ludde_t gets.
Comment #8
slip commentedOK, I'll take a look when I get a chance. If anybody wants to take a shot at making a patch that would be great. I think I'll fix this one and the stock bug and make an alpha release so we can have a true dev branch.
Comment #9
slip commentedHah! so, this was caused during a big code cleanup..
Here's a patch. Anybody up for testing?
Comment #10
techypaul commentedHi,
Tested - this fixes the OR/ludde_t problem with recovering orders but it makes no effect on the problem I am having with actually making a sale. Have I missed something?
Thanks,
Paul.
Comment #11
slip commentedPlease try this out
Comment #12
slip commentedactually, now that I think about it... that call to db_rewrite_sql() doesn't make any sense.
Try this one.
Comment #13
techypaul commentedYay! Working perfectly for me :).
Thanks for your help with this, very much appreciated.
p.
btw, .12 tested.
Comment #14
slip commentedThanks guys!
http://drupal.org/cvs?commit=347974