News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

[FIXED] VAT are not saved on my products

Started by fmmarzoa, February 23, 2009, 10:52:08 AM

Previous topic - Next topic

fmmarzoa

Hello there,

My name's Francisco and I'm from Spain. I'm building a VirtueMart shop for my site "lacuruxa.es" in a testing host on my home, but I'm having problems. I've observed that taxes where not being calculated on orders, then I saw that my created products has no taxes asigned. So I did edit these products through "Update Item::<product>" for each of them, and selecting the tax it should be applied on "Product Informatio/Vat Id" from the dropdown combo box -177 (16%)-. The fact is that even "Product Gross" is then recalculated, then I save the product clicking on "Save" button, it gives no error messages, warnings or so, but if I return to the product again I see that Vat Id is... -0- NONE! :-(

I'm using VirtueMart 1.1.3


P. S. Excuse my english.

fmmarzoa

More on this: I've checked that it's saving a value of "127" on database where it should be "177" :-? :-?

In the same product of the previous example:

mysql> select product_name, product_tax_id from jos_vm_product where product_id=18\G
*************************** 1. row ***************************
  product_name: Vacuosu
product_tax_id: 127
1 row in set (0.00 sec)

And there's no tax rate with that tax_rate_id:
mysql> select * from jos_vm_tax_rate where tax_rate_id = 127;
Empty set (0.00 sec)

That I do not understand is why if I'm telling it to use this one:

mysql> select * from jos_vm_tax_rate where tax_rate_id = 177\G
*************************** 1. row ***************************
tax_rate_id: 177
  vendor_id: 1
  tax_state: -
tax_country: ESP
      mdate: 1234260976
   tax_rate: 0.1600
1 row in set (0.00 sec)

It's using the inexistent "127" instead. Maybe that I've used it before, as this is a testing site and I did some changes on taxes also, but if this is the case, it may be a bug as I'm telling it now to use "177".

I'll try reseting those product's taxes to 0 by hand on database...

fmmarzoa

I've reseted it to 0:

mysql> update jos_vm_product set product_tax_id=0 where product_id=18;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select product_name, product_tax_id from jos_vm_product where product_id=18\G
*************************** 1. row ***************************
  product_name: Vacuosu
product_tax_id: 0
1 row in set (0.00 sec)


But as soon I update it through backend to assign the tax #177, it saves again 127 instead of 177.

I've look at the source of the backend page, and the list is correct:

<option value="0">0 (-none-)</option>
<option value="177">177 (16%)</option>
<option value="2">2 (8.25%)</option>
<option value="178">178 (7%)</option>

So the problem should be in another place. Perhaps 127 is an undocumented limit for tax id or so???

fmmarzoa

#3
That's the point: product_tax_id is declared as tinyint(2) on database, so I think its high limit will be 127 and that's the real problem.

In jos_vm_tax_rate the tax_rate_id is a int(11), so I thing this is a bug and should be corrected.

As a workaround I've done:
alter table jos_vm_product modify column product_tax_id int;

Then I updated the product through the admin backend and it did work!! :-)