EDI.Net
EDI.Net copied to clipboard
indice-co
Flat files translation
Hi guys,
Is there a way to translate flat files like VDA or ACH with the following structure:
101 191001234 9922222261210151518A094101Certification Bank-SiliCERTIFICATION BANK-SILIRETURNS ....
What would be the best way to develop a POCO that fits the goal? Any considerations for mapping (i.e., ACH to XML/JSON, etc.)?
Thanks!
I need more input in order to assist here. This is a question better suited for stackoverflow IMHO.
On seccond read I would say no it is not supported. EDI.Net needs at least the basic principles of one of the basic grammars to be there (segments/elements/components and delimiters).
There is another great lib that has your back check out the CsvHelper
CsvHelper may not be a good fit since it has nothing to do with EDI. These standards (like ACH or VDA) belong to EDI, but comparing to EDIFACT, for instance, these are simply flat-files. Still, if I would develop the login to handle that sort of translation, where I'd start? Is this a new 'grammar' implementation for the purpose?
I will look into this. I am not familiar with the ACH-NACHA format standard. Your question got me to look around and I found this spec file here: NACHA_format.pdf and here NACHA_File_Layout_Guide.pdf
I don't know if it is official but if this is the case then it seems fairly easy to create something to handle the case. I am not sure if I would not go though the standard EdiTextWriter though because it is fairly complex and differs in nature.
If you have any official documentation regarding this please share.
@cleftheris, I have a spec that is not so much different. However, it clearly shows how to parse the file. The concept of 'envelope' is the same as many other standards in the EDI world (i.e., header, line items, trailer/control numbers). The difference is in the predefined positioning of the elements and the absence of so-called 'separators'. In the NACHA_format.pdf you referenced, page 4 clearly describes the parsing on the first line (header), similar to what I posted in my original message. Seems like the 'parsing' is not that difficult. The question is - how do we achieve that by leveraging your framework? I just want to make sure we're doing changes in the right places.