Login
Register

VirtueMart

WooCommerce

Others

Docs

Support

Blog

About

Shipping by Rules for VirtueMart

IMPORTANT ANNOUNCEMENT: Plugin development ceased, all plugins made available freely (GPL)

With great sadness we have to announce that we are ceasing development of all our VirtueMart, WooCommerce and Joomla plugins. Effective immediately, all our plugins -- even those that were paid downloads -- are made available for free from our homepage (GPL license still applies), but we cannot and will not provide any support anymore.

It has been a great pleasure to be part of the thriving development communities of VirtueMart as well as WooCommerce. However, during the last year it became painstakingly clear that in addition to a full-time job, a young family and several other time-consuming hobbies at professional level (like being a professional singer) the plugin development and the support that it requires is not sustainable and is taking its toll. It has been an honor, but it is now time to say good bye!

×

Notice

The forum is in read only mode.
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC:

Compatibility issue with VMInvoice for tax calc 17 Oct 2016 12:59 #1

  • yetopen
  • yetopen's Avatar Topic Author
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!

Compatibility issue with VMInvoice for tax calc 22 Oct 2016 23:47 #2

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
  • Page:
  • 1