[Done v2.0]Currency Rounding Issues with quantity discounts

[redwax]

You used 1.14999998 as the rate value. Strictly speaking as the current VAT rate is 15%, that should be 1.15,

I know, I can't remember where I invented 1.14999998 from

I don't want to harp on about VAT (as this is really a subject for an accountant) , as opposed to the bug itself, but do you realise that if you do become VAT registered, and therefore liable to pay the VAT on your ouptuts you will in fact be making less profit per item. ?

Not so! Well, marginally, but obviously I paid VAT on the goods purchased which I would be able to offset if I was registered and charging VAT, so yes, there would be a small deduction in profit directly but ultimately I would only be interested in the net price of goods I bought rather than the gross value.

[wilt]

Just another question.

What is the original value of the product, and what settings do you have for the quantity discount for that product.

[redwax]

Original value is 2.60 and I have qty discount set for actual price of 2.17 for min qty of 4. The admin interface also shows calculated price of £2.50 = 4x £9.98

[wilt]

and just to double check,

What is your Zen Cart version.

[wilt]

not that it matters, as I can duplicate the problem in a stock 138 install.


Bear with me while I try and find the prob.

[redwax]

For the record, it's 1.3.8a.

Thanks a million for your help Wilt

[redwax]

not that it matters, as I can duplicate the problem in a stock 138 install.


Bear with me while I try and find the prob.

Did you manage to figure out what was going on here Wilt? I have had a good play but am truly stumped.

[redwax]

I've looked a little deeper....

Zen cart calculates the base price * quantity before applying the currency rate and rounding.

It appears that there are three functions primarily involved with this:

function display_price();
function format();
function show_total();

Getting the correct per item calculation is easy enough by modifying:

  function display_price($products_price, $products_tax, $quantity = 1) {
    return $this->format(zen_add_tax($products_price, $products_tax) * $quantity);
  }
}

to:

  function display_price($products_price, $products_tax, $quantity = 1) {
    if (empty($currency_type)) $currency_type = $_SESSION['currency'];

    
      $rate = (zen_not_null($currency_value)) ? $currency_value : $this->currencies[$currency_type]['value'];
      $products_price = zen_round($products_price * $rate, $this->currencies[$currency_type]['decimal_places']);
      $products_price = $products_price * $quantity;
      $format_string = $this->currencies[$currency_type]['symbol_left'] . number_format($products_price, $this->currencies[$currency_type]['decimal_places'], $this->currencies[$currency_type]['decimal_point'], $this->currencies[$currency_type]['thousands_point']) . $this->currencies[$currency_type]['symbol_right'];
  
    if ((DOWN_FOR_MAINTENANCE=='true' and DOWN_FOR_MAINTENANCE_PRICES_OFF=='true') and (!strstr(EXCLUDE_ADMIN_IP_FOR_MAINTENANCE, $_SERVER['REMOTE_ADDR']))) {
      $format_string= '';
    }
    return $format_string;
  }
}

This uses parts of the format() function hard coded into display_price() rather than calling it. Not too much of a drama (although I don't know what else this might brake), except the cart totals uses a huge function - show_total() which does the quantity calculations before function format() which applies the currency and rounding calculation.

All this requires a fair bit of time to put right - it has taken me an afternoon writing the above alternate function and realising the issue with the other function.

This would appear to be a fundamental floor in how zen cart calculates pricing. I am sure there was a clear design objective that steered the development down this path but I can't think what it might have been.

[wilt]

Hi,

While your fix will certainly correct cart totals, it breaks when you go to checkout.

The problem here is that the order totals use a slightly different method for calculating their values.

Unfortunately this is not easy to fix (although I am quite willing to be proved wrong)

V1.3.x code does uses a very poor model for the calculation & storage of line item data. unfortunately we are stuck with this from the original osC code.

There may be a workaround in that I believe restricting the currency conversion rate to say 2 decimal places might bypass the discrepancy (although I have not tested that)

If anyone has any better solution I'd be really grateful to see it.

[redwax]

While your fix will certainly correct cart totals, it breaks when you go to checkout.

Yeah, I know, it doesn't even show the correct sub-total amount. Basically, fixing this problem would require a rewrite of the following functions:

display_price();
format(); (this is used quite extensively from what I can see)
show_total();

Which, it itself isn't too much of a drama but who knows what else will break and owing to the life-cycle of the 1.3x series I'm not sure it is time worth spending.

Is this something that has been addressed in the ever delayed v2 do you know?