It should be reworked to work with #5882 (closed).
I'm wondering if account_sepa_message is really still needed as normally the wizard to import statement should never failed.
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.
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.
Cédric Krieradded 1 deleted label and removed 1 deleted label
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
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.
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?
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.
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 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.