openerp-expert-accounting team mailing list archive

[<hproust@xxxxxxxxxxxx>]

Hello, 

+1

This is a similar issue we had raised in 2010 with a
negative answer from OpenERP. I copy below my initial message sent in
Nov 2010. 
_1. If I am correct, the solution you proposed to handle VAT
is as follows: _
_account.py (line 1659)_
_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+2)_
_return change_digit_tax_

_2. This
solution deals with most common European needs, but does not answer my
request, as I explain below. _

_Cameroon:_
_- Currency: XAF (CFA
Francs), no decimals _
_- VAT: 19,25%_
_- Account: no decimals_

If I
apply your solution, I will have 'Account'=0 in decimal_precision, VAT
field will be limited to 2 decimals, and will not allow me to configure
correctly without entering some code. 

_3. Solution: _
 _As as
principle, in all developments, variables used must not be linked to
"functional objects" which have different use: _
_eg. taxes and accounts
are two different objects, and should not be linked to one unique
variable in decimal_precision 'Account' but should be clearly separated.
_

_I come back to my initial proposal (which may not be the best
one...): _
_Proposal :_
_Change 'Account' to 'TaxAmount' in account.py
in line 1658 :_
_'amount': fields.float('Amount', required=True,
digits_compute=dp.get_precision('TaxAmount'), help="For taxes of type
percentage, enter % ratio between 0-1."),_
_Create new variable in
decimal accuracy menu : Usage: TaxAmount ; Digits: 4 (as an
example)_

_** This bug has been marked a duplicate of bug 667316_
_ tax
percentage limit 2 digits_
_ * You can subscribe to bug 667316 by
following this link:
https://bugs.launchpad.net/openobject-addons/+bug/667316/+subscribe_

Best


Hervé

_________________________________________
Hervé PROUST

Directeur Associé Bureau : +212 (0)522 23 54 44
Mobile Maroc : +212 (0)
670 76 83 67
Mobile France : +33 (0) 6 61 41 50 58 

10, rue Ibnou Al
Arif
20 100 Casablanca - Maroc
hproust@xxxxxxxxxxxx

www.kazacube.com

On Wed, 4 Jul 2012 10:17:34 -0300, Raphael Valyi
wrote: > Hello, > > I fully agree with what Eric said. I recently had a
conversation with > Joel from CampToCamp about this and he told me
CampToCamp tried to get > this changed the same way Eric said too (but
ended patching their > customer to get the job done). May be CampToCamp
can confirm here. > We have a customer with this issue (hopefully he
will soon purchase > an OPW and we will throw yet an other OPW on that
bug). > > IMHO, it's quite likely to encounter this kind of issue. If
for > example you deal with employees expenses and buy some gas for a >
travel, it's very likely that gas unit price will need more than 2 >
digit precision to match the invoice you get from the gas station when >
buying many units. And of course, accounting will still have to be >
only 2 digits (BTW, it seems that in some countries accounting >
precision could be different than 2 digits, but it's unrelated to >
price unit and very rare). > Sorry, but I find it incredible when
OpenERP SA tells partners about > selling OpenERP "out of the box", when
such issues are running unfix > and even unacknowledged for years and
years. > > So +1 for Eric's comment from Akretion's point of view. > >
On Wed, Jul 4, 2012 at 9:59 AM, Eric Caudal wrote: > > As far as I have
experienced due to business constraints, you can > have different
precisions for sales prices, purchases prices and > accounting. > > I
have a customer who is selling small pieces at for example 0,123 > RMB
each (in RMB) and buy it at 0,1234 (in euro). You dont want your >
accounting to be impacted because usually these are total numbers (you >
keep it at 2 digits). > > The factor between euro and RMB is small (x10)
but some other > currency have larger proportion (I am thinking for
example in Vietnam > dong) > > It will depend a lot on business
conditions, which is very difficult > to foresee. This is why I tend to
advocate for a common sales price > precision for SO and CI, a common
purchase price precision for PO and > SI and a separate accounting
precision. > > To be noted that this is not what this module is doing:
it creates > only a accounting line precision: to achieve sales price
precision > different to purchase price precision, we should create in
the invoice > line 2 different prices (one for sales and one for
purchase) and > change all internal calculations. For simplicity (and
because I didnot > need it) I kept it as a separate precision. > > ERIC
CAUDAL, Elico Corp, Shanghai. > eric.caudal@xxxxxxxxxxxxxx [2] > Cell: +
86 186 2136 1670 [3]. Skype: elico.corp > PREMIUM CERTIFIED TRAINING
PARTNER - OPENERP READY PARTNER. > > http://www.openerp.net.cn [4] > >
On 07/04/2012 08:35 PM, Numérigraphe wrote: > > Thanks for you input
Eric. > I agree that the precision must be the same in invoices and
orders. > If I understand, you propose to "push" the order's precision
to the > invoices and accounting entries. > Isn't it simpler to just set
the order lines' precision to that of > the accounting? > Lionel. > > **
Summary changed: > > - Wrong precision for tax in sale/purchase order
lines > + Wrong precision for subtotals in sale/purchase order lines > >
_______________________________________________ > Mailing list:
https://launchpad.net/~openerp-expert-accounting [5] > Post to :
openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx [6] > Unsubscribe :
https://launchpad.net/~openerp-expert-accounting [7] > More help :
https://help.launchpad.net/ListHelp [8] > > > > Links: > ------ > [1]
mailto:eric.caudal@xxxxxxxxxxxxxx > [2]
mailto:eric.caudal@xxxxxxxxxxxxxx > [3]
http://ssl0.ovh.net/tel:%2B%2086%20186%202136%201670 > [4]
http://www.openerp.net.cn > [5]
https://launchpad.net/~openerp-expert-accounting > [6]
mailto:openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx > [7]
https://launchpad.net/~openerp-expert-accounting > [8]
https://help.launchpad.net/ListHelp