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!
Welcome,
Guest
|
|
Have you planned or it is possible to add a floor("up") or round("up") operation between the valid operators to the shipment by rules plugin?
I mean, here at Spain , the postal service makes you pay a kind of "ensurance" which depends on the value of the shippment and which is stepped in 50€ (or fraction) steps. It is: a shipment with products for 49€ will mean a step, a shipment of 51€ will mean 2 steps, and so on... So it will be really appreciate a operator or suggestion to solve this issue, becuase I guess this kind of "stepped" taxes are usual not only at Spain. floor(amount/50) which gives the closest int number (rounding to upper int) Maybe you have already solved this by using modulus operation or similar but I am not able to figure it out?? Hope you can put some light on my ignorance. |
|
Sorry for replying my own post, but maybe current solution cold be similar to:
Stepped Ensurance Cost = StepTax * (1 + (GoodsValue - (GoodsValue%StepValue))/StepValue) being: StepTax : the tax you have to pay for each step GoodsValue : the Value of the Goods you have to ensure on your shipment StepValue : the money which defines a step A little bit "complicated" for my point of view, to solve a such as usual issue. |
|
It is on my TODO-List to add some basic functions (that's the only feature that is still left). However, implementing this in the rules parser is not as easy as it sounds (and I currently don't have time for any new developments). I agree that it would be quite useful, though.
So, for now you need to use the workaround with the modulo... Sorry, Reinhold |
|
Version 3.0.0 is now available, which adds the following features:
-) Functions like round(..), ceil(...), max(...), min(...) -) New variables TotalPackaging, MinPackaging and MaxPackaging -) Variable substitutions in the rule names: {varname} will be replaced by the value |