Derived module to import bank statements#3
Conversation
This gives more flexibility with respect to the parameters that will be used by the actual methods. For instance, this allows the CSV policy for bank statements not to override the parse_one() method
|
Thanks @gracinet! The travis build is red because of a missing OpenERP dependency. These are handled manually in (see https://github.com/OCA/maintainer-quality-tools#sample-travis-configuration-file-for-version-70) |
connector_file_bank_statement needs account-bank-statement-reconcile
|
Done, hope it'll work ! Can you please show me the link to that Travis so that I can see for Thanks On 09/04/2014 01:50 PM, Leonardo Pistone wrote:
|
|
@gracinet it's directly on the pull request view, to the side of your commits. I see also a large comment-like box, but that's just because I have commit rights. thanks! |
|
neat, didn't notice, thanks ! |
It uses anybox.testing.openerp to load some XML configuration file (the quickest way for me to produce it) and it detected that I forgot to set bank_statement_id on imported chunks.
Forgotten files that should have been with f946854
There was a problem hiding this comment.
Shouldn't this be only on 'done'? If your import failed for a bad configuration of backend like wrong user, you cannot restart it.
|
I tested it and it works 👍 |
3 participants
This module provides a new backend version, that in turns leverages the account_statement_base_import module.
Each chunk becomes a bank statement. Some flexibility is provided through the dedicated configuration fields on the backend model.
For instance, one can decide to cut in chunks of at most 50 lines having a single date, storing that date as the statement's date.
One can also decide to base the statement's name on lines labels if lots of line share the same label (can have special functional meaning). Not leaving the default name is good for concurrency (no sequence involved).