Post by ocWineMaker » Fri Oct 21, 2022 4:37 am

I am new to OpenCart. I had to find an alternative solution for an existing online shop and OpenCart seemed to be a valid option. Everything went very smooth... until the shop was prepared, the first products had been added and some sample shopping carts had been filled. Very soon I was hit by the "rounding issue" in OpenCart when adding quantities of hundreds or thousands of a product. For me, it's ab it surprising that this seems to have been around for quite a while...

The shop I am dealing with had a product which is sold at EUR 5,80 (gross). German VAT on wine is 19%. Therefore, the exact net price would be EUR 4,87394958. By default, OpenCart only allows to specify the product net price with a precision of 4 decimals which would be EUR 4,8739 in this case. It's quite obvious that this will lead to issues if customers put large quantities (e.g. 100 or 1000 items of this product) into their shopping cart. Neither the subtotal nor the tax nor the total would be correctly calculated.

Hence, I did some research in the OpenCart code (based on version 3.0.3.8 that I use). To my understanding, the actual problem has more than one root cause, I think:
  • The field "price" in table "oc_product" has too few decimal places (set to "decimal(15,4)").
  • The controller (catalog/controller/checkout/cart.php) reduces the precision of the value for "unit_price" by rounding it to two decimal places and then setting "price" based on $this-currency->format($unit_price, ...) and "total" using $this->currency->format($unit_price * product['quantity']), ...) which produce incorrect results as the precision of "unit_price" has already been reduced by rounding it before.
To the best of my understanding, the only proper fix for this issue is:
  • Increase the precision of the "price" field in table "oc_product" to at least "decimal(15,8)".
  • Avoid reducing precision of "unit_price", "price" and "total" in catalog/controller/checkout/cart.php. Instead keep the values with their default precision and store additional array fields (e.g. "$data['products']['formattedPrice']", "$data['products']['formattedTotal']", "$data['formattedTotals']['title']" and "$data['formattedTotals']['text']") to pass properly rounded and formatted values to the template (catalog/view/theme/default/template/checkout/cart.twig).
If my findings are correct, I would appreciate if the required changes could be integrated in OpenCart instead of requiring separate extensions that fix the symptoms but not the root cause.
Last edited by ocWineMaker on Fri Oct 21, 2022 3:17 pm, edited 1 time in total.

Newbie

Posts

Joined
Wed Aug 31, 2022 5:17 pm

Post by OSWorX » Fri Oct 21, 2022 4:34 pm

Already discussed in several other threads, for example: viewtopic.php?t=229626

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Guru Member

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by ADD Creative » Fri Oct 21, 2022 7:20 pm

ocWineMaker wrote:
Fri Oct 21, 2022 4:37 am
  • The controller (catalog/controller/checkout/cart.php) reduces the precision of the value for "unit_price" by rounding it to two decimal places and then setting "price" based on $this-currency->format($unit_price, ...) and "total" using $this->currency->format($unit_price * product['quantity']), ...) which produce incorrect results as the precision of "unit_price" has already been reduced by rounding it before.
You have that part incorrect. The precision of "unit_price" is not reduced before total is calculated, it's just the tax being added.

If my findings are correct, I would appreciate if the required changes could be integrated in OpenCart instead of requiring separate extensions that fix the symptoms but not the root cause.
Even if you corrected as suggested you would still have rounding issues with the totals due to the way they are displayed and calculated, especially when multiple currencies are used.

Theses issues have been mentioned many times over the years and sadly the developer has always rejected the idea of making changes. I think mainly because the issue is not as easy to fix for all cases as you might think it is.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom
Who is online

Users browsing this forum: No registered users and 1 guest