Tax Rates Round to Decimal Precision of Account + 2 - Should be variable

Bug #868839 reported by MIke Pestorich
This bug affects 8 people
Affects Status Importance Assigned to Milestone
OpenERP R&D Addons Team 3

Bug Description

In it was noted that tax percentage rates were limited to 2 decimals. As a "reasonable default" new code was introduced to fix this by changing that behavior to "use the decimal_precision of Account +2 for percentage values". While I can understand how this would work in most situations, we have just implemented an OpenERP system in Fresno CA where the local sales tax is in fact 7.975% (or 0.07975 when entered into OpenERP). Currently that rounds our rate to 7.98% given our Accounts are setup with a precision of 2. This does not calculate the correct tax amounts on our invoices (off by as much as a few dollars in some instances where the invoiced amount is large enough). We have no need for nor do we want our Accounts to round to anything beyond 2 decimals and the fix implemented in the bug above precludes using a tax rate such as the one noted that requires more than 4 decimal places (account +2 in our case is 4 but the rate we use needs 5).

While I understand one can change the calculated tax value on the invoice, that is not behavior that I can expect of our end users on a regular basis. In the interim I have modified the code on our side in to return account+3 instead of account+2:

class account_tax(osv.osv):
    def get_precision_tax():
        def change_digit_tax(cr):
            res = pooler.get_pool(cr.dbname).get('decimal.precision').precision_get(cr, 1, 'Account')
            return (16, res+3)
        return change_digit_tax

This works fine for me but I thought that since the previous bug noted Account+2 was a "reasonable default" that it should be just that... a default - which implies the decimal precision of the rate relative to the account precision should be variable and able to be set by the user. I personally believe that Account precision and Tax precision have nothing to do with each other and shouldn't be related in such a way to begin with. Shouldn't there be an actual entry in the decimal_precision table specifically for taxes that does not depend on and unrelated entities precision? Something like:

class account_tax(osv.osv):
    def get_precision_tax():
        def change_digit_tax(cr):
            res = pooler.get_pool(cr.dbname).get('decimal.precision').precision_get(cr, 1, 'Tax')
            return (16, res)
        return change_digit_tax

Just my thoughts.

Current Environment:
OpenERP 6.0.3 on Mac OS X 10.7 (the code above exists in the trunk as well)

I'd be happy to help work something up if any one agrees or would find my suggestion to be useful.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Mike,

I have checked your issue and according to lp:667316 we have set a decimal accuracy for account tax.

So when you want to more precision on it you have to change the decimal accuracy of account.

For more information I have attached a video so would you please check it and notify us where you face the problem.

Thanks and waiting for your reply!

affects: openobject-server → openobject-addons
Revision history for this message
Amit Parik (amit-parik) wrote :
Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenERP Addons because there has been no activity for 60 days.]

Changed in openobject-addons:
status: Incomplete → Expired
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Mike,

Would you please try with the latest updated code.

If you still face the problem then you can reopen this with more information.


Changed in openobject-addons:
status: Expired → Invalid
Revision history for this message
MIke Pestorich (mmpestorich) wrote :

I'm sorry I thought I replied to this a long time ago but apparently I didn't.

No the "fix" you pointed out to me (lp:667316) is exactly why I filed this in the first place. I didnt like the way it was implemented. What that does is require me change the decimal precision of ALL my accounts to 5 in order to enter a tax rate with 5 decimals. However, I want all of my accounts to have a decimal precision of 2 not 5. The tax rate is the only thing that needs to be stored with 5 decimals.

With that code:

If account precision is set to 5 to allow me to use a tax rate of 7.975% (or 0.07975). Then an invoice looks like this:

Sub Total: 1,234.56000
Tax (7.975%): 98.45616
Total: 1,333.01616

If account precision is set to 2 the tax rate is rounded to 7.98%. Then the invoice looks like this:
Sub Total: 1,234.56
Tax (7.98%): 98.52
Total: 1,333.08

What I should be able to do is leave account precision at 2 but still be able to use a tax rate with precision of 5 that rounds to 2 after the rate is applied to the total:
Sub Total: 1,234.56
Tax (7.975%): 98.46
Total: 1,333.02

As you can see, I get three different Totals depending on the scenario. The third one is what I would like to do as this, as far as I know, is how sales/purchase taxes are commonly calculated over here.

