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

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!

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

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.

Thanks.

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:

(1)
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

(2)
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

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

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!

Hello,

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.

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

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!

Amit,

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.

may be you want to try
http://bazaar.launchpad.net/~c2c/c2c-rd-addons/trunk/files/head:/c2c_account_tax_rounding/

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
sum(net)*tax
which is the desired outcome.
Set "Rounding Precision" in Tax definiton.

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 https://bugs.launchpad.net/openobject-addons/+bug/707923/comments/56

Hello

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

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.

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.

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 : http://www.revenuquebec.ca/en/entreprise/taxes/tvq_tps/calcul-taxes.aspx

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:

SQL:
update account_tax set amount=0.09975 where amount = 0.09970;

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

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.

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
http://docs.oracle.com/cd/A60725_05/html/comnls/us/gl/currency.htm#t_currency
….......................
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
http://docs.oracle.com/cd/A60725_05/html/comnls/us/gl/autota02.htm#r_autotax_rul
http://docs.oracle.com/cd/A60725_05/html/comnls/us/ar/calctax.htm#e_calctax