Author Topic: Custom field price calculation  (Read 2474 times)


  • Beginner
  • *
  • Posts: 11
Custom field price calculation
« on: September 24, 2015, 18:04:52 pm »

First of all, thanks to the VM Developers, for all your nice work. I'm now in the middle of my fourth VM installation for a Client an once again I'm stumbling upon the following problem.

The Problem:
Custom field prices will be added to the base price and then the discount i calculated. I've had different cases where I needed to add the custom field price after the discount is applied to the sales price.

There are also a couple of other posts about this or related Problems in the forum:

My unsatisfying solution:
Since I try to avoid hacking the VM core files like the plague, because you will run sooner or later into troubles if you do it. And every time you update the shop you have to apply and test your hacks.

So, for custom field prices that should ignore the discount on a product I use the a modified version of the dropbox Plugins. The plugin just adds the product discount( I included also the VAT, one of my customers is so bad in math :) ) to the price modificator. Like this, the plugin adds the exact amount you specified to the sales price. But there is a slight Problem you have to live with! Technically it will show the wrong base price since the custom field price modificator includes the discount! If someone is interested in the modifications you'll find it at the end of this post.

The proper solution
In my opinion the proper solution for this problem is to add a new parameter to custom fields to specify how the price modificator should be applied ( before or after the product discount is applied ).

So practically you have to extend the calculation rule for the sales price to something like the following: 
The current base price calcualtion: ( "base price" + "custom field prices" ) * discount = "sale price"
The new sales price calculation: ( "base price" + "custom field prices before discount" ) * discount ) + "custom field prices after discount" = "sale price"

So I'd like to hear from the Developers
 - Can it be done without interfering to much with the existing calculation rules?
 - Is this already on someone‚Äôs Todo list?

So far I didn't look at the VM code. But if no one is already working on this, and you think it's feasible. I'll would give it a shot and try to work out a way to implement this.

Regards Thomas

VM 2 Dropbox plugin and modification
Dropbox Plugin VM2:

The following code is for the VM2 Dropbox Plugin only.
I was in a hurry to get the shop working and so I hard coded the VAT for my country. If you want to use it you need to change the VAT according to your country or improve the code to pull the VAT from the product or remove it entierly.

Code: [Select]
--- a/src/plugins/vmcustom/drop/drop.php
+++ b/src/plugins/vmcustom/drop/drop.php
@@ -1,9 +1,14 @@
-defined('_JEXEC') or   die( 'Direct Access to ' basename__FILE__ ) . ' is not allowed.' ) ;
defined('_JEXEC') or die( 'Direct Access to ' basename__FILE__ ) . ' is not allowed.' ) ;
//@Banquet Tables Pro custom dropbox plugin.
 //Lets go 2.0
-if (!class_exists('vmCustomPlugin')) require(JPATH_VM_PLUGINS DS 'vmcustomplugin.php');
+if (!
class_exists'vmCustomPlugin' )) { 
+       require(
JPATH_VM_PLUGINS DS 'vmcustomplugin.php');
+if (!
class_exists'calculationHelper' )) {
+       require (
JPATH_VM_ADMINISTRATOR DS 'helpers' DS 'calculationh.php');
plgVmCustomDrop extends vmCustomPlugin {
@@ -
74,11 +79,25 @@ class plgVmCustomDrop extends vmCustomPlugin {
$valueWithPrice explode('|'$valuesWithPrice);
                                if ( 
$customVariant['custom_drop'] == $valueWithPrice[0])  {
-                                       if ( isset (
$valueWithPrice[1]) ) {
+                                       if ( isset (
$valueWithPrice[1]) ) { 
$op $valueWithPrice[1][0];
$cValue substr($valueWithPrice[1], 1);
$valueWithVAT = (float) ($cValue/0.8) / 1.08;
$discount 1;
$VAT 1.08;
$cHelper calculationHelper::getInstance();
$prices $cHelper->getProductPrices$product );
$discounts $prices['DATax'];
+                                               if( !empty( 
$discounts ) ) {
$keys array_keys$discounts );
$discount -= $discounts$keys[0] ][1] / 100;
+                                               }
//print_r( $discount );
+                                               //$discount = $product->salesPriceWithDiscount / $product->basePriceWithTax;
+                                               $valueWithVAT = (float) ($cValue/$discount) / $VAT;
                                                if (
$op == '+'$productCustomsPrice->custom_price $valueWithVAT;
// testing equals
else if ($op == '='$productCustomsPrice->custom_price = -$product->product_price+$valueWithVAT;

VM3 Dropbox Plugin
Dropbox Plugin VM3:
I did not make the modification yet. But I'll post them here as soon as possible...


  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 10070
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Re: Custom field price calculation
« Reply #1 on: September 24, 2015, 21:57:55 pm »

is not related, he uses the override price option, which always sets the final price to the override, no matter which discount.
I should fix your bug, please support the VirtueMart project and become a member
Extensions approved by the core team:


  • Beginner
  • *
  • Posts: 11
Re: Custom field price calculation
« Reply #2 on: September 24, 2015, 23:30:01 pm »
Hi Milbo,

Yes and depends somewhat on the point of view.
I have to deal with different customers that don't know these "details". They just want to mange their products and sell stuff...:)
Some of these customers just do not understand the actual concept of the override price option. They except the custom value price to be applied no matter what( with discount or without ), and for certain products I have to admit It makes sense.

I understand the concept of the override price option and I agree that it's technically not related. But it's how I said in my previous post. I didn't take a look at the code yet, and I can't really argue with you about it.

But if you introduce a parameter to define how the custom price is used, could empower custom fields a lot.
You could have also multiple options:
 - default(like now)
 - before discount (not on price override)
 - after discount( not on price override)
 - always( the price gets always applied, how it's defined)

So back to my question, is this feature worth to explore it or is it to much trouble to take on.