search

indice-co / EDI.Net

EDI Serializer/Deserializer. Supports EDIFact, X12 and TRADACOMS formats
MIT License
434 stars 164 forks source link

Flat files translation #178

Open command0r opened 3 years ago

command0r commented 3 years ago

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!

command0r commented 3 years ago

I'd appreciate your input, guys.

cleftheris commented 3 years ago

I need more input in order to assist here. This is a question better suited for stackoverflow IMHO.

cleftheris commented 3 years ago

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

command0r commented 3 years ago

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?

cleftheris commented 3 years ago

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.

command0r commented 3 years ago

@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.