Take the 2-minute tour ×
Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. It's 100% free, no registration required.

We are using Magento CE 1.7 and have various rounding issues. In various calculations there is a 0,01 EUR difference.

The basic issue might be that the article-prices are incl. tax.

Co-programmers overwrote the Mage_Core_Model_Store::roundPrice() method to calculate with 4 digits precision. But this seems to cause issues with PayPal payments.

Is there a solution for those problems?

EDIT:

We actually tried an official core patch which basically adds 4-digit rounding to \Mage_Tax_Model_Sales_Total_Quote_Shipping::_round, \Mage_Tax_Model_Sales_Total_Quote_Subtotal::_deltaRound and \Mage_Tax_Model_Sales_Total_Quote_Tax::_deltaRound which fixes a coupon rounding issue but not the PayPal problem.

share|improve this question
    
As far as I remember Magento stores prices with 4 decimal points. So if prices are input with 4 decimal points the calculation is correct. But I may be wrong. –  Tim Bezhashvyly Feb 19 '13 at 10:01
    
What do you mean by "input with 4 dec. points"? But the Magento rounding works with 2 dec. points. Also I think the PayPal interface works with 2 dec. points - this seems where the problem starts. –  Alex Feb 19 '13 at 10:07
    
If I recall correctly, if you input prices in admin with 4 decimal points it will be saved in db with 4 decimal points. Then it will be rounded to 2 point during output, but rounding will be correct as price with 4 decimal point will be rounded. –  Tim Bezhashvyly Feb 19 '13 at 10:12
    
Sure - but we mainly have problems with total calculation, especially if percentage-based coupon codes are involved. –  Alex Feb 19 '13 at 10:14
    
Oh, then I got your question wrong. Sorry. –  Tim Bezhashvyly Feb 19 '13 at 10:15

5 Answers 5

We are aware of several rounding issues within the core Magento tax module that cover scenarios that have been described. Presently we're working on those issues for an upcoming 1.13 release. Those rounding issues are triggering a simple Paypal check that determines if the line items in the cart add up correctly. It looks like Fabian's patch takes care of the Paypal check in the short term.

If you have any questions, comments, or suggestions on how we can improve the Magento Tax module please don't hesitate to contact me as I'm the product manager responsible for taxes.

Regards, Chuck

share|improve this answer
    
Great! Is there some kind of test suite available to show which issues will be tackled? –  Alex Feb 21 '13 at 16:45
    
Chuck, would you mind setting up your user info in order to verify? –  benmarks Feb 21 '13 at 17:25
    
The tests are internal only. As far as more detail on known rounding issues - that's a little interesting. A customer would see them as being associated with certain tax configurations using specific combinations of price, tax rate, discounts, etc. Our approach for 1.13 has been to identify common tax configurations and ensure that # combinations will not mathematically produce rounding errors and tag certain configurations (small corner cases) as hazardous configurations that should be avoided. –  Chuck Feb 21 '13 at 17:39
    
A little bit off-topic, but does it mean that there would be also CE 1.8 edition? –  Sergei Guk Feb 21 '13 at 19:47
    
Yes - CE releases lag EE releases by about a month. 1.13 is the next EE release. –  Chuck Feb 22 '13 at 18:46

Thanks to Andreas Vogt, I build a module to fix the Paypal round bug. Andreas gave me a few core hacked files and I made the module. It checks wether the sums are correct and if not, it is corrected.

Afaik the core hack is tested in the wild. A lot of people asked for the module, but no onw gave me feedback wether it works. But it is unit tested! (only wether the rewrites work, because I had no idea, what the paypal problem is ;-))

https://github.com/magento-hackathon/PaypalRoundBugfix

share|improve this answer
1  
Hm .. which bug exactly does it fix? Looks like the cart-line-items-transfer bug. We actually have switched the cart-transfer off. And is it to be applied with the 4-digits rounding patch? –  Alex Feb 19 '13 at 10:35
    
