Wrong sum amounts in general ledger

[Pieter J. Kersten (EduSense BV)]

When printing a general ledger filtered on period and date, the details filter correctly, but the summed amounts include entries beyond the selection period. This makes the sum different from the printed details.

Proof:
Create two invoices, one in period 1, 2nd in period 2.
Create bank statement, set period to period 1 and import both invoices. Set payment date/booking date somewhere in period 2.
Print general ledger and filter on period 1 only -> includes invoice from period 2
Print general ledger and filter on period 1 and date < period 2 -> does not show invoice 2, but includes it in totals.

[Vinay Rana (OpenERP) (vra-openerp)]

hello,

i cannot reproduce this bug.
can you provide me more information with report pdf so i will get more.

Thanks.

[Pieter J. Kersten (EduSense BV) (pieterj)]

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
>

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Pieter J. Kersten,

How is possible to print the GL report in 2 separate fiscal year together.you have to first close the old fiscal year trasfer the entry into new fiscal year and then print the GL report of latest fiscal year. or you can comparing 2 fiscal years with the help of account_balance module.and in report wizard at any one time you can pass any one fiscal year.

Hope this will help you.

Thanks.

[Pieter J. Kersten (EduSense BV) (pieterj)]

Hi vra,

You clearly misunderstand me.

I *am* printing one single fiscal year. Please also note that - although
it seems possible to print multiple fiscal years - I clearly described
printing *one* fiscal year. Stronger put: I've taken every possible
measure given to me by OpenERP to limit the GL to one single period in
one single fiscal year.

The problem is - it includes items from another fiscal year due to
misplacement. I did *not* select those and they do *not* belong there.
OpenERP did not expect those either - the sums in the totals do not
match the details.

I do not know how to make things clearer. I hope this sheds enough light
for you.
--
Pieter J. Kersten

Op dinsdag 13-10-2009 om 07:03 uur [tijdzone +0000], schreef vra
(openerp):

> Hello Pieter J. Kersten,
>
> How is possible to print the GL report in 2 separate fiscal year
> together.you have to first close the old fiscal year trasfer the entry
> into new fiscal year and then print the GL report of latest fiscal year.
> or you can comparing 2 fiscal years with the help of account_balance
> module.and in report wizard at any one time you can pass any one fiscal
> year.
>
>
> Hope this will help you.
>
> Thanks.
>

[Vinay Rana (OpenERP) (vra-openerp)]

hello,

can you attached your output pdf of report?
so it is easy to check because in my side its works fine.

thanks.

[Pieter J. Kersten (EduSense BV) (pieterj)]

Hi vra,

The PDF's contain no more relevant information for the bug than what I
already provided in the textual descriptions. The actual data in it is
sensitive and not for publication. What you see is a list of posts in an
account, prefixed with the sum of those posts in the selected accounting
period, where for each selection, the totals stay the same, but the
details differ.

Did you follow the sequence I described to reproduce the problem?

I think there are two problems, one on the surface which is quick to
fix, one under the surface which is harder to fix:

1. The access path for the totals is different than that of the details,
meaning that filtering *has* effect on the details, but has *no* effect
on the totals given the described situation. Fixing this will repair the
report, but not what caused it.

2. account_period is not an attribute of account_bank_statement and
should not be shown to the user when encoding bank statements as if it
were. This is what caused the misplacement in the first place - encoding
a payment for an invoice in one accounting period and fiscal year in
another, previous, accounting period and fiscal year. That should not be
possible. Allowing it creates an invalid situation. Instead, the
transactions on the statement should be either placed in the same
accounting period as the imported invoices/payments, and/or manual
selectable by the user per transaction. This is more difficult to fix,
as it reflects a design problem in OpenERP's handling of denormalization
issues.

Hope this helps.

Op dinsdag 13-10-2009 om 10:09 uur [tijdzone +0000], schreef vra
(openerp):

> hello,
>
> can you attached your output pdf of report?
> so it is easy to check because in my side its works fine.
>
> thanks.
>

[Ruud Riem-Vis (ruud-riem-vis)]

I can confirm this bug and propose to reproduce it is follows:

1) create an empty chart of accounts
2) create an invoice for a product with a price of 100 dated on 05/01/2010
3) create another invoice for the same product with a price of 200 dated on 06/02/2010
4) create the general ledger from "Financial Management->Legal Statements->Generic Reports->General Ledger" and select Display accounts "with movements" and select the filter "By date" and then select the dates from 01/01/2010 to 01/02/2010.

You will see that the sum in the account corresponding to the sales account of the product will show 300 even though the time period includes only the first product. The selected entries below the sum are correct.
If you select the time period from 01/02/2010 till 01/03/2010, you will see the same sum again with the correct entries in the selected time period.

In fact, it seems that the account sums are computed independent on the selected time period.

[Numérigraphe (numerigraphe)]

Based on comment #7, I'm marking this bug "confirmed" so Launchpad won't drop it.

[Dukai Gábor (gdukai)]

Our accountant confirms this bug.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello ,

We would like to have an opinion from you for this fix.

Patch is attached herewith.

Thanks.