Duplicate statement detection can misfire using multiple accounts with same parser.

Bug #801107 reported by Stefan Rijnhart (Opener)
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Account Banking Framework
Confirmed
Medium
Unassigned

Bug Description

Hi,

we have two different bank accounts with the same characteristic name and date pattern, as bank statements are made available at regular intervals. This triggers duplicate detection, as it only takes statement name and date into account. Of course, statements for two different accounts are never duplicates.

As each bank account should have their own journal ("ideally", says the OpenERP documentation: http://doc.openerp.com/v6.0/book/3/3_7/accounting_entries.html), taking the journal into account when detecting duplicate statements should solve the problem.

Cheers,
Stefan.

Revision history for this message
Pieter J. Kersten (EduSense BV) (pieterj) wrote :

Lets see if I got you right. To rephrase this problem and fix in my own words:

You have two bank accounts for which you use the same import parser and thus share the same statement numbering generator. When searching for processed statements with the current search parameters, there is no way of telling which statement belongs to which account, which can lead to wrong duplicate identification and thus wrongly skipped statements.

You suggest that adding a journal_id to the search parameters should make that distinction, based on OpenERP's advisory to use a unique journal for each owned bank account, and assuming that every OpenERP user will follow this advise.

Is this correct?

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote : Re: [Bug 801107] Re: Duplicate statement detection should take journal into account

On 23-06-11 13:58, Pieter J. Kersten (EduSense BV) wrote:
> Lets see if I got you right. To rephrase this problem and fix in my own
> words:
>
> You have two bank accounts for which you use the same import parser and
> thus share the same statement numbering generator. When searching for
> processed statements with the current search parameters, there is no way
> of telling which statement belongs to which account, which can lead to
> wrong duplicate identification and thus wrongly skipped statements.
> You suggest that adding a journal_id to the search parameters should
> make that distinction, based on OpenERP's advisory to use a unique
> journal for each owned bank account, and assuming that every OpenERP
> user will follow this advise.
>
> Is this correct?
>

Yes. I would like to add that it is my impression that having a single
journal for each bank account is more a best practice in bookkeeping
than just a suggestion in the OpenERP documentation, although
technically not necessary.

Cheers,
Stefan.

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail: <email address hidden>
tel: +31 (0) 614478606
web: http://therp.nl

Revision history for this message
Pieter J. Kersten (EduSense BV) (pieterj) wrote : Re: Duplicate statement detection should take journal into account

That may be, but there are valid reasons to use multiple journals per bank account. So I wouldn't count on it.

I suggest to increase the traceability instead of assuming manual conformity. Statements already have a link to the imported file, so by adding a link to the settings when creating an import file, one could check the bank account itself, which seems a much cleaner approach to me. One could even generate warnings about different import parsers used beforehand.

If you can wait, I'll fix this in a week or two. Otherwise, you can try it yourself and propose a fix here.

Thanks for reporting.

Changed in account-banking:
status: New → Confirmed
importance: Undecided → Medium
summary: - Duplicate statement detection should take journal into account
+ Duplicate statement detection can misfire using multiple accounts with
+ same parser.
Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

Sounds good to me, thanks!

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

Other bug subscribers

Remote bug watches

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