Post by rph » Fri Mar 15, 2013 8:54 am

Calculus? It's simple multiplication. The floats aren't anywhere near large enough to be an issue.

-Ryan


rph
Expert Member

Posts

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

Post by daik01 » Fri Mar 15, 2013 6:11 pm

SOLUTION

It's a rounding problem, I solved it, look at http://www.webfryslan.nl/parallax

To do this easy, use mine admin tool : http://www.opencart.com/index.php?route ... on_id=9798

This way you can set prices inclusive taxes, add the price inclusive taxes as 236.9900, and you will have the sesired result.

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 gob33 » Fri Mar 15, 2013 7:14 pm

You will always have problems if you use floats in an accounting software.
The result is approximative. This is because of internal representation of floats in computer.
You can use double precision to minimize precision loss, but the best way is not to use floats.
There is also the GNU gmp functions (more complete).

See for reference What Every Computer Scientist Should Know About Floating-Point Arithmetic

All my extensions


Active Member

Posts

Joined
Wed Feb 10, 2010 8:43 am
Location - France

Post by bon_garcon » Fri Mar 15, 2013 11:09 pm

rph wrote:The price isn't wrong. That's how rounding works.
Even though it makes sense how the price is being calculated I think it is "wrong" from customer and accountant perspective.

For arguments sake, you can't be invoicing person for $12,067.50 if they are buying 100 Units for price of $120.68, or can you? It just doesn't add up.

I'm only saying this as I've been hearing few complaints from my customers that numbers in the invoices we send don't add up.

Newbie

Posts

Joined
Thu Mar 14, 2013 6:22 pm

Post by rph » Sat Mar 16, 2013 12:46 am

If the price of a product is 120.675 how much will you be charged if you buy 1? Now how much will you be charged if you buy 100?

-Ryan


rph
Expert Member

Posts

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

Post by rph » Sat Mar 16, 2013 2:11 am

gob33 wrote:You will always have problems if you use floats in an accounting software.
The result is approximative. This is because of internal representation of floats in computer.
You can use double precision to minimize precision loss, but the best way is not to use floats.
There is also the GNU gmp functions (more complete).

See for reference What Every Computer Scientist Should Know About Floating-Point Arithmetic
You can just read the PHP documentation on floating point precision. Maximum error is 1.11e-16. Maximum precision OpenCart will ever work with is 8 places. Tax class is all simple multiplication, division, and addition and the price formatting class does automatic rounding. It should never be an issue.

-Ryan


rph
Expert Member

Posts

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

Post by gob33 » Sat Mar 16, 2013 8:13 am

This is machine internal representation who cares.
When you perform more additions, subtractions, multiplications and divisions on inexact numbers, you'll lose more and more precision and at some time, error show up.
Read this.

All my extensions


Active Member

Posts

Joined
Wed Feb 10, 2010 8:43 am
Location - France

Post by rph » Sat Mar 16, 2013 4:34 pm

Best I can figure you would have to order 900 billion of a product in order to have a chance at a 0.0001 deviation (the highest quantity the order table will hold is 9999).

-Ryan


rph
Expert Member

Posts

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

Post by hypemedia » Mon Mar 18, 2013 7:51 pm

The calculation for the price is a huge problem and a real one I don't understand why are so few people complaining about his.

If you enter prices in the store without vat (this is normal behavior) and after that you start adding taxes and several items in the cart you will see that because of the floating point error and the fact that opencart is using 4 decimals for calculation and the price without VAT you will get a small price deviation of 1 cent maybe sometimes more and this is a problem you can verify on the demo store of opencart.

I don't get it, are accounting rules so loose in your country that a few cents don't matter?

Active Member

Posts

Joined
Fri Aug 17, 2012 5:39 pm

Post by rph » Tue Mar 19, 2013 5:58 am

You're mistaken on how business accounting works.

-Ryan


rph
Expert Member

Posts

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

Post by hypemedia » Fri Mar 22, 2013 5:28 pm

No I am not but you must understand that for some countries 1 cent off the price is a mistake and is an accounting error.

This is an OpenCart related problem we have several stores on Magento and Ubercart and this is the first time where 2 products with VAT that are 39 euro each in total of the order are 77,99 and not 78 because of the floating point error.
Accounting rules appart this is a question of business image. The client dosen't care that the computers do not calculate right. If you buy 2 products that cost 39 euro each the total should always be 78 euro.

Active Member

Posts

Joined
Fri Aug 17, 2012 5:39 pm

Post by daik01 » Sun Mar 24, 2013 3:03 am

