[Solved] Tax Calculations don't add up with combinations

[Labs]

On the info page of a product we have the following:
Pre-tax wholesale price: $20
Pre-tax retail price: $100
Tax: GST (10%)
Which automatically puts the correct amount in the next section
Retail price with tax: $110

However when I create a combination and put an additional cost of $60 in this section:
Impact on price: "Increase" of $60

The price of $170 shows up in my shops page.

By adding an Increase to the price, my GST calculation should then be calculated based on the Pre-tax retail price of $100 and the Increased price of $60 therefore $160 plus $16 (10%) so my end price should be $176.

Shouldn't it?



Thanks
Labs

[rocky]

The price increase you enter must include the GST, so you must enter $76 as the price increase. That is the way Prestashop works. I know this is a bad way of doing things, since if the tax rate changed, you would have to manually recalculate the tax of all your price increases. I hope the Prestashop team will fix this in a future version.

[first1]

Good Point rocky... could you report that to them so it can be changed?

[Labs]

Thanks Rocky,

Yes that was the path we ended up thinking we have to go down but I actually figured it out to be $66 as the price increase, I've left the 10% GST in the info section so that the customer page does show the tax included notice.

[rocky]

Hi first1,

This issue has been previously reported here. The Prestashop team wrote that this is the way it is designed to work and "fixed" it by adding "* tax included" to the bottom of the Product Combinations Generator.

I'll add this as a feature request and hopefully the Prestashop team will make the change for Prestashop v1.3.

Rocky

[first1]

Great, thanks.

[dezignated]

I am still new to prestashop but so far I like it. I have not tested this but for now I changed line 1265 in classes/product.php
***************************************************
from:

$attribute_price = $usetax ? $result['attribute_price'] : ($result['attribute_price'] / (1 + (($tax ? $tax : $result['rate']) / 100)));

to:

$attribute_price = $usetax ? ($result['attribute_price'] * (1 + (($tax ? $tax : $result['rate']) / 100))) : ($result['attribute_price'] );

***************************************************
I only use the combination prices with out any product prices so I don't know if that is setup the same way. Like I said I have not really tested this but it seems to do it for me until I am more setup for real testing. If anyone has anything to add please let me know.


Thank you,
Rob

[David Niry]

I had the same issue and made the exact same change as dezignated. Seems to work for me too.

[thedanald]

so maybe i am an idiot... but i was having the same problem. On my product page, the red label displaying "tax incl." was adding on 47% tax. For my products, i wanted to display this with no tax at all. I had tried everything, thinking it was somehow related to a tax issue. Upon further investigation (i was just trying to kludge a fix), i found out that on the backend under Payment --> Currencies, there was a 1.47 conversion rate. I deleted that item, and BAM.... the price displayed on the Product page displayed correctly. Hopefully you are as lucky as i am, and this is your problem.

Other than that... the cart pretty much works perfectly for me.

may the course be with you.

dan

[mizzer]

This problem still exists in 1.3dev. The tax excluded/tax included thing is such a hack - the fix in this thread works fine, the original problem is a logic error in the development that has existed for over a year.

The logic statement simply needs to be flipped around. if $usetax is true, then calculate the tax. If it's false, then just use the attribute price. Not a big deal, the cart gets the correct price, everything is fine.

The original call to getPriceStatic() sets the usetax flag as needed (and correctly). $usetax only gets changed (correctly) if PS cannot find the tax rate or is configured to ignore it. Someone misstyped a ternary logic statment though, and $usetax is being used opposite of how it should be.

That such a simple bug has existed for this long is mind boggling. And having to set tax rate into a combination is NEVER ever the correct way to run a business. Why on earth isn't this fixed now?

[ukbaz]

Well looks like they still haven't fixed this in 1.3.2 final a;though the code now is different:

// Attribute price
       $attribute_price = Tools::convertPrice((array_key_exists('attribute_price', $result) ? floatval($result['attribute_price']) : 0), $currency);
       $attribute_price = $usetax ? Tools::ps_round($attribute_price, 2) : ($attribute_price / (1 + (($tax ? $tax : $result['rate']) / 100)));
       $price += $attribute_price;
       $reduc = Tools::convertPrice($result['reduction_price'], $currency);
       if ($only_reduc OR $usereduc)
           $reduc = self::getReductionValue($reduc, $result['reduction_percent'], $result['reduction_from'], $result['reduction_to'], Tools::ps_round($price, 2), $usetax, floatval($result['rate']));

Does the above fix still work in this version?
Thanks
Baz