On 2022-07-18 13:44, edbo wrote: > On Mon, 2022-07-18 at 12:40 +0200, Cédric Krier wrote: > > > > Cédric Krier <firstname.lastname@example.org> 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.
|2022-07-18 13:55:04||ced||set||recipients: + nicoe, ohuisman, risto3, reviewbot, edbo|
|2022-07-18 13:55:04||ced||link||issue4658 messages|
Showing 10 items. Show all history (warning: this could be VERY long)