Daniel wrote:putting the match back to 4 decimals not 8
I don't understand why you put it back to 4 decimals. If you use 8 decimals, it will end in a rounding problem for every 1.000.000 products instead of 100. I think that is good enough for all opencart users.

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 rph » Sun Mar 24, 2013 6:07 am

hypemedia wrote:No I am not but you must understand that for some countries 1 cent off the price is a mistake and is an accounting error.

This is an OpenCart related problem we have several stores on Magento and Ubercart and this is the first time where 2 products with VAT that are 39 euro each in total of the order are 77,99 and not 78 because of the floating point error.
Accounting rules appart this is a question of business image. The client dosen't care that the computers do not calculate right. If you buy 2 products that cost 39 euro each the total should always be 78 euro.
I'm sure it would come down to local laws or business practices, but I haven't seen businesses that do VAT-inclusive line item invoicing (to my understanding VAT-inclusive is mostly used in places like vending machines where set prices are a must). From an accounting standpoint VAT-exclusive is much more useful as it shows the tax liability without having to go through the extra steps of reverse calculating it product by product in an order.

I'd also add that this isn't an error. It's a side effect of having prices with tax included and displaying that number to a set digit place. When you see a price of €39.00 that's an approximation. That actual price is €38.995. If you buy one unit (which is going to be the display price with tax) your cost would be rounded to €39.00. But if you buy two then it's more accurately $77.99.
daik01 wrote:
Daniel wrote:putting the match back to 4 decimals not 8
I don't understand why you put it back to 4 decimals. If you use 8 decimals, it will end in a rounding problem for every 1.000.000 products instead of 100. I think that is good enough for all opencart users.
I don't believe this should ever even be an issue as the database isn't used as an intermediary when making calculations.

-Ryan


rph
Expert Member

Posts

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

Post by victorj » Sun Mar 24, 2013 6:43 am

This problem is not only related to Opencart.
Before switching to OC i used CubeCart and is has the same problem especialy when dealing with larger numbers.

cant speak for other countrys but in the netherlands Your total sales incl tax is used to calculate how much tax you have to pay.
rounding problems can be a great problem if involved on large numbers of transactions ie you will pay to much tax if rounding is not correct.

as a mathematical enigineer i want calculations done correct.
buildings and bridges have collapsed because in calculating incorrect rounding was used and overall strenth was just under needed strength.

So for my shops a adapted everything now all ex tax prices do have 8 decimals and problem with rounding with large numbers is solved.
Prices display properly and tax is calculated as it should.

Koeltechnische deurrubbers eenvoudig online op maat bestellen.
Alle niet stekplichtige onderdelen zoals scharnieren, sloten, randverwarming en verlichting voor alle typen koelingen en vriezers.
https://koelcel-onderdelen.com


User avatar
Expert Member

Posts

Joined
Sat Jun 25, 2011 4:09 am
Location - Alkmaar Holland

Post by daik01 » Sun Mar 24, 2013 11:15 am

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

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 » Sun Mar 24, 2013 11:55 am

I've refrained, till now. Just as Consummate Bard Bill's lady protested too much, there is still a practical limit. Virtually every comment and perspective supra has merit of its own. We're concerned basically about the literal bottom line; and no doubt also about subtleties of certain configuration files on servers (floating-point settings among them), database limitations, and to a lesser extent also details of OC innards.

One simple solution is to pass the buck: to the transaction processor. Send the prices, send the quantities, send the tax rates, send the shipping fees or rates, etc., and let the transaction processor compute it. Or just send the total of extensions (prices times quantities), and let the transaction processor compute it. In the instance of PayPal you can set up buttons till you can't stand buttons any more. I daresay that's one of the attractions of OC; no code buttons.

Another simple solution is to provide a v. short notice to effect that if quantity and tax rounding errors are apparent among multiple products or their extensions calculated individually among products, please compare what is shown to what appears at final checkout through the actual transaction processor where the prices are properly lumped before net tax(es), net shipping, and whatever else are then, afterward, added to the solitary units' and ganged extensions' own grand subtotal (and if worried, abort mission there). It may be necessary nowadays to note that half and up is the next one. Education has gone downhill, and fuel prices have long since expressed the con game of a mere mil, much less than a mere farthing or halfpenny, per gallon. Nowadays we can at least be happy that gallons per penny or dollar of mils "won" in the bargain have gone down while dollars per gallon have gone up. There isn't need to try to explain that error rates are machine limited to the inverse 16th power of ten base ten even using floating-point, and even the most proficient primates do not do that well manually unless they keep to fingers and toes (don't push it, no thumbs allowed) with accordingly reduced rounding errors.

