journal_id and period_id in account.move.line should be 'related' fields, and hidden in most cases

[Mohammed]

Journal_id and Period_Id are repeatedly defined in Account.move and account.move.line which is not reasonable as long as I can not create different lines with different journals per move
 _constraints = [
        (_check_centralisation,
            'You cannot create more than one move per period on centralized journal',
            ['journal_id']),
        (_check_period_journal,
            'You cannot create entries on different periods/journals in the same move',
            ['line_id']),
    ]

Having said that, IMHO I do not see that need for redundancy in account.move.line as long as it is already defined in account.move. Furthermore, it is really and noticeably from past experience confuse the end user while doing data entry and decreasing the UX.

[Frederic Clementi - Camptocamp (frederic-clementi)]

+1

[Stéphane Bidoul (Acsone) (sbi)]

+1 see also bug #713539

[Stéphane Bidoul (Acsone) (sbi)]

Seems to be similaro to bug #720808

[Olivier Dony (Odoo) (odo-openerp)]

After discussing in R&D, here is a bit or rationale for these fields:
- they are needed for performance reason on account.move.line to avoid indirect lookups every time
- they must be exposed sometimes to the user, e.g. when doing manual journal entries (no parent move exists to take the values from)

However, as described in this bug and its duplicate(s), the current implementation indeed needs to be improved with regard to values copy/sync and field visibility, in the following manner:

1) Values copy/sync: if possible the fields should be converted to fields.related, so that their values are properly synchronized/shared between lines and their move. If fields.related does not work because of the journal items line-by-line creation, then perhaps this can work with function fields instead.

2) Visibility: the default form and tree views for account.move.line should never contain these fields. They should only appear when the stock move values are not directly visible (probably mainly in the Journal Items menu)

I am confirming the current bug (which has a better description) and marking bug 713539 as a duplicate.

[Bogdan Stanciu (bstanciu)]

On 13. 05. 11 16:43, Olivier Dony (OpenERP) wrote:
> After discussing in R&D, here is a bit or rationale for these fields:
> - they are needed for performance reason on account.move.line to avoid indirect lookups every time
> - they must be exposed sometimes to the user, e.g. when doing manual journal entries (no parent move exists to take the values from)
>
> However, as described in this bug and its duplicate(s), the current
> implementation indeed needs to be improved with regard to values
> copy/sync and field visibility, in the following manner:
>
> 1) Values copy/sync: if possible the fields should be converted to
> fields.related, so that their values are properly synchronized/shared
> between lines and their move. If fields.related does not work because of
> the journal items line-by-line creation, then perhaps this can work with
> function fields instead.
>
> 2) Visibility: the default form and tree views for account.move.line
> should never contain these fields. They should only appear when the
> stock move values are not directly visible (probably mainly in the
> Journal Items menu)
>
> I am confirming the current bug (which has a better description) and
> marking bug 713539 as a duplicate.
>
> ** Changed in: openobject-addons
> Importance: Undecided => Low
>
> ** Changed in: openobject-addons
> Status: New => Confirmed
>
> ** Changed in: openobject-addons
> Milestone: None => 6.1
>
> ** Changed in: openobject-addons
> Assignee: (unassigned) => OpenERP R&D Addons Team 3 (openerp-dev-addons3)
>
Good that is moving forward! This is a rather "old" story...

thank you!
bogdan

[Bharat Devnani (Open ERP) (bde-openerp)]

Hello Mohammed,

Thanks for reporting. The Revision ID and Number of the bug are as follows:

Revision ID : <email address hidden>
Revision Number : 4892

The Solution of the bug will be merged in addons soon.

Thanks & Regards,
Devnani Bharat R.

[Mustufa Rangwala (Open ERP) (mra-tinyerp)]

Bharat,

You have made proper fix as per comment 4.
I made some points on your merge proposal kindly check and fix it.

Thanks,
Mustafa

[qdp (OpenERP) (qdp)]

the conversion of those fields into fields.related has landed in trunk in revision 5366.

Thanks

[Flamion Alain (alain-flamion)]

I got this error in recording purchase invoices (journal id 3) after recording manual opening entries with journal id 9.
When validating purchase invoice there is a mismatch between line journal id (9) and move journal id (3).
There was no problem in recording purchase invoices before the manuals entries on journal id 9 which seems to be good validated.
From where does this journal id 9 come from ?
In function create (account-move) the vals contains the good journal id (3) but the constraints fails.