openerp-india team mailing list archive

["Kyle Waid - http://www.gcotech.com" <868839@xxxxxxxxxxxxxxxxxx>]

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

-- 
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):
  New

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