Comment 2 for bug 447915

Hi vra,

Thanks for the rapid response.

Ok, full situation:

1. Two fiscal year, 2008 and 2009
2. Periods in both, 3 months size
3. Invoice 1 is placed in period 4 in 2008, Invoice 2 in period 1 in
2009
4. Bank statement encoded with date in period 1 2009 and period set to
period 4 in 2008
5. General Ledger on 2008 with no extra filtering shows Invoice 2 and
includes it in totals (should have excluded invoice 2, so wrong, but
totals are correct)
6. General Ledger on 2008 with either filtering on period (period 1-4
2008) and/or filtering on period and date (01/01/2008-12/31/2009 and
period 1-4 2008) show the *same* totals as the GL in 5, but excludes
invoice 2, so double wrong.

Using the rest of OpenERP to investigate, it shows that the payment of
invoice 2 is placed in period 4 2008, while the invoice itself and the
payment date are both in period 1 2009, which is a invalid situation.

I'm running the 5.0.6 version of the server.

My first analysis drills down to what I now see as a fundamental flaw in
OpenERP's account module: the denormalized period attributes on several
objects shine through into the user interface.

Period is logically not an attribute of account_move_line, but of
account_move. The same applies to account_bank_statement, which - in
real life - has nothing to do with periods. account_invoice does. So
when you import an invoice into a bank statement, it should take the
period of the invoice into account. The denormalization of period for
both in order to support rapid reporting and processing, should not
touch the users behavior, let alone limit or even cripple functionality.

Explanation:
1. Entering bank statements can span multiple periods. This is even
quite common. As the bank statement in OpenERP account is a 1:1
visualisation of 'the real thing', it should support multiple periods.
If you use the period in the current form for encoding real life
multi-period statements, you end up with the mess described in this bug.

2. Once encoded, it is impossible to change the period in account_move,
because the software checks if the periods on all lines in the move are
identical. Although this is a valid check, doing it while correcting is
like interrupting a person before he/she can finish his/hers sentence,
which is plainly rude. This behavior makes it also impossible for the
user to correct the wrong assumptions of the software by hand.

Let me know if this provides enough information for you.
--
Pieter J. Kersten

Op maandag 12-10-2009 om 06:02 uur [tijdzone +0000], schreef vra
(openerp):

> hello,
>
> i cannot reproduce this bug.
> can you provide me more information with report pdf so i will get more.
>
>
> Thanks.
>
> ** Changed in: openobject-addons
> Status: New => Incomplete
>