VirtueMart 2.0.12b - Discount amount always showing?

[gmartin]

Hi all!

After an update from 2.0.10 to 2.0.12b I get for every product an discount amount of 0.00 showing.

Usually the discount amount is displayed even if it is not empty, right?

I use an override file, so I added for testing an vardump and it says "float(1.0E-6)". That means, the discount amount isn't empty at all.

What is wrong? Some configuration/update stuff?


Thx a lot!


[attachment cleanup by admin]

[Lorrein]

It might be that in the product has a value entered in the override field and also has override disabled selected in the product

[sysman]

I noticed same problem when I updated to 2.0.12b.  I thought it may be related to the template I am using for my website (e-sport GavickPro), so I reverted to 2.0.8e and all is back to normal for now.

[bytelord]

Hello,
Yes i have that issue also. Some of my products have 0.00cur value so they are not empty or return me the float you just said. The strange is that this happens for certain products only, not for all products. But this happen cause of the new rounding functions, for example sometimes when calculating final price or relative gives a value to discount or tax something like 0.0001, or similar, so the price is not empty and for that reason the rounded discount is 0.00 if is configured to 2 or -1. So we have two solutions for that on our templates (using round):

To resolve this at the moment i did the following:

1st solution:

Code Select Expand

if (round($product->prices['basePriceWithTax'],VmConfig::get('salesPriceRounding')) != $product->prices['salesPrice']) {
echo $this->currency->createPriceDiv ('discountAmount', 'COM_VIRTUEMART_PRODUCT_DISCOUNT_AMOUNT', $product->prices);
    }

the above is for category view, around line 296 (com_virtuemart/views/category/tmpl/default.php) - you could use that expression for discount and please also update your template ... take a look here: http://dev.virtuemart.net/attachments/download/492/com_virtuemart.2.0.12_layout_changes.zip

Now, if you want to use an if statement like if $product->prices['discountAmount'] ... you have to round the value so the floating be removed, like the following example that will have the same results as the above:

2nd Solution:

Code Select Expand

if (round($product->prices['discountAmount']) != '0' ){
echo $this->currency->createPriceDiv ('discountAmount', 'COM_VIRTUEMART_PRODUCT_DISCOUNT_AMOUNT', $product->prices);
}


On the second solution we placed not equal to zero (0) because there is may be a negative discount, so we want our store works with positive and negative discounts.

Hope it helps you out

Regards

[muskes]

Go to:

Products -> Taxes & Calculation Rules

Change the field "Type of Arithmetic Operation" from "Tax per product" to "Vat tax per product" 

...this should work.

Regards,
Muskes

[bytelord]

Hello,

Yes it is working, seems that vat tax calculated based on rounded prices, but tax per product without rounding...

Thanks for the observation

Regards

[muskes]

you´re welcome 

[gmartin]

Go to:

Products -> Taxes & Calculation Rules

Change the field "Type of Arithmetic Operation" from "Tax per product" to "Vat tax per product" 

...this should work.
[...]

Thanks a lot!
That worked for me!

Nice to know.

[Lorrein]

Great,

that works for me to.

[AH]

Sounds like a bug.

VM should not return a value for discount when the VIRTUEMART_PRODUCT_PRICES has OVERRIDE set to NULL or OVERRIDE price set to 0.000 and PRODUCT_DISCOUNT_ID is set to 0 there is no Discount and nothing should be shown.

[bytelord]

Hello Hutson,

It caused by round prices because discount could be applied with other ways too, like coupon, or mass discount, or discount rule, so override is not the only option. When checking prices could be happen the following:

e.g. sales_price                 1.12345 [rounded(-1)= 1.12],
       base_price_with_tax  1.12345 (not rounded)

In tax per product when the discount is calculated (may be a calc like that) by sales_price(not rounded) - base_price_ with_tax = 0,00345 to find the difference or if sales_price(not rounded) != base_price_with_tax(rounded) then discount=0,00345
so discount_price = ...= 0,00345 or rounded discount price equals to discount_price(round(-1) = 0.00 + currency

So the discount is been rounded after the calculation from createPriceDiv in the front templates and is how 0.00currency appears because is it not empty.

I think that is not a "bug" 100% because was many users ask that from dev team to change the way the taxes is been calculated per product (no to be rounded). What is need to get fixes, imho, is prices to be calculted for tax per product as float numbers and after rounded from creatediv.

Regards

[AH]

Bytelord

Of course! I forgot that a discount can be applied by a rule as well!

When I set the product to be Vat per product, the discount is no longer shown no doubt due to rounding.

Although the "fix" in the template pages sorts out the display, I think that this should be sorted in the delivery of data to the template page.

I still go with my first thought, that this should be handled more effectively by the code, rather than having to hack a template.  However, for those needing to get the job done, template route is the best we have for now.

Many thanks for the fast and detailed reply!

[bytelord]

Hello,

I am not also 100% that this is the problem, didn't find the time yet to check it but i believe that the reason, rounding. As you have already see the templates has been updated and the show prices areas now are checking using if (round($product->prices['basePriceWithTax'],VmConfig::get('salesPriceRounding')) != $product->prices['salesPrice']) {
but not for all prices for base price only... so the other prices doesn't updated and doesn't work as expected with tax per product (return nonempty values, cause are float numbers during rounding and no empty or 0). I want first to clarify why this has been changed and then provide any suggestions to dev team to correct that if they haven't already fix it... but you have right, the "output" should work the same for all calculation rules.

Regards