[6.1/Trunk/7.0] wrong date in import invoices in bank statements

[Gunther L.]

When invoices imported in bank statements the transaction date of the
generated journal line is incorrect. The date is not the date from the bank
statement. The effective date from the invoice is choosen.

Steps to reproduce:
Create a invoice with date 2013-01-01 in period 2013/01.

The customer pay the invoice on 2013-02-01 via bank. Now we have to
create a bank statement on 2013-02-01 in period 2013/02. Click on
'import invoices' and import the invoice. Now confirm the bank statement
and you will see following error:

ValidateError

Error occurred while validating the field(s) date: The date of your Journal Entry is not in the defined period! You should change the date or remove this constraint from the journal

Now go to journals and disable 'Check Date in Period' in bank journal and the
bank statement can be confirmed. Click on Journal items and you can see
the wrong date 2013-01-01 in the journal item.

[Carlos Liebana (carlos-liebana)]

We can confirm that this also happens in v6.1

[Niels Huylebroeck (red15)]

This was originally fixed in v6.0 on rev 5380
http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/revision/5380

It says there that this was a backport from 6.1 but I cannot find that mentioned revision id at all.

If my memory is correct we originally reported this issue.

Mind you this solution is not complete as the voucher itself is still using the date from the imported invoice!

[Rifakat Husen (OpenERP) (rha-openerp)]

I think here is the rev of 6.1 where we fixed it,
http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/revision/6966

[Rifakat Husen (OpenERP) (rha-openerp)]

Hi Niels,
voucher itself used the date of bank statement line which we fixed for 6.0 and 6.1 long way back,
http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/revision/5136
http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/revision/6966

These fixes where not forward ported to 7.0 and trunk so we need to do that only.
Thanks.

[Rifakat Husen (OpenERP) (rha-openerp)]

Here is the fix for 7.0 also,
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-592393-opw-skh

Thanks.

[Niels Huylebroeck (red15)]

So the fix for making sure the voucher creates account moves on the correct date is by changing the code in the voucher object to use the statement line date instead of the date on the voucher.

I admit that would work, but what about manual vouchers ? Those that are not part of a bank statement ? You still create the account moves on the date listed on the voucher itself. Why this double standard why not simply make sure that importing invoices on a bank statement creates a voucher that will match the date of the statement line ?

I'm not agreeing with the proposed solution because it leaves a voucher behind with a date that does not match the date the actual moves are being created on (unless this voucher was part of a bank statement).

[Rifakat Husen (OpenERP) (rha-openerp)]

A manual voucher created on the statement line shall have default date from
statement line itself, there is already passed default context value, 'default_date': date
This has already been taken care, don't you think?

Please let me know if I have understood it wrong.

[Niels Huylebroeck (red15)]

You are correct but you are still asssuming vouchers are only being used from the bank statement, vouchers can also be completely manually be entered outside of the bank statement view.

Also I'm not sure but I think the default_date context value will not be saved when creating a voucher from a statement, since both you (and me) are overriding the date set on the created statement line ( account_statement_from_invoice.py:122 )

We should perhaps replace this with :
"date": context.get('default_date', statement.date)

But I would also adjust it on the date written to the voucher then (as already suggested in my branch)

[Niels Huylebroeck (red15)]

I'm having a 'duh' moment here, the importing of the invoices does NOT have the context['default_date'] value since we are not editing a statement line but creating one!

[Rifakat Husen (OpenERP) (rha-openerp)]

Hello Niels,

I have tested all the scenarios in v6.1, there are 3 possibility for payment voucher,
1. automatic voucher creation via import invoice
2. manually voucher creation while creating statement line manually
3. First create voucher manually outside the bank statement and then assign it to
    statement line(only possible with 6.0 and 6.1, not possible with 7.0)

point 1,
I checked your fix, that will solve statement line date problem while we import any invoice and also
create voucher with statement's date. In 6.1, it voucher date is taken from line's and line from statement
date so ultimately it's same. Your fix looks fine.

Note that statement line's date is always taken from bank statement. By import invoice, line date is taken from
statement date and while manual line creation, date is taken from context into _defaults.

point 2,
When create voucher manually, it's date is fetch from context 'default_date' passed on voucher_id. so as soon as
we fix line date in point 1, this will solve problem for voucher date.