Is there more than one problem? As I said, I have no idea, what exactly it fixes - if there is more than one problem :( –  Fabian Blechschmidt Feb 19 '13 at 11:09

We are facing both, the paypal rounding bug and the issue with coupon codes of 100% discount. We only have problems on prices (like Eur 3,99 incl. tax), where the net price has on the 3rd digit a 5 (3,325). So also the tax (here with 20%) has on the 3rd digit a 5 (0,665). So if you round and add both prices (what paypal and magento does) the total is Eur 0,01 more than the base price (Eur 4,00).

The right caclulation should be Eur 3,32 net + Eur 0,67 tax = Eur 3,99

As we are also trying to find a general solution, we give the paypal rounding fix a try!

share|improve this answer
    
great, tell me if you have problems, I'm eager to help and see the Bugfix in the wild and debug it if needed! –  Fabian Blechschmidt Feb 20 '13 at 11:01
1  
FYI the issue you've described is fixed in our upcoming release ( 1.8 CE / 1.13 EE ). –  Chuck Mar 12 '13 at 14:39
    
@Chuck I have just tested this scenario with Mage_Tax_Model_Sales_Total_Quote_Tax from 1.13.0.1 and it does look to have resolved the issue as a drop-in replacement in a 1.12 project. Thanks very much. Is there an ETA for 1.8CE yet? –  Jonathan Day Jun 1 '13 at 11:53

there is a general relationship between the prices, the quantity, discount, tax and their precisions.

Assume:
x is the price
y is the percentage
s is the rounded sub-total

2 Directions
A) incl. Tax => excl. Tax => incl. Tax
B) excl. => incl. => excl.

The important issue is the rounded subtotal I am calculating with the max. Error. 2 fractional digits means 5*10^-3

A) x*10^2/(y+10^2) // s*(y+10^2)/10^2

B) x*(y+10^2)/10^2 // s*10^2/(10^2+y)

A)
Subtotal precision 2 fractional digits:
5*10^-3*(y+10^2)/10^2 => (y+10^2)/10^2<1 => no y
3 fractional digits:
5*10^-4*(y+10^2)/10^2 => (y+10^2)/10^2<10 => y<900
4 fractional digits:
5*10^-5*(y+10^2)/10^2 => (y+10^2)/10^2<10^2 => y<90900
(must be a very bad country)

......

B)
Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/(10^2+y) => 10^2/(10^2+y)&lt;1 => every y

If you want to calculate with discounts or taxes and want to recalculate the price, the next explanation can be interesting for you. Please be aware since I don't know any case in the front-end, it is possible there is an intern calculation. A) Total => Tax/Discount =>Total B) Tax/Discount => Total => Tax/Discount

A) x*y/10^2 // s*10^2/y

B) x*10^2/y // s*y/10^2

A) Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/y => 10^2/y < 1 => y>10^2
Subtotal precision 3 fractional digits:
(5*10^-4)*10^2/y => 10^2/y < 10 => y>10
Subtotal precision 4 fractional digits:
... 10^2/y < 10^2 => y>1

With a precision of 2 digits, you must have a rate with NO FRACTIONAL DIGITS. Example: Total: 15,15 tax-rate: 0,3% => tax 0,04545 => rounded 0,0455 tax: 0,0455 => total: 15,17

B) Subtotal precision 2 fractional digits:
(5*10^-3)*y/10^2 => y/10^2 &lt; 1 => y < 10^2

if a is the precision, than must be y less than a+2.

Please note if you handle quantities. The error will be multiplicated. So if you have a max of 10^5, you have to have a precision of 7. This is only worrying, if you are calculating with offset!

ADDITION (9.10.2013 Magento Version 1.7.0.2) Brutto <=> Netto and Taxes // America <=> old Europe Sets are integers (Cents) and the mapping
f(x) = round(a*x) a>1 is not bijective. In my words: Not for every price incl. exists a price excl. or There are sometimes 2 prices incl. for one price excl. or You can get 2 different results depending how you calculate

Real-world-example from Germany:

You try to enter a price incl. taxes: 19,95 You get 16,76 (2 digits) as your prices excl. the taxes (19%). If you calculate the 19% taxes you get (16,76*0.19) 3,18. (Be aware: 19.95 * 019/1.19 ~ 3.19)

So there is 1 Cent difference. 16,76 => 19.94 16.77 => 19.96

There is no price 19,95 in america - land of netto.

So calculate with original prices as far as possible. For including prices use entered price and the taxes (broken number).

PayPal has this fraud check - now i'm not sure - but PayPal just adds the number magento gives it. see http://fabiankrueger.de/blog/magento-und-paypayl-rundungsfehler/ If this is not true and PayPal recalculate Tax or Total, this problem is not solvable, else the prices - wrong or right - are shown before in Magento. Solve it there. For me it seems to work.

share|improve this answer

Here is a new lightweight extension that fixes that error: http://www.magentocommerce.com/magento-connect/catalog/product/view/id/20012/

share|improve this answer
2  
Be really good if you explained what you had done in the module, the approach you took and why etc. –  McNab Oct 10 '13 at 10:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.