This has been discussed many times and I spent hours googling and trying all "solutions" I found, but got nowhere. So I hope someone here has a real solution to this seemingly basic problem:
I need all prices to appear rounded to a full number. No matter what currency or discounts. Always round.
Thank you!
Oh, I got it, finally, and it was not so hard:
Configuration > Configuration > Currencies > [your currency]
Set decimals to 0
Add .00 to formats
Still a problem with rounding, though:
Displayed:
Base price: 18.10
Total for 2 units: 36.10
But ... 18.10 x 2 = 36.20
There is no mathematical error, it just looks wrong, because the actual unit price is 18.05, rounded up in display.
The base price should therefore be displayed rounded to .05 instead of .1 - How?
Check under configuration-> prices, there You have settings for rounding of display or not.
regards
Jörgen @ Kreativ Fotografi
Hello Jörgen,
Thanks for coming in and trying to help. Yes, this is one of the many settings I changed back and forth. I wish it was that simple, but once I tried this setting, it made things worse. Now I tried again, and see no difference.
Another example:
Base price:€16.20
2 units => Total without tax: €32.30
If I display all decimals, I see that the calculations are correct. But I cannot show those numbers on the product page.
What I also found is that it is all good with the default currency, $. But switching to any other currency, I get these rounding issues.
Any idea? Thank you!
Regards,
Ralf
EDIT: What I think should happen, is that the total price is simply the base price as displayed multiplied by the number of units.
It would be slightly less correct, mathematically, if all discounts and exchange rates are taken into account, but who cares - as log as what is displayed makes sense.
Hello, i agree that the displayed values are the ones that should add up. It should work the same with all currencies, maybe the setting for the decimals for the currency under currencies could control this.
Regards
Jörgen @ Kreativ Fotografi
I wish it could. But it doesn't. Maybe something in the currency conversion needs to be changed. I saw Max Milbers name in there, maybe he would know.
It seems unlikely that I am the first one having this issue. But I wouldn't know what could be special about my shop.
Definitely a bug, in my opinion:
Clean new install of Joomla 3.8.6, VM 3.2.12.9708
I deactivated all rules (tax, discount) and rounded to 1 decimal.
Screenshot: https://cl.ly/qV2e
... 12.50 x 10 = 124.50
"Round only display" on/off makes no difference.
Quote from: lausianne on March 27, 2018, 15:28:44 PM
The base price should therefore be displayed rounded to .05 instead of .1 - How?
For that we have the "Rappenrundung" mode. Do all your changes in the vm config first. You can later adjust them per currency.
Quote from: lausianne on March 27, 2018, 19:40:10 PM
Another example:
Base price:€16.20
2 units => Total without tax: €32.30
If I display all decimals, I see that the calculations are correct. But I cannot show those numbers on the product page.
Why you cannot show it on the product page?
Quote from: lausianne on March 27, 2018, 19:40:10 PM
What I also found is that it is all good with the default currency, $. But switching to any other currency, I get these rounding issues.
Any idea? Thank you!
As just written to your other comment. You have in VM most time a common and a specific setting. So go first to the vm config and change the options there.
Quote from: lausianne on March 28, 2018, 19:39:38 PM
Definitely a bug, in my opinion:
Clean new install of Joomla 3.8.6, VM 3.2.12.9708
I deactivated all rules (tax, discount) and rounded to 1 decimal.
Screenshot: https://cl.ly/qV2e
... 12.50 x 10 = 124.50
looks like rounded to 2 decimals. And I have no clue about your other settings, which you are maybe not aware of.
Quote from: lausianne on March 28, 2018, 19:39:38 PM
"Round only display" on/off makes no difference.
It should solve your first case. Just think about the screw example. You buy 1000 screws for 1 cent each, plus vat. One screw would have in germany 0.19 cent vat => 0.0 Vat. But not 1000 screws. For this we have the "round only display", should be disabled for your case.
You need Rappenrounding activated and "round only display" disabled.
Hello Milbo,
Thanks for your comments.
>> ... 12.50 x 10 = 124.50
> looks like rounded to 2 decimals. And I have no clue about your other settings, which you are maybe not aware of.
This: >>"Clean new install of Joomla 3.8.6, VM 3.2.12.9708 / I deactivated all rules (tax, discount) and rounded to 1 decimal."
This is literally all I have done and set (as far as I remember, using default demo data). Single currency. I have (on my shop under development) tried all settings I could think of and that I have found mentioned in the forum and documentation, the results are always the same. "Rappenrundung", "Round on display" ... no difference. VAT is not relevant for the problem.
>> What I also found is that it is all good with the default currency
I was wrong about that. I only did not see the issue, because the prices in the default currency are already rounded to 1 decimal, so additional rounding makes no difference - unless you add discounts and/or VAT.
> Why you cannot show it on the product page?
Because it is wrong. 12.50 x 10 = 125.00, not 124.50. Customers don't care about the mathematics behind these numbers, they will just be confused. Most won't notice or won't care. But my client noticed and cares.
I have looked through the source code, but couldn't figure it out myself, unfortunately. I don't see why the total price cannot be calculated by rounded base price times number of units rather than however it is done currently.
If only the base price is affected by any modifications and rounded afterwards, the total will then always be correct automatically. Whatever is set in the backend, numbers should always add up in the frontend, IMHO.
Rounding to 1 decimal and showing 2 for display gives this side effect. Seems not to be rounded for the total sum.
Regards
Jörgen @ Kreativ Fotografi
Thanks, Jörgen. What would I have to set how, to get it right?
I went back to the clean test shop. And now I discovered something completely new to me, my bad: I found that rounding digits can be set for each individual kind of price! (seen it a hundred times, never noticed) Wonderful. So I set everything to one digit (was -1 before).
Yet, for the result it again makes no difference: https://cl.ly/qeqB
Interestingly, the price is correct for "Product prices result", only for "Total" it's wrong. (I found this was a coincidence. With other prices this is also wrong.)
Unfortunately, in the official demo, the Configuration is not accessible and currency details cannot be changed. But I'd happily give access to my test site to anyone who wants to try.
Or if you have your own shop: set the price of a product to 12.45 and rounding to 1 decimal. Then buy 10 of them.
EDIT:
Just found this shop: https://demo.joomlapro.com/vmuikit-yootheme-horizon/
Switch currency to $, then buy 10 of any watch, go to cart. Wrong totals.
I got into a brief exchange with an extension developer. Eventually he wrote this:
"I've tried it locally out of curiosity and it really seems to be a bug in VM to me. In my cart in VM, the total price is correct if I disable the "Round only display" option in VM, but the subtotal in each line is still incorrect.
Unfortunately, you'll probably need to wait for VM devs to fix it."
So I'm somewhat relieved it's not just me ...
Since this is apparently really is a bug, would a moderator mind moving this thread to
Virtuemart Development and bug reports / http://forum.virtuemart.net/index.php?board=127.0
... please?
Together with Maik we found maybe a bug, go to the currencydisplay helper /administrator/components/com_virtuemart/helpers.
Replace the function roundForDisplay with this code
public function roundForDisplay($price, $currencyId=0,$quantity = 1.0,$inToShopCurrency = false,$nb= -1){
if(empty($currencyId)) $currencyId = $this->getCurrencyForDisplay($currencyId);
if($nb==-1){
$nb = $this->_nbDecimal;
}
$price = $this->convertCurrencyTo($currencyId,$price,$inToShopCurrency);
if($this->_numeric_code===756 and VmConfig::get('rappenrundung',FALSE)=="1"){
$price = (float)$price * (float)$quantity;
$price = round((float)$price * 2,1) * 0.5;
} else {
$price = round((float)$price,$nb);
$price = (float)$price * (float)$quantity;
}
return $price;
}
Thank you very much, Milbo. I was getting almost desparate with this issue. Your change actually fixes it for the cart, all seems correct there now. On the product page though, I still get the old faulty results.
This IMHO was not a bug
Round only for display was working as defined and gave result of line item consistent with cart totals
If I use the changed version of currency display and add multiple quantities of an item to the cart then the Line total is different from the cart total for configurations where VAT tax is utilised
Not something any shop owner or customer would expect to see (yes it may be confusing for shoppers where multiples of a line item are purchased)
However when purchasing multiple quantities of a single item, rounding the item before multiplying the qty results in misleading information in the cart
example
Net price is 2.22
inclusive of vat = 2.22 x 1.20 = 2. 664
With rounding to 2dp for display = 2.66
Purchasing a single item gives line totals and cart totals which are in line
However purchasing a quantity of 12 gives confusing figures
The code that rounds a single item first results in:-
Line total of 31.92 and Vat of 5.28 calc is 2.22 x 1.20 (rounded) = 2.66 x 12
Cart Total of 31.97 and Vat of 5.33 calc is 2.22 x 12 x 1.20 = 31.968 (rounded)
The Cart total is what will be billed
The proposed change shows line item total different to actual billing amount.
Thank you for your elaborate reply, AH. Although I did not try to recalculate your examples, I assume that it is all correct, and that you are probably right in theory.
The problem is, though, that what clients see, is obviously (to them) wrong. They (and the law, actually) does not care, whatever calculations are taking place in the background. What is displayed is valid. So if the base price is displayed as $3.80 (after rounding and currency conversions etc.), then that is the actual valid price, and this should be used for all further calculations.
Then, if a client puts 5 of these into the cart, the result for the total must be $19, on the product page as well as in the cart and in the invoice. What to tell a client who sees $19.10 instead? "It may look a bit off, but it's really ok ... don't worry"
Quote from: Milbo on April 04, 2018, 10:56:24 AM
It should solve your first case. Just think about the screw example. You buy 1000 screws for 1 cent each, plus vat. One screw would have in germany 0.19 cent vat => 0.0 Vat. But not 1000 screws. For this we have the "round only display", should be disabled for your case.
Thanks for coming back in, Milbo. Unfortunately I don't really see how this example is relevant. Tax, at least in my case, is only added in the cart, to it will be added to the total sum of everything. The problem is that the total sum is already wrong, at least on the product page. In the cart, after your fix, it is now correct.
Regarding screws, though: If I displayed prices incl. VAT, and the price, incl. VAT was displayed as 1ct, then I cannot charge more than €10 for 1000 screws. Even if I then lose €1.90. If I care about 0.19ct per screw, then I cannot round the display in the first place, I have to display those 0.19ct, or display prices excl. VAT, or sell in packs of at least 10.
QuoteTax, at least in my case, is only added in the cart
And in my case the existing code works as required and expected.
Tax has to be shown at a product level and the totals have to be correct for the line item and the cart total
The proposed change "at least in my case" makes things wrong (as shown above.)
If sold B2B, at least in Switzerland, there is no need to show VAT at product level. Anyway, the rate is only known after the client entered his address.
If the change would actually made things wrong for you (and then probably also for others), then it should be optional. In my case it is clearly and obviously wrong the way it is now. And I have seen other VM stores with the same issue.
Just this: 18.00 x 2 = 36.10 - see attachment. No tax, no discount. I still, after all our discussions, cannot see how this can not be regarded as a bug. Or how to explain to my client that this is fine and by design, and cannot be different ... There must be a misunderstanding somewhere.
show the product and the price that is being used
Thanks for staying in, AH. Please find screenshots attached. One shows the price settings in the backend, the other shows the same product in the cart, where all prices are correct, after applying Milbo's fix.
In this shop, tax only applies for customers within the country. Sales to foreigners is without tax.
"Round only display" is off. When I switch it on, there may be slight differences, but the problem remains.
A detail: contrary to what I wrote earlier, there is actually a discount when buying certain numbers of products. But removing that discount makes no difference regarding the problem.
The problem is the same on the original demo shop. I added a screenshot of that, too. (It's the Safety Helmet)
Change that base price to 18.98
I did some testing and setting 3 dp base price will give you rounding variances regardless of what you have set as DP
I can change the price to anything, as soon as discount or currency switch come in, the issue is back. It should not matter how many digits the base price has in the backend. All that counts for the client are the prices that he sees in the frontend.
"So I'm somewhat relieved it's not just me ..."
QuoteUnfortunately, you'll probably need to wait for VM devs to fix it.
I don't believe that VM devs are considering trying to convert VM to work backwards from a line item retail price inclusive of VAT
There has been a small change to the currency display functionality " roundForDisplay" in the latest version
VM works from a cost price -> forwards
Not from a Retail Price inclusive of VAT -> backwards
Possibly you should consider not setting cost prices to be more than 2dp if you round to 2dp
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.
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"
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?
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.
Luisanne
I am working on 3.2.15
Wait until that is released - then try that.
Thank you!
For the time being, I applied a quick & dirty workaround, added to .\components\com_virtuemart\views\productdetails\tmpl\default.php:
<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>
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!
Lausianne
Quoteorder 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
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.
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 ...