[trunk] foreign_balance should not be computed for account with no secondary currency
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP R&D Addons Team 3 |
Bug Description
Hello.
We are working on this Optimization:
And we face a BIG problem with multicurrency feature just improved some little time ago.
In this line of account.py
'foreign_balance': "COALESCE(
We see that this algorithm sum all multicurrency values and it is TOTALLY wrong, because i can have n the same account different vaules, and we NEVER can sum Apples with Pears.
How functionally you can try:
Make an move invoice on €.
Then Make an invoice to same partner in USD$
Make an invoice an you currency, (We Use VEF).
Then go to edit tree view for accounts and show the field "foreign_balance" with the view editor,
You can face that if pfor example you made 3 invoice for 100 CURRENCY, the total for the account REceivable or Payable related on this invoices.
The amount received is 300 (sum directly for 100€ 100$ and 100VEF)
-In V6 this feature is simply missing.-
I think it is a huge cancept mistake.
IMHO, we need to have from OpenERP-dev team a Blueprint related with the concept that they want to implement in this field, because in other way this field is really useless and affect the performance in calculation.
Related branches
- Raphael Collet (OpenERP) (community): Approve
-
Diff: 12 lines (+1/-1)1 file modifiedaccount/account.py (+1/-1)
summary: |
- [TRUNK 6.0] Bad computation for multicurrency move lines + [trunk] bad computation for multicurrency move lines |
Changed in openobject-addons: | |
status: | In Progress → Fix Committed |
Hi,
The 'foreign_balance' function field represents the balance in the secondary currency for GL accounts which *do have* a secondary currency set (currency_id != False), and thus have all their journal items expressed in that same secondary currency.
It makes no sense for GL accounts which have no secondary currency, and thus may mix different currencies.
We should improve the __compute function to make sure the foreign_balance is always computed as 0 for GL accounts that don't have a secondary currency.
This may confuse other people tinkering with the low-level accounting database structure, so let's not consider this a Wishlist.
Thanks for reporting.