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 -- You received this bug notification because you are a member of OpenERP Accounting Experts, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/868839 Title: Tax Rates Round to Decimal Precision of Account + 2 - Should be variable Status in OpenERP Addons (modules): Confirmed 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-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
