chart of account tree - unexpected behavior in sorting records

Bug #315212 reported by Jan Verlaan
22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Undecided
Stephane Wirtel (OpenERP)

Bug Description

I am building a new chart of account. In the account tree my items are not in sequence as
1
-->10
2
-->20
but are unexpectedly changing to
2
-->20
1
-->10
thus into the wrong sequence.

I have searched and found that the tablefield parent_left is calculated and used for ordering the data, but could not find how I can manually influence that behavior.

My only option is to create a XML in the right sequence so when installing the chart of account country module the table is populated in right sequence and the parent_left is calculated in sequence.
But when adding account records later on they don't fall in the right sequence.

This is a problem for countries where the chart of account is not fixed developed by the country administration like in The Netherlands or USA, where users start with a minimal chart of account and can add extra accounts later on when needed.

OpenERP RC3
Proposal for code change in:
/addons/account/account.py
line 127
    class account_account(osv.osv):
        _order = "parent_left"
        _parent_order = "code"
        _name = "account.account"
to
    class account_account(osv.osv):
        _order = "code" #<<== changed order from "parent_left" to "code"
        _parent_order = "code"
        _name = "account.account"

I have tested this change and it gives the right behavior. All chart of accounts are sorted now based on "code" instead of "parent_left" resulting in a logical order of account number and/or alphabetic.

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

changed project from openobject-server to openobject-addons as it is specific in account module.

Revision history for this message
Jan Verlaan (jan-verlaan) wrote :

With revision 1488 the code is changed from what i propose to what it is now.
So originally it was working ok!
Revision 1488 is used to remove "Fast Charts of Accounts", but why this variable is changed I can't find out.
(bad fix???)

BTW, the new introduced variable with revision 1488 "_parent_order" is never used in the code!

Changed in openobject-addons:
assignee: nobody → qdp
qdp (OpenERP) (qdp)
Changed in openobject-addons:
assignee: qdp → stephane-openerp
Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

I just fixed for the installation process.
Stw will work to fix for update/create methods.

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

fixed in trunk.

Changed in openobject-addons:
status: New → Fix Released
Revision history for this message
Ferdinand (office-chricar) wrote :

pls review this patch ( as I do not understand the parent_left construct yet)
but AFAICS it works now

the accounts have not been sorted correctly
prior I got something like
01 (parent view)
02 (parent view)
010 account
011 account
020 account

and after patch a correct sort
01 (parent view)
010 account
011 account
02 (parent view)
020 account

Revision history for this message
Ferdinand (office-chricar) wrote :

pls see patch

Changed in openobject-addons:
status: Fix Released → Incomplete
Revision history for this message
Ferdinand (office-chricar) wrote :

patch does not work always neither

is it possible to get a correctly sorted list ?

in "charts" the accounts are listed correctly

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

has been fixed in trunk 2 weeks ago. Problem related to parent_store.

Changed in openobject-addons:
status: Incomplete → Fix Released
Revision history for this message
Pieter J. Kersten (EduSense BV) (pieterj) wrote :

Actually, the order is still messed up after the fix. The order still depends on the code of accounts. View accounts with a name breaking the order of account coding will end up clustered at the bottom/top of the chart. A solution is in changing the _parent_order to "parent_left" as well.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.