Post by daik01 » Mon Mar 25, 2013 2:13 am

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.....

TOP 5 Opencart Extensions:
1:Opencart Reservations
2:Stock Report, import/export stock levels with Excel
3:3D Carousel
4:Product Price Changer by Category
5:Set price Inclusive Taxes
DEMO SHOP


Active Member

Posts

Joined
Sun Oct 21, 2012 3:18 am


Post by butte » Mon Mar 25, 2013 3:42 am

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.

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by rph » Mon Mar 25, 2013 8:03 am

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.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by butte » Mon Mar 25, 2013 8:56 am

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

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by daik01 » Mon Mar 25, 2013 4:02 pm

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)

TOP 5 Opencart Extensions:
1:Opencart Reservations
2:Stock Report, import/export stock levels with Excel
3:3D Carousel
4:Product Price Changer by Category
5:Set price Inclusive Taxes
DEMO SHOP


Active Member

Posts

Joined
Sun Oct 21, 2012 3:18 am


Post by dydyt » Mon Jun 03, 2013 10:26 pm

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!

Newbie

Posts

Joined
Wed Oct 17, 2012 3:28 am

Post by fabrizio » Tue Jun 04, 2013 2:24 am

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.

Newbie

Posts

Joined
Thu Apr 04, 2013 1:06 am

Post by shanni73 » Wed Jun 05, 2013 11:14 pm

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

http://australianwebsitesolutions.com.au Australian Website Hosting for Opencart Shopping sites- Serious Hosting for Serious Aussie Shopping Sites!


New member

Posts

Joined
Mon Sep 27, 2010 7:26 pm
Location - Central Coast NSW

Post by mothercruncher » Thu Dec 19, 2013 5:50 am

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 :(

User avatar
New member

Posts

Joined
Mon Jan 31, 2011 9:10 pm

Post by butte » Thu Dec 19, 2013 6:27 am

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.

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by cha0s » Fri Mar 24, 2023 11:47 pm

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

Newbie

Posts

Joined
Tue Aug 27, 2013 9:07 pm

Post by ADD Creative » Sat Mar 25, 2023 1:33 am

cha0s wrote:
Fri Mar 24, 2023 11:47 pm
Hi, topic made in 2012, already 2023 O0 , 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.

www.add-creative.co.uk


Expert Member

Posts

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

Post by cha0s » 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?

Newbie

Posts

Joined
Tue Aug 27, 2013 9:07 pm

Post by ADD Creative » Sat Mar 25, 2023 9:31 pm

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.

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 34 guests