Another solution is to show contributing item and extension totals en route to final totals that will probably differ slightly from those (with v. brief notice that only the final transaction numbers count). Probably most of us (with sales but even with vat taxes) go to cash registers unaware till the moment of truth what the taxes cost us (there may be more carnivory stuffed into a scarf vat than into a car vat, but I doubt it), so it is a nicety to be able to see in an OC what items' taxes cost us (there being a reaction to taxes, we can then adjust choices or quantities if we wish). When banks run transactions, by way of cash or check deposits or credit batches, and whether with or without currency exchanges, the totals in are converted into a lump sum among all manner of trivia that gave rise to them, before the deposit or currency exchange is deemed total and is then transacted. When taxes are collected on sales, vat, income, whatever, the totals are reckoned before rates are applied. At taxman's step, either you fill in the little tiny box with a big number or they audit the big number in the little tiny box, but unless they audit they have no genuine interest in the plethora of trivial little numbers that gave rise to the gross or net in the box, they want their form, they want their payment, and they'll let their machines snoop for statistical hints of wrongdoing. (Even California has allowed rounding to whole dollars for several years, but that's not why it's bankrupt.) Granted, customers and bean counters can come unglued over minor discrepancies, and customers comprise a shop's court of public opinion, but unless displays (other than the multidigit one in the admin panel, well beyond pennies) show prices and whatever else well beyond the customary two digits in currency numbers (dimes and pennies or equivalents), the beans will wiggle. Even in the strictest of academic publications, authors often must live with totals that either don't match 100% or must be shown to adequate decimal digits to match it.

Granted, our throwing rocks through a window no longer there is not without a modicum of satisfaction.

Guru Member

Posts

Joined
Wed Mar 20, 2013 6:58 am

Post by hypemedia » Sun Mar 24, 2013 3:28 pm

rph wrote: I'm sure it would come down to local laws or business practices, but I haven't seen businesses that do VAT-inclusive line item invoicing (to my understanding VAT-inclusive is mostly used in places like vending machines where set prices are a must). From an accounting standpoint VAT-exclusive is much more useful as it shows the tax liability without having to go through the extra steps of reverse calculating it product by product in an order.

I'd also add that this isn't an error. It's a side effect of having prices with tax included and displaying that number to a set digit place. When you see a price of €39.00 that's an approximation. That actual price is €38.995. If you buy one unit (which is going to be the display price with tax) your cost would be rounded to €39.00. But if you buy two then it's more accurately $77.99.

Ok I understand that this is how the price is calculated, but in Europe in most of the countries the price a customer sees in the store is the price with all the taxes included. So if the price is 39 euro VAT included (the product price is keept in the store as 31,4516) the vat is 24%. OK as said when the customer is checking out at the order summary is seeing Unit price 39 and if he buys 2 products the 2 products will add as 77,99 instead of 78 from wich 15,10 is VAT. How can I explain in the accounting first where the 1 cent is gone and second how can I explain my customer why my store is calculating 2x 39 in 77,99. This is not an hypothetical problem it is a real one I have right now.

What can I do?

Active Member

Posts

Joined
Fri Aug 17, 2012 5:39 pm

Post by rph » Sun Mar 24, 2013 11:24 pm

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.

-Ryan


rph
Expert Member

Posts

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

Post by rph » Sun Mar 24, 2013 11:36 pm

hypemedia wrote:How can I explain in the accounting first where the 1 cent is gone
Now you know why business accounting uses tax-exclusive line item invoicing.

-Ryan


rph
Expert Member

Posts

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

Post by hypemedia » Mon Mar 25, 2013 12:36 am

rph wrote:
hypemedia wrote:How can I explain in the accounting first where the 1 cent is gone
Now you know why business accounting uses tax-exclusive line item invoicing.
Again this is valid for US not the rest of the world.

I did some more tests and i have setup an product in Magento there i set the price in the backend of the system to 31.45 (only 2 decimals) USD then I apply 24 % VAT and show it to the customer the price incl VAT. If you add 3 products to the cart the total price will be 117 and not 116.99 as in Opencart.

This is because Magento has an option to calculate the taxes based on: Unit price, raw total and total. The calculation is right when Unite price is chosen. For the other options it works as in Opencart calculating the total price at.116.99.

This is what I need to achieve and I don't understand why I can not do that in Opencart. It is a simple questions that dosen't include complicated taxing procedures around the world, just simple math.
Here is the link so you can see what I am talking about.
http://testare2.hype.ro/index.php/test.html

Active Member

Posts

Joined
Fri Aug 17, 2012 5:39 pm
Who is online

Users browsing this forum: No registered users and 23 guests