With that said, no big deal if there is no intention to change the behavior. The code change I instituted above allows me to get by just fine for now. I just think there is something wrong with tying account precision with tax rate precision. They are two completely different things.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Mike,

First Thanks for your patience on this issue.

We have used a same decimal accuracy for 'tax' and 'accounts'. So If you want to set your tax precision on 5 then you have to change your account's decimal accuracy.

I think this is not create any problem because If you need decimal accuracy for taxes then your total must be have the same precision. Which is works fine with current scenario.

If you want another precision for your taxes then you can customise it easily at your end. Just create new precision for "taxes' and assign this precision where you needed.

I think this is not a generalise issue but we needs more information on this. How the real scenario working for this?

That's currently I am setting this as an "Opinion" and ask to experts mailing list for "how to handle this type of scenario in real way". After discussion on this we will decide the better way.

@Accounting Experts : Would you please share your views on this.

Thanks and more suggestions are welcomed!

Changed in openobject-addons:
status: Invalid → Opinion
Revision history for this message
Kyle Waid (midwest) wrote :


Thank you for the video. I tested this and it does indeed create more decimals on taxes, however the accuracy is not computed. If I use 0.0275 it will compute a number for tax, if I use 0.0275948302 or any other decimal accuracy it will not compute, it will only consider the first few digits, so your solution does not solve the problem. I tested this just today on latest sources. The best way to test is to increase the decimal accuracy, and then place an order for a very high dollar amount. In my case it was 68,000. The taxes were off by 12 dollars!!! Even with extreme decimal accuracy defined.

Changed in openobject-addons:
status: Opinion → New
Revision history for this message
Kyle Waid (midwest) wrote :

One thing I wanted to stress importance on, I do not understand the tax calculation method in OpenERP. It does not make sense to me. In almost ANY program I can configure an actual percentage like 7.275, 15% and so on. But in OpenERP I have to use a ratio 0-1? like 0.0275 or something similar. The problem ends up is that the tax calculation is not the same.

When using an external order system I have to match exactly the amounts in the external system with OpenERP. Because the taxes have to be calculated independently in OpenERP it appears impossible to have a match. I find in all cases there is a rounding discrepancy and the higher the amount of the sale the higher the discrepancy.

This end result makes auto-reconciliation of sale order impossible. One of pythons great features is decimal accuracy, so I am surprised to have such an issue.

I also agree with mike in the fact you do not have a standard built in configurable option for taxes. Things like this are industry standard and you should not have to make any modification. Just like when you create a new database and it selects euro as the currency silently. You really need to work on these things, its so simple and so asinine to have these problems in an "enterprise" software

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Kyle,

Thanks for your reply and nice explanation on this.

As I said before, If you want to more digits on your tax decimal you have to change your account precision means you have to change your account decimal accuracy as I shown in video. i.e. for your 2nd option 0.0275948302 you have to set "Account" decimal accuracy at 10 and it will works.

According to your last comment ,"You really need to work on these things, its so simple and so asinine to have these problems in an "enterprise" software", That's good. Because as per my "Opinion" also we have to differ account precision and tax precision.

Also this is not a blocking point rather than it's good feature request.

That's why I am considering this as a "Wishlist".

Thanks again!

Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3)
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
MIke Pestorich (mmpestorich) wrote :


With all due respect, I couldn't disagree more with your assessment that this is not a "blocking point".

If I change Account Precision to accommodate a higher precision tax rate then my transaction amounts don't calculate correctly due to accumulated rounding differences (as in sub-point 1 under comment #5 above).

If I leave the Account Precision alone then tax amounts are not calculated correctly (as in sub-point 2 under comment #5 above).

Account Precision and Tax Rate Precision are two separate things. It makes no sense for them to share the same precision setting. The only way to calculate correct tax amounts and correct transaction amounts is to have two different precision settings (as in sub-point 3 under comment #5 above). Without the modification I made to the code (in the original summary to this bug), OpenERP would be completely UNUSABLE in places such as California where high precision tax rates are common and lower precision transaction amounts are necessary.

That's my two cents at least.

Revision history for this message
Ferdinand (office-chricar) wrote :

may be you want to try

Default tax calculation is per line including rounding of tax amount per line.
This module turns off rounding per line and per tax, hence simulation vertical calculation
standard: tax = sum(round(net*tax)) (~decimal)
this: tax = sum(net*tax) (~float)
WARNING - in extremely rare cases this may also produce another result than
which is the desired outcome.
Set "Rounding Precision" in Tax definiton.

Revision history for this message
Lorenzo Battistini (elbati) wrote :

For more references about tax computation methods, see bug 707923 .

A patch for 'account' module (OpenERP 6.1) is available at branch lp:~openerp-community/openobject-addons/fix-account-6-1-tax-computation-method . You can find the relative patch file at

Revision history for this message
Ferdinand (office-chricar) wrote :


I just tried the patch

some remarks

1) If SO or PO have
vertical_comp = True
then the generated invoice must have it too

2) I think the vertical_comp must have a general setting
* company
* tax and/or
* partner

