Rounded prices - how?

[lausianne]

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?

[Milbo]

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

Code: [Select]

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;
}


[lausianne]

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.

[AH]

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.

[lausianne]

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"

[Milbo]

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.

[lausianne]

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.

[AH]

Tax, 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.)

[lausianne]

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.

[lausianne]

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.

[AH]

show the product and the price that is being used

[lausianne]

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)

[AH]

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

[lausianne]

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.

[AH]

"So I'm somewhat relieved it's not just me ..."

Unfortunately, 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