Wrong VAT calculation when editing order

[n3t]

Hi,

I found wrong VAT calculation in VM when editing already stored order, could someone confirm this issue?

Steps to reproduce
- Normally from FE order some product that has included some tax.
- open the order in BE, you should see product with price without tax, total price, and than on separate line shipping and payment fee (if present), then one line with tax calculation rule (such as VAT 21%) and sum line with total VAT and sum per order
- click to edit item, do not change anything and click to save
- see how total changed

Seems like, for some reason, there is edit field even for line with tax calculation rule, which after storing, is not calculated again, but stored as is, and added to total TAX sum. Means that the result is, that the VAT is calculated twice.

Pavel

[AH]

http://forum.virtuemart.net/index.php?topic=79800.0

[n3t]

VM 3.0.16
Joomla 3.5.1

[Marion]

Hi

I'm having the same issue, just a little different.

Joomla version 3.5.1
VirtueMart version 3.0.16 and 3.0.14
php version 5.6.21

I'm using the German version, so I hope that I'm translating all the terms correctly.

I'm importing my products as SQL statements in phpMyAdmin. For each product there is a price imported into the correct table. This price is shown correctly in the backend. First I chose to apply "VAT" rule to the base price. I then realised that net price was shown with VAT and full price with 2 x VAT. So I changed in one product the rule to "standard rules" instead of "VAT". This changed correctly the rule for all products.

Now in the backend the net price and full price are both the same (both without VAT). That's a minor problem, as long as the front end shows prices correctly. But - the front end is still showing the old version with 2 VATs on full price. If I open a product in the backend and save it without changes, the front end shows the price correctly.

Why do the prices not change automatically? Do I have to open manually every product and save it to have correct prices? I've got 600 products... 

Can you please confirm the bug? And is there a workaround until the bug is eliminated?

Thank you for your help!

[Marion]

I did some further testing.

Changing from rule "VAT" to general rule does't seem to have an influence, because changing back didn't. Backend prices are sometimes correct, sometimes not. The essential difference for correctness in frontend is if a product has been opened in the backend or not.

Reading that 3.0.16 seems to be instable I set my test installation back to 3.0.14. Problem still remains.

Please allow me to mention that the issue is very urgent. The shop is of no use at all if prices are wrong.

[AH]

Can you please confirm the bug?

No - I cannot confirm this as I have no idea what you are doing

You say you imported via SQL direct into tables

Instead try and add a new product using the VM administrator

Then review this new product for VAT display and calculation

When you have done this - come back here and report your results

[Marion]

Instead try and add a new product using the VM administrator

Then review this new product for VAT display and calculation

When you have done this - come back here and report your results

If I do it like this, VAT display and calculation are correct. This is no surprise. As I mentioned, if once opened and saved in backend they show correct.

The problem seems to be that the calculation is executed when a product is saved in the VM administration. If products are added by import, the calculation is not executed. And that's a bug in my opinion. Price calculation should be executed whenever a product is displayed. Or at least there should be an update script like the one for images.

The background of my SQL statements: I need to add a lot of products. Adding them in the VM administration is too slow. That's why I generate SQL-statements from product "raw" data and I can import a lot of products within seconds.

[AH]

Thank you for the confirmation.

From what I can fathom, there is no "bug" in VM relating to VAT calculation - As I anticipated, it is your SQL population of data that is incorrect.

"And that's a bug in my opinion. "  Or at least there should be an update script like the one for images.

How can that be a bug? You need to update ALL relevant database fields for the tables you are directly importing into and any other related tables

I am unsure as to why VM should try and sort out the mess you have created when you have not populated the necessary fields.

[n3t]

Ok, Marion's issue is completely different with the one I opened.
My issue is upon editing the order, not the product itself.
Products are inserted correctly through administration (even some could be still imported from VM 1).
During checkout process everything works fine, in the product everything is calculated well, just when editing order, total TAX is calculated wrong
(per product Tax is still calculated correctly).

[Marion]

I'm a database speshitpillt and I know very well what I'm doing, otherwise I would't do changes on the DB directly. Every necessary field was filled out and everything linked correctly. It was my mistake though, I must admit. I took the numeric currency code as ID. When I saved an unchanged product, the ID was corrected. I'm sorry that I insisted on it being a bug. N.B. a single SQL statement fixed it all  . I can't see any alternative to SQL updates to VM, import extensions are not up to date, and you don't expect users to type in hundreds of products manually, do you?

To add something useful to the thread instead, I tried to reproduce Pavel's error. In my case it was not the total amount of tax that changed, but the total order price - see picture.
Correct total order price is 32.85.

[lindapowers]

Ok, Marion's issue is completely different with the one I opened.
My issue is upon editing the order, not the product itself.
Products are inserted correctly through administration (even some could be still imported from VM 1).
During checkout process everything works fine, in the product everything is calculated well, just when editing order, total TAX is calculated wrong
(per product Tax is still calculated correctly).

Yes I get the same result as you, actually it has been like that for years, to the point where we never edit an order and in case we have to modify it we create a new one due to the issue we both get.

I used to get also the final price modified.

To be honest we have not tested it for a long time cause it never worked, editing orders always broke calculations and it was a real pain adjusting prices.


Regards

[franzpeter]

Why don't you use a hidden category for the VAT? Create a category called VAT rate. Set it to hidden. Go to calculation rules, enter your desired VAT rate and choose the VAT category you did create before. If you import via database it should not be a big problem. I think you put your products into categories. So you fill in the product_categories table. So for each product you just need to create here an entry for the normal category and an additional one for the VAT category.

[lindapowers]

BTW I just tried editing an order adding a product, saving and it never gets added O_o

[AH]

Marion - Thank you for the update - we all make mistakes 

Many of us do direct database updates and have felt your pain!

I can't see any alternative to SQL updates to VM, import extensions are not up to date, and you don't expect users to type in hundreds of products manually, do you?

Not if they have an alternative method, such as direct product creation using SQL statements and CSV or some other data files.

I am not sure how up to date the CSVI import utility is regarding even simple product creation.

Maybe you could post your scripts on a different thread to give back to the community?

[franzpeter]

CSVI Pro is up to date!