usually it will be sufficient to set this parameter at company level, because all companies in in the "home" country will usually follow the local rule vertical or horizontal

if nothing is found at partner we check tax and then company and use this as default

obviously this parameter can also be set as default in SO/PO/INV

Revision history for this message
Fabrice (OpenERP) (fhe) wrote :

Hello Dr. Ferdinand and Lorenzo,
Could you explain why you involve the "horizontal computation vs. vertical computation" debate in this thread? The comment #5 seems to show a rounding problem related to currency decimal precision vs. tax decimal precision and presents a scenario that raises a mistake with only one invoice line. So I don't understand why we are involving horiz. vs vertical computation which is IMO another debate.
The issue we are talking about here is already visible with only one invoice line. Let's not make the hypothesis more complicated than what it needs to be.
Looking forward to having your input.

Revision history for this message
Ferdinand (office-chricar) wrote :

may be this was a comment on the wrong place, nevertheless it's a shame that we have to deal with such issues in this stade of the project.

Revision history for this message
Jonatan Cloutier (jonatan-cloutier) wrote :

We also have this problem in Quebec (Canada) where the rate is 9,975% (0.09975) so we need to compute the taxes with a rate precision of 5, but the total amount of an invoice must be rounded to 2 decimal either by line or globally. Here is the state reference :

Revision history for this message
Benwah (benwah) wrote :

This is indeed a bug for Quebec (Canada).

I found a *bad* temporary fix that seems to work for invoicing at least, this works for Quebec taxes:

update account_tax set amount=0.09975 where amount = 0.09970;

Revision history for this message
Matthias Chardon (matthias-chardon) wrote : AUTO: Matthias CHARDON is out of the office (returning 17/06/2013)

I am out of the office until 17/06/2013.

I am out of office until June 17th, pls contact Sebastien Roche in case of

Note: This is an automated response to your message
"[Openerp-expert-accounting] [Bug 868839] Re: Tax Rates Round to Decimal
Precision of Account + 2 - Should be variable" sent on 15.06.2013 04:52:40.

This is the only notification you will receive while this person is away.

Revision history for this message
GUENARD (michel-guenard) wrote :

Hi every one.
Just joining the discussion and fresh user of OpenErp:)

Rates used for calculations, like Taxes, rebates, currency conversions, social security taxes, sales commissions, income taxes, quantity rates of a product used in a BOM etc... can not be rounded up or down by any software.

These rates are either determined by the law or by an agreement (signed or not) between parties (partners) or determined as a ruling inside the company.

They must stick to these rules which are mandatory and hence set by the users (at cy level) with the appropriate decimal length.

Calculations like average cost of products or average hourly rate of salary or rebates per unit of sale, weights per unit, quality default rate per unit (or million of units) ....resulting on decimal values can be rounded by the users, according to their company business rules AND/OR applicable regulations.

For accounting purposes, the result of any single calculation (rate*base_amount or sums/substraction) needs to comply with the currency decimal structure of the company in order to fit with the lowest monetary unit (cents for instance when cents are a monetary unit)

Other famous ERP softwares already solved these issues; I believe OpenErp cannot be innovative in this regard. see Oracle, SAP...
See for instance, Oracle guidelines for currency rates
6. Enter the Precision of the currency to designate the number of digits to the right of the decimal point used in regular currency transactions.
7. Enter the Extended Precision to designate the number of digits to the right of the decimal point used in calculations for this currency. The extended precision must be greater than or equal to the standard precision.
Note: Some Oracle Applications use the extended precision. Others, like General Ledger, do not.
8. Enter the Minimum Accountable Unit to designate the smallest denomination used in this currency. Note that this might not correspond to the precision.
See tax calculation rules

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments