Wrong Total Price to everyone who using Opencart

rph wrote:

daik01 wrote:

I don't believe this should ever even be an issue as the database isn't used as an intermediary when making calculations.

Look at http://www.webfryslan.nl/parallax
Created 8 decimale, and there is no problem until you buy more the 1.000.000 products

How? That doesn't make sense programatically because OpenCart isn't getting tax-included prices from the database, it's calculating them on the fly.

It's very simple. You save the product price with more decimals. So your calculations are precizer. I think that the 1 cent difference for 1.000.000 producty should not be a problem for most Opencart users. If so, change your product and sell them per 1000.....

I suppose that what I'm not understanding is why you don't just disable tax calculations and pass the vat-embedded unit prices' quantity extensions.

Where (as here) we have a percentage sales and use tax complicated by jurisdictional variations statewide, sometimes one wins or loses half a cent by buying more than one of something or among items and quantities' total tax. Apparently vats are fixed and embedded in the price, and I assume that vats are preset to avoid pennies (or other hundredths). If OC is not prompted to "reverse engineer" and then to reinstate vats, there should accordingly be no problem. Otherwise, I would be surprised that close scrutiny would not show the same problem arising in at least some department, grocery, and other sorts of mass retail purchase stores, and perhaps asking some of their own inner sanctum people how they avoid or deal with the arithmetic problem as well as the government (even California takes half-cent rounding as a fact of life, but from what you've said apparently halfpennies are of uniquely European or nowadays of Union concern). Otherwise . . .

Try a simple, short notice (comment) to this effect (in lingo for your customers):

The shop calculates from unit prices (with vats) and ordered quantities the subtotal extensions whose total, possibly embodying fractional hundredths (of a Euro or other currency) of apparent discrepancy when uncalculating embedded vats and recalculating them, then passes along with fixed or variable shipping (if any) to the payment portal, and the payment portal (depending upon which transaction processor) effectively either takes that as-is or redoes the arithmetic (without fiddling with vats) and provides "the" definitive final result.

daik01 wrote:It's very simple. You save the product price with more decimals.

If you're talking about product price with tax, that's never stored. It's calculated on the fly. It's done so if an owner changes product prices it goes live instantly. I'm not aware of any currencies that use 4 places, let alone 8. The most I could find are 3 places with the dinar. Everyone else uses 2 or 0.

Sellers, however, go to three in the usual instances of American fuel sellers, with the long since traditional (as well as annoying and insulting) ploy of subtracting a mil ($0.001) from prices, and sometimes of various wholesale and retail quantity discounts. Then any discrepancies, losses, or gains are cumulatively rounded into traditional pennies at paytime, at a cash register or a credit cardslot. Probably fortunately we still haven't seen anyone sell gasoline or gas on-line with OC (if yes, I don't even want to know about it).

rph wrote:

daik01 wrote:It's very simple. You save the product price with more decimals.

If you're talking about product price with tax, that's never stored. It's calculated on the fly. It's done so if an owner changes product prices it goes live instantly. I'm not aware of any currencies that use 4 places, let alone 8. The most I could find are 3 places with the dinar. Everyone else uses 2 or 0.

Yes, that is what you showing at the front end of your store. Because Opencart has to calculate taxes, you have to store the product price in the database exclusive taxes. If you do that with more precission (8 instead of 4 decimals) you will have less rounding problems at the end. (Rounding takes places at the end)

This a little bit help me:

1. EDIT: system/library/currency.php

2. FIND:

Code: Select all
round($value, (int)$decimal_place)

3. REPLACE WITH:
Code: Select all
round($value, 1)

I hope, that you will fix this bug in the next OC version, because in prestashop works perfectly!

Hi dydyt,
thank you for the tip!!.
I tried it on my OC ( 1.5.4) and it doesn't work.
It rounds all the prices on the front end but when i buy for example 100 items at 17.10 € each in my cart i have:
100 x 17.10 = 1711,55€

I'm surprised that Prestashop has the same issue....i don't understand how people handle this issue in their shops; i see many shops with wrong math in the cart and then in the invoice too, what do you say to the customers?.
Do you confirm that with this modification Prestashop works well?...i mean if i put an order of 100 items the math is correct in the cart? I like very much OpenCart but i have to find an alternative to this problem.

Hello

I am having the same problem - BIG TIME!!

Why is open cart calculating wrong prices. For instance I have a cart order that I created that totals $152.90 ex tax. + Tax = $15.30 The total in the cart says = $168.10 This does not add up!!!

$152.90 + $15.30 = $168.20 NOT $168.10 - It is out $0.10

HOW??

Does anyone know why or how to fix this??

The other thing is, is that majority of the totals are out by 1 cent. Most of the time, and this is not even good. I have no idea.

Any ideas?

Thanks

I'm running into this, what, bug? feature? and it is triggering PayPal IPN errors that mean my sales are not always passed back to the store to receive their "complete" statuses.

It is driving me nuts

In some instances, in Europe and for some reason less often in Australia, an apparent rounding (too far beyond pennies to matter) and VAT have given a penny difference when two farthings or a halfpenny will throw the difference up or down. That has been taken on in several threads this year alone. A penny discrepancy is easy to explain as how software happens to round, even banks and accountants understand the 0.5 cutoff rule taught them by elders. A dime discrepancy is not acceptable whether software or a thug did it.

The /system/logs/ will record PayPal details. That makes the logs important to protect (.htaccess should already do that) and to prune (rename, pull down via ftp, delete -- they will be restarted). The logs also allow seeing the transactions, for which changes that are not getting through can be at least manually done.

Droll, that as a feature. It may be a bug in the module, or it may relate to the PayPal changes over to using http1.1, dunno, yet.

Hi, topic made in 2012, already 2023 , Is there any solution to this what the author wrote here? maybe possible buy some module to fix it. Thanks

cha0s wrote: ↑

Fri Mar 24, 2023 11:47 pm

Hi, topic made in 2012, already 2023 , Is there any solution to this what the author wrote here? maybe possible buy some module to fix it. Thanks

There is not full solution, but there are ways to work around it depending on your store configuration and what you want the end result to be.

the task is to have prices on the site with only two decimal places, for example product price without TAX = 1.88, we added tax class with 21%, then on front price 2.27 (but in fact 2.2748), and everything counts as 2.2748, but customer sees price 2.27!

p.s: 0.0048 - this should not be, such money does not exist

Is it possible to make all prices have only two decimal places? (all places), and without round,
if product 1.88 then after 21% = 2.27, (not 2.2748)
if product 1.9 after 21% = 2.29 (not 2.30)

can this be solved with a little bloodshed? or does it need to shovel the entire opencart and each controller and model, where there are calculations?

cha0s wrote: ↑

Sat Mar 25, 2023 7:51 pm

the task is to have prices on the site with only two decimal places, for example product price without TAX = 1.88, we added tax class with 21%, then on front price 2.27 (but in fact 2.2748), and everything counts as 2.2748, but customer sees price 2.27!

p.s: 0.0048 - this should not be, such money does not exist

Is it possible to make all prices have only two decimal places? (all places), and without round,
if product 1.88 then after 21% = 2.27, (not 2.2748)
if product 1.9 after 21% = 2.29 (not 2.30)

can this be solved with a little bloodshed? or does it need to shovel the entire opencart and each controller and model, where there are calculations?

A workaround would be to enter the ex. tax price as 1.8760. This will give an including tax price of 2.26996 which will round to 2.27. It's closer so the customer would have to add 1000s before it was noticed.

Another workaround is to add rounding in selected places where calculations are done in the prices. I believe there are extensions in the marketplace that do this, but I don't know how well they work.