Import Statement Files

accounting

(Cédric Krier) #21

What is the format you are talking about?


(Cédric Krier) #22

I think also that each format will have a set of values that could help the user to create the statement lines. Like the account number, communication, reference etc.
As those values will depend of the format and even inside the same format the statement could have different kind of information, I think we should just store them in a Dict field and each parser will create the keys he may need.


(Sergi Almacellas Abellana) #23

It’s the CSB43 file format, used for spanish banks. Here is a document describing it. It’s in spanish as I wasn’t able to found an english version.


(Sergi Almacellas Abellana) #24

Is this really required? Or it’s better to each module to add it’s own fields?


(Cédric Krier) #25

I have implemented it and it is very nice design I think.
It prevent to create dozen of column on the origin table because I guess an average installation may have about 2 or 3 different import format. For the CODA, I have already more than 10 field because I want the user has the maximum information when encoding the statement line.
Also it is nice feature that if you do not put a key, no value is shown so it is like having a invisible state setup by default.

I looks very similar to CODA.


(Sergi Almacellas Abellana) #26