point 3,
When creating voucher outside of statement and the date is different than the statement's, in this case shouldn't
the date of voucher be updated with statement/line's date? or it should keep that voucher's date and generate
accounting entries as per voucher date?

What happens currently in 6.1, when creating voucher from outside with date different than statement's, it writes
statement's date on the voucher as soon as you confirm the statement, and creates payment entries as per statement's
date, in this case voucher date will be lost. Can payment voucher date and statement date be different?

>We should perhaps replace this with :
>"date": context.get('default_date', statement.date)
I don't think we need this, because both will always be same. 'default_date' takes line date and that also comes from
the statement itself.

Awaiting your response.

[Niels Huylebroeck (red15)]

Let me reiterate what is troubling on your suggested solution:

Whenever you import an invoice on the bank statement the voucher date is not set to the statement date (or the line date) but is instead still set to the date which was on invoice move. This creates confusion whenever a user is trying to correct the reconcilements from his bank statements by looking at all the draft vouchers (via the menu, not from the bank statement).

Your fix is overwriting the date of the voucher the moment you confirm the voucher, this is a blind leap of faith imo, the user can see the voucher's date is wrong and has to trust that OpenERP will correctly apply the date that was on the statement line ?

My solution makes it so the voucher's date is by default on the same date as the statement, this makes it easier to find the voucher when looking at them (while still draft).

I understand my solution does indeed not fix the problem where changing the statement line date should change (if present) the date on the voucher. It seems a simpler and cleaner solution to apply an on_change handler on the statement.line date field which would check if a voucher is present and change the date on that voucher to match the changed date (again only if the voucher is not confirmed obviously, otherwise we should raise an error and notify the user that he cannot change the date on a confirmed voucher)

I will see about adding an on_change handler on the statement line date field in my fix.

[Rifakat Husen (OpenERP) (rha-openerp)]

>This creates confusion whenever a user is trying to correct the reconcilements from his bank statements by looking at all the >draft vouchers (via the menu, not from the bank statement).
I agree. Your fix handles this.

>I understand my solution does indeed not fix the problem where changing the statement line date should change (if present) the >date on the voucher. It seems a simpler and cleaner solution to apply an on_change handler on the statement.
I think on_change solution for stable indeed good? I think this will be taken care by this,
http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/revision/5136#account_voucher/account_voucher.py

I know this is weird that changing the statement date will not immediately change voucher date, but ultimately it will while confirming statement. If we don't go for on_change solution then this will still be fine, what do you think?

Thanks for your clarification.

[Niels Huylebroeck (red15)]

Hi Rifakat,

I think we are indeed agreeing on the approach now, I understand that the code that writes the date on the voucher is good, but it should act as a safeguard and the on_change event should still be implemented to avoid user-confusion.

As you may have noted I have not yet had the time to implement the on_change handler, is there a chance you can do this and push it on the branch that we're trying to merge ? (The branch is openerp-community so you can push directly on there.)

[Rifakat Husen (OpenERP) (rha-openerp)]

Done! could you check?

[Niels Huylebroeck (red15)]

Looks good, I added the branch from Somesh which also added the (over)write when confirming the voucher (just to be on the safe side)

[Rifakat Husen (OpenERP) (rha-openerp)]

Thanks.

One of my colleague will commit fix for voucher date via import invoice in 6.0/6.1

[Amit Dodiya (OpenERP) (ado-openerp)]

Hello,

Following are the fixes for 6.0 and 6.1:
http://bazaar.launchpad.net/~openerp-dev/openobject-addons/6.0-opw-592430-ado/revision/5473
http://bazaar.launchpad.net/~openerp-dev/openobject-addons/6.1-592430-opw-ado/revision/7213

[Martin Trigaux (OpenERP) (mat-openerp)]

Hello guys,

I agree with you on the need for these changes. This was integrated in 6.1 and for some unknown reason not ported to 7.0.
This is now done.

However, as mentioned on the merge proposal below, the on_change use is problematic (should not make write calls edit mode). I believe it is not problematic to have a mismatch while the two are in draft. We are open to discuss this point though.
https://code.launchpad.net/~openerp-community/openobject-addons/fix-1127198-import-invoice-payment-date/+merge/163006

The 6.1 changes forward ported in 7 is merged at the following revision

revno: 9799 [merge]
revision-id: <email address hidden>

Thanks