openerp-india team mailing list archive
-
openerp-india team
-
Mailing list archive
-
Message #10795
[Bug 936842] Re: [6.0 - trunk] Bad computation for residual invoice and account.move.line
** Changed in: openobject-addons
Status: Expired => Invalid
--
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/936842
Title:
[6.0 - trunk] Bad computation for residual invoice and
account.move.line
Status in OpenERP Addons (modules):
Invalid
Bug description:
Hi everyone,
Today I’d like to submit you a problem I found in account module for
the way the residual amount is computed. This is not really a bug,
more of a misconception.
Here is my problem:
Currently, here is the account.move generated for an invoice (without tax) :
4111001 Customer X Debit 75,00€
706 Credit 75,00€
For my customer, I have to develop a commission management and I decide to make use of the accounting system for this.
The important point here is, the commission account can be the same than the receivable account because the people who have the commission is also often our customer.
So in my development, I create some others account.move.line. Here is
our account.move example with a 10% commission:
4111001 Customer X Debit 75,00€
706 Credit 75,00€
4111001 Customer X Credit 7,50€
606 Debit 7,50€
Until now, everything is fine. Unfortunately the residual field of the
invoice is bad computed. Instead of the 75-7,50 = 67,5€ I want to
have, I have the sum 75+7,50 = 82,50€.
I thought I’d just have to make sure some fields are negatives, but
after looking at the code, it seems this will not be as simple as
that.
First, looking at the function _amount_residual from account.invoice.py :
for m in invoice.move_id.line_id:
if m.account_id.type in ('receivable','payable'):
result[invoice.id] += m.amount_residual_currency
It seems the residual invoice field is the sum of all the
amount_residual_currency of the invoice account.move.line. Ok, at this
point I thought I’d just have to find the amount_residual_currency
field of the commission move line and make it negative.
Unfortunately, here is how amount_residual_currency is computed,
looking at the _amount_residual function in account_move_line.py :
[…]
move_line_total = move_line.debit - move_line.credit
sign = (move_line.debit - move_line.credit) < 0 and -1 or 1
[…]
res[move_line.id]['amount_residual_currency'] = sign * (move_line.currency_id and self.pool.get('res.currency').round(cr, uid, move_line.currency_id, result) or result)
Here is what I understand from this code: The sign code line is here to make sure that the amount_residual_currency is always positive.
Since I want to make the amount_residual_currency of my commission line negative, I suppose you understand my problem. I can’t resolve my residual computation problem with only my module, I also have to refactor the residual function computation in account module.
I think I understand why you did that, make sure
amount_residual_currency is always positive, this is because of the
supplier invoice. With supplier, debit and credit are inversed so to
keep the supplier invoice positive you coded the function this way.
But I do think this is really a terrible way to do it, and my case
proves it. Because of this choice, it is impossible to make negative
residual, and so we lose a lot of flexibility with our account lines.
I think the only good way to do it would probably to recognize if this
is a customer or supplier invoice/account move, because this is the
information which indicate the sign of debit or credit. The best way
would probably to put this information on account.journal, if this is
a sale journal or purchase journal, and compute the residual with this
information (debit – credit = positive if sale journal, negative is
purchase journal)
I suppose there will also some work to do in the reconcile function,
but I didn’t investigate on it.
What do you think?
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/936842/+subscriptions
References