A test on an exported FEC led to ‘column errors’. Inspecting the file by hand, some lines were broken by newlines (\n). These new lines come from invoice references (mostly supplier) entered with a trailing newline.
I think it occurs when users copy-paste refeerences from pdf docs.
Would it be possible to trim (suppress spaces, tabs and newlines) in invoice references before saving?
It would be even better if existing invoices could be cleaned to remove these trailing invisible characters that breaks FEC.
Should I open a bug for this?
There is a proposal for Issue 7914: Trim char/text field - Tryton issue tracker
But any way, I think it is good that CSV writer would remove \n char like we already do with the delimiter.
but what if the date fields being exported by csv need the ‘\n’ because they are multiline?
CSV is not meant to be printed but is a simple interchange format.
These special characters at worst should be escaped, but not stripped, IMHO.
…
escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
How did you test? Is it an official test?
In all generality you’re right but the FEC norm prevent this.
I guess @ced is only talking about the FEC exportation and not the generic CSV export tool of Tryton.
Well, I guess I must agree, the FEC seems to imply (at least flat non structured ‘xml’ file version) that
the CR and/or LF is the record terminator with no mention of escaping…
This is indeed a problem in that we have lots of moves having multiline descriptions (namely coming from bank statements).
Will try as well and dig into this…
My acoutant simply said ‘your file import failed’; I tested with https://app.masterfec.fr/ (don’t have a Windows machine to use the official https://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec).
The XML version uses xs:string which seems to imply
The string data type can contain characters, line feeds, carriage returns, and tab characters.
I do not understand why you are talking about XML, the topic is about the CSV FEC.
Because theoretically that gets over the problem encountered.
No the problem is on the CSV FEC format.
For me, the point I 1° implies that no carriage return is allowed in the field value because indeed there is no reference to the CSV format so there is no escape char.
So I filled Issue 9451: Remove carriage return in FEC fields - Tryton issue tracker
1 Like