openerp-expert-accounting team mailing list archive

[Launchpad Bug Tracker <868839@xxxxxxxxxxxxxxxxxx>]

You have been subscribed to a public bug by Amit Parik (OpenERP) (amp-openerp):

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.

** Affects: openobject-addons
     Importance: Undecided
         Status: Opinion

-- 
Tax Rates Round to Decimal Precision of Account + 2 - Should be variable
https://bugs.launchpad.net/bugs/868839
You received this bug notification because you are a member of OpenERP Accounting Experts, which is subscribed to the bug report.