Rounded prices - how?

[lausianne]

Prices are not inclusive of VAT in this shop, there simply is no VAT (can be, if customer in CH, but is not related to this issue anyway). I don't expect anyone to work backwards from anywhere. On the contrary, I'd hope calculations worked forward from base prices.

And, as I said, it does not matter at all what cost prices are set to. They could be rounded to a hundred dollars - after currency conversion they'd still have lots of digits. And then produce wrong prices in the frontend.

And if you check the original VM demo shop - without changing any of the default settings, the error is right there.

[AH]

Ok - I am still hanging in here

Just tested the latest version

NO tax
I went with a price of 18.97749
"Round only display" switched off
Currency is 2dp

When I add 10 to cart - it calculates to 2 dp based on the single item rounded first.

The last image is where I switch on "Round only display"

[lausianne]

Sorry, very busy last few days. All right, so there is one example where the rounding leads to a correct result. But should these results not ALWAYS be correct, not just randomly?
Even if it says in the config that it "Round only display off" mathematically give more accurate results, to which I totally agree - in the backend. But customer sees what customer sees. He sees no backend. And if he sees 18.00 x 2 = 36.10 and has doubts about the mathematical correctness, what can I say? My mathematics are correcter than yours?

[lausianne]

Demo shop, your example price, no tax, no rounding.

EDIT: In the demo shop I cannot see or set rounding on display. But in the shop I'm working on (VM 3.2.14) it makes no real difference.

[AH]

Luisanne

I am working on 3.2.15

Wait until that is released - then try that.

[lausianne]

Thank you!

For the time being, I applied a quick & dirty workaround, added to .\components\com_virtuemart\views\productdetails\tmpl\default.php:

Code Select Expand

<script type="application/javascript">
correctTotal = function() {
jQuery('.spacer-buy-area span.PricepriceWithoutTaxTt').off( "DOMNodeInserted", correctTotal);
quantity = jQuery("input.quantity-input").val();
basePriceStr = jQuery(".spacer-buy-area span.PricebasePriceVariant").text();
basePriceParts = basePriceStr.split(' ');
basePrice = parseFloat(basePriceParts[0]);
totalPrice = (basePrice*quantity).toFixed(2);
currencyStr  = basePriceParts[1];
jQuery(".spacer-buy-area span.PricepriceWithoutTaxTt").html(totalPrice  +" "+currencyStr);
console.log("Total price fixed");
jQuery('.spacer-buy-area span.PricepriceWithoutTaxTt').on("DOMNodeInserted", correctTotal);
};
jQuery('.spacer-buy-area span.PricepriceWithoutTaxTt').on("DOMNodeInserted", correctTotal);
</script>

[lausianne]

Checking in again, client breathing down my neck ...

In http://dev.virtuemart.net/projects/virtuemart/repository/changes/trunk/virtuemart/ I found this, and assume it is related?
- calculationH reverted calculation of the priceWithoutTax to the old method (wrong, but the same as we had last years)
- order item editing, replaced product_item_price against product_discountedPriceWithoutTax for calculation of the subtotal

If I can do something to help, like testing code changes, please let me know.
I'm glad I found the trunk (didn't know about it before), I see there is a lot of good work being done on Virtuemart. Thank you!

[AH]

Lausianne

order item editing, replaced product_item_price against product_discountedPriceWithoutTax for calculation of the subtotal

This is unrelated to display - It relates to order editing in admin and order table details

[lausianne]

Meanwhile I worked on this myself and overwrote much of the original price calculations. Now base prices are converted only once to get the base prices in all used currencies and all subsequent calculations are based on those converted base prices. No further conversions and no rounding errors caused by those conversions.
Disadvantage, and why I'm not making this public, is that it's a q&d hack, many features (discounts etc.) are not supported, currencies are hard coded, core hacks -> no more updates.

[lausianne]

A year later ... I just installed Version 3.6.0. In the release notes I read that there have been improvements regarding price calculations. Unfortunately, for me it is still not working correctly: https://cl.ly/d8519eff5f0c
As soon as there's a currency calculation, the displayed prices are wrong.
Including all of the digits, I know, it would be correct. But that is only a virtual correctness, not a visible one.
WYSIWYG - in every shop I've ever seen on the internets. Except VM ...