Issue 4658
- Title
- CAMT053 SEPA Statement module
- Priority
- feature
- Status
- resolved
- Nosy list
- ced, edbo, nicoe, ohuisman, reviewbot, risto3, roundup-bot
- Assigned to
- ced
- Keywords
- review
Created on 2015-03-19.16:04:24 by nicoe, last changed 1 week ago by roundup-bot.
Messages
New changeset 4932ad9cd590 by Cédric Krier in branch 'default': Add account_statment_sepa module https://hg.tryton.org/tryton-env/rev/4932ad9cd590
New changeset 88ebc8344dda by Cédric Krier in branch 'default': Add account_statment_sepa module https://hg.tryton.org/readthedocs/rev/88ebc8344dda
New changeset 31d963d802f8 by Cédric Krier in branch 'default': Add account_statment_sepa module https://hg.tryton.org/modules/account_statement_sepa/rev/31d963d802f8
On 2022-07-18 13:44, edbo wrote: > On Mon, 2022-07-18 at 12:40 +0200, Cédric Krier wrote: > > > > Cédric Krier <cedric.krier@b2ck.com> added the comment: > > > > On 2022-07-18 12:08, edbo wrote: > > > > > * the dates of the statements are the all the date of the import, I > > > > > would have expected this would be the date of the statement not the day > > > > > of the export / import > > > > > > > The format provides only a creation date for each statement. There is also > > > > a period but this is not a unique date like Tryton's statement is > > > > expecting. > > > > > > There are lots of different dates indeed, each with their own code. > > > > I do not known which ones you are talking about? > > I see several `<Bal>` tags in a statement which have different `<Cd>` like > `PRCD, OPBD, CLBD, CLAV` etc. And those have different dates. No idea what they > mean. Those are dates of the balances included in the statement. They will just define a duration so it is not the date of publication of the statement. > > > > > - It doesn't matter which CAMT importer I choose, it will always import > > > > > the CAMT.053 exported from the bank. > > > > > > > I do not see any problem. > > > > > > Me neither, but it's a bit weird to select a CAMT.053 and import it as > > > CAMT.052. Maybe just merge those selections into one? > > > > I do not see the point to put constraint, just to tell user he makes > > mistake without consequences. > > But if there are no consequences, why not add one option like `CAMT.052 / 053 / > 054` instead of three? That was basically my question. This way it is possible to customize the behavior per type.
On Mon, 2022-07-18 at 12:40 +0200, Cédric Krier wrote: > > Cédric Krier <cedric.krier@b2ck.com> added the comment: > > On 2022-07-18 12:08, edbo wrote: > > > > * the dates of the statements are the all the date of the import, I > > > > would have expected this would be the date of the statement not the day > > > > of the export / import > > > > > The format provides only a creation date for each statement. There is also > > > a period but this is not a unique date like Tryton's statement is > > > expecting. > > > > There are lots of different dates indeed, each with their own code. > > I do not known which ones you are talking about? I see several `<Bal>` tags in a statement which have different `<Cd>` like `PRCD, OPBD, CLBD, CLAV` etc. And those have different dates. No idea what they mean. > > > A possibility can be to check the dates of the lines and if they are all the > > same use that date. I don't know how many users benefit from this. > > That seems to be just adhoc hack. It is. > > > > > - It doesn't matter which CAMT importer I choose, it will always import > > > > the CAMT.053 exported from the bank. > > > > > I do not see any problem. > > > > Me neither, but it's a bit weird to select a CAMT.053 and import it as > > CAMT.052. Maybe just merge those selections into one? > > I do not see the point to put constraint, just to tell user he makes > mistake without consequences. But if there are no consequences, why not add one option like `CAMT.052 / 053 / 054` instead of three? That was basically my question.
On 2022-07-18 12:08, edbo wrote: > >> * the dates of the statements are the all the date of the import, I would have expected this would be the date of the statement not the day of the export / import > > > The format provides only a creation date for each statement. There is also a period but this is not a unique date like Tryton's statement is expecting. > > There are lots of different dates indeed, each with their own code. I do not known which ones you are talking about? > A possibility can be to check the dates of the lines and if they are all the same use that date. I don't know how many users benefit from this. That seems to be just adhoc hack. > >>- It doesn't matter which CAMT importer I choose, it will always import the CAMT.053 exported from the bank. > > > I do not see any problem. > > Me neither, but it's a bit weird to select a CAMT.053 and import it as CAMT.052. Maybe just merge those selections into one? I do not see the point to put constraint, just to tell user he makes mistake without consequences.
- the dates of the statements are the all the date of the import, I would have expected this would be the date of the statement not the day of the export / import
The format provides only a creation date for each statement. There is also a period but this is not a unique date like Tryton's statement is expecting.
There are lots of different dates indeed, each with their own code. A possibility can be to check the dates of the lines and if they are all the same use that date. I don't know how many users benefit from this.
- It doesn't matter which CAMT importer I choose, it will always import the CAMT.053 exported from the bank.
I do not see any problem.
Me neither, but it's a bit weird to select a CAMT.053 and import it as CAMT.052. Maybe just merge those selections into one?
- statements are per day
This is up to your bank if it creates a statement per day or not.
- the dates of the statements are the all the date of the import, I would have expected this would be the date of the statement not the day of the export / import
The format provides only a creation date for each statement. There is also a period but this is not a unique date like Tryton's statement is expecting.
- empty statements are also added (can we leave them out?) and have to be manually deleted
I would have expected that bank would not generate a statement for this case but I can ignore statement without entries.
- It doesn't matter which CAMT importer I choose, it will always import the CAMT.053 exported from the bank.
I do not see any problem.
I've tested this on a 6.4 installation. I also don't know if my workflow is right for this import. I'm irregularly importing bank statements sometimes there are weeks in between sometimes even months because I don't have a huge business which needs importing statements that often.
The workflow I'm following is:
- Login at my banks website (Rabobank)
- Go to the export transactions part
- Select a date range (the bank does it automatically for me) from the last export until yesterday
- Download the transactions (in this case in CAMT.053) as a file
- Import the file into Tryton with the 'import bankstatements'
What I normally would expect are:
- one huge statement with all the lines
- statements per day with their lines and empty statements will not be imported (this is what I prefer)
With the CAMT import I noticed:
- statements are per day
- the dates of the statements are the all the date of the import, I would have expected this would be the date of the statement not the day of the export / import
- empty statements are also added (can we leave them out?) and have to be manually deleted
- It doesn't matter which CAMT importer I choose, it will always import the CAMT.053 exported from the bank. The Odoo version has a sort of version check https://github.com/OCA/bank-statement-import/blob/13.0/account_bank_statement_import_camt_oca/models/parser.py#L254
Those are my observations when using the module.
The review12011002 is ready for testing, it supports CAMT.052.001, CAMT.053.001 and CAMT.054.001. But CAMT.053.001 is indeed the recommended format because it is the direct counterpart of the Tryton's account statement.
I have not found anything special for CFONB.
team up to do both camt053 (what is started) as well as camt053.cfonb (if different) and cfonb at the same time (which is what I'd like to quickly finish). Otherwise, I'd be happy to provide the cfonb stuff I've already done with the supporting documents used. BTW: *tag-team* https://www.merriam-webster.com/dictionary/tag%20team (definition 2) sorry for the jargon
* richard [2019-02-02 14:30:41]: > Any way we can tag-team this forward? What do you meant by this?
It would be nice to see this advance a bit (reworked already?)... In particular, I'd like to use a portion to tack onto for recent CFONB 120 fixed format. I have a prototype cfonb parser already. Any way we can tag-team this forward?
It should be reworked to work with issue5882. I'm wondering if account_sepa_message is really still needed as normally the wizard to import statement should never failed.
Here is the review.
I have made the implementation of CAMT053 blueprint https://code.google.com/p/tryton/wiki/CAMT053
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-09-18 15:58:40 | roundup-bot | set | messages: + msg78215 |
| 2022-09-18 15:58:37 | roundup-bot | set | messages: + msg78214 |
| 2022-09-18 15:58:30 | roundup-bot | set | messages:
+ msg78213 nosy: + roundup-bot status: testing -> resolved |
| 2022-09-18 14:40:54 | reviewbot | set | messages: + msg78212 |
| 2022-08-26 18:42:21 | reviewbot | set | messages: + msg77808 |
| 2022-07-18 13:55:04 | ced | set | messages: + msg77421 |
| 2022-07-18 13:44:26 | edbo | set | messages: + msg77420 |
| 2022-07-18 12:40:08 | ced | set | messages: + msg77419 |
| 2022-07-18 12:08:35 | edbo | set | messages: + msg77418 |
| 2022-07-18 10:52:14 | reviewbot | set | messages: + msg77416 |
Showing 10 items. Show all history (warning: this could be VERY long)