TOPIC:

Hi,
I'm using your plugin Advanced Shipping Rules with VirtueMart and also VMInvoice for managing orders and invoicing. Everything is working quite well but I have a problem with the tax calculation for the shipping when modifying orders from the backend, using VMInvoice.
In the modifying view of an order I select the shipping method (created with the plugin) and when I click 'Apply', to recalculate the shipping costs, I get two lines for the applied taxes.
I debugged a little bit and I thing I get the problem.
Standard shipment plugins of VirtueMart allow to configure just one tax rule for each shipment method defined but in yours is possible to set more than one tax rule (one for each calculation rule) for one shipment method. VMInvoice when recomputes shipping costs gets the shipping method from VirtueMart ( $shipping = VMInvoice3Getter::getShippingsVM2($order->shipment_method_id) ) and then checks if the tax rule is set in the shipment method ( if ($shipping->shipment_params->tax_id>0) { ... ). The problem is that when a shipment method is defined with ADV_shipping_rules there is no attribute 'tax_id' in the object 'shipment_params' but there are more attributes: 'tax_id1', 'tax_id2' and so on...This leads to a wrong calculation of applied taxes because the one selected is not recognized.

I tried to force VMInvoice to use the attribute 'tax_id1' for instance and everything seams to work fine. I can use this like a temporary fix but obviously it can't be the final solution.

I also tried to update the plugin to the last version but nothing changes.

May you provide a fix for these issue?

Thanks, best regards!

Dear Yetopen,
From your description, it appears that VMInvoice calls the vmPSPlugin functions to get the shipping cost, but does not actually emulate the whole cart (in particular, it does NOT call the shipping plugin's setCartPrices function, which would properly calculate taxes, etc.).
Instead it tries to make a shortcut by relying on the way one particular shipping plugin implements tax handling. I'm sure this breaks with other plugins, too.

This is clearly not a but in our plugin, let alone fixable within our plugin. It is a flaw in the way VMInvoice handles shipping plugins and their tax. I'm sorry, but I don't see an easy way to "fix" (i.e. workaround a shortcoming in VMInvoice) in our plugin. In particular, the handling of tax_id and tax_id1 is not done with code in our plugin, but they are set from the VM core based on the parameter definitions given in the plugin's xml manifest. There is no way to add an additional tax_id field without also showing it as a plugin configuration parameter in the shipping method configuration...

I'm afraid your workaround is the easiest way to work around this VMInvoice assumption.

Best regards,
Reinhold