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
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
Even though it makes sense how the price is being calculated I think it is "wrong" from customer and accountant perspective.rph wrote:The price isn't wrong. That's how rounding works.
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.
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.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
-Ryan
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.
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?
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 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.Daniel wrote:putting the match back to 4 decimals not 8
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
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.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'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.
I don't believe this should ever even be an issue as the database isn't used as an intermediary when making calculations.daik01 wrote: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.Daniel wrote:putting the match back to 4 decimals not 8
-Ryan
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
Look at http://www.webfryslan.nl/parallaxI don't believe this should ever even be an issue as the database isn't used as an intermediary when making calculations.
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
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.
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?
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.daik01 wrote:Look at http://www.webfryslan.nl/parallaxI don't believe this should ever even be an issue as the database isn't used as an intermediary when making calculations.
Created 8 decimale, and there is no problem until you buy more the 1.000.000 products
-Ryan
Again this is valid for US not the rest of the world.rph wrote:Now you know why business accounting uses tax-exclusive line item invoicing.hypemedia wrote:How can I explain in the accounting first where the 1 cent is gone
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
Users browsing this forum: No registered users and 32 guests