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. -- You received this bug notification because you are a member of OpenERP Indian Team, which is subscribed to OpenERP Addons. https://bugs.launchpad.net/bugs/868839 Title: Tax Rates Round to Decimal Precision of Account + 2 - Should be variable Status in OpenERP Addons (modules): Invalid Bug description: In https://launchpad.net/bugs/667316 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 account.py 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. To manage notifications about this bug go to: https://bugs.launchpad.net/openobject-addons/+bug/868839/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~openerp-india Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-india More help : https://help.launchpad.net/ListHelp
