Intro to EDI/X12/edifact

July 7, 2009 2:54 PM

EDI Programing. I need some help, getting stated in programing EDI/x12/EDIFACT/ect... I looking for good internet how to sources, books I may be-able to find at my local library, and information where I can find "free" edi tables [sources]. I'm also looking to wring my code in VB.net - will that be a problem or should I stick with C[x] - Thanks
posted by comasight to computers & internet (3 comments total)

I've had a little exposure to EDI/X12 stuff thanks to the ERCOT market (Texas electricity).

Your local library should be able to get you a copy of the ANSI standards (a $850 value, at least!) as a reference book... you'll also need to look at the specific APIs that your EDI user provides, because those will be implementation-specific. At least in the case of ERCOT, the messages are provided free, but the container part of the messaging wasn't provided, so you needed the ANSI spec in order to implement it.

It was a couple of years ago, and I didn't do much research, but I never found an open-source library for talking X12.

Can't help you on the choice of language... in theory they'll both do it, as they can both emit text. I'm not a Microsoft coder though, so I can't tell you which is better. Probably the one you already know ;)
posted by lowlife at 4:10 PM on July 7

Here are a few of the EDI/X12 bookmarks I had saved from my last job. Honestly none of this probably would have been enough to get me started in EDI from scratch, but it did help once the person I was replacing explained the basics.

- An X12 Technical Tutorial

- A list of some common EDI transaction types and acronyms

- Links to a lot of retail corporations' EDI specs (You can learn a lot by looking at actual specs, rather than the EDI standards, because the standards are super-complex in order to handle every possible scenario. Find specs for companies that trade EDI in your industry, and you'll avoid studying a TON of useless information.)

- The EDI-L Yahoo! Group - If you get on this email list, you will read lots of stuff that won't make sense at first. And then gradually it will start to sink in and make sense. Plus the people there seem to be really helpful if you ask a question politely and indicate that you've really made an effort to understand on your own first. On the other hand, questions that basically amount to "Do my job for me, please?" or "How can I pretend to understand EDI to get this job?" or "Crap, I pretended to understand EDI and got this job, and now I don't know what to do!!!" are definitely not tolerated well. (Also, search the archives of their messages for answers to specific questions before you chime in to ask them.) It's sort of like MeFi--lurk for a while until you get a feel for the culture, and hopefully you will find a helpful community and not make a jerk of yourself when you finally speak up.

These guys would probably also have some thoughts on what language you should be using, probably already in their archives. I always used a super-outdated software package called Mercator to translate EDI (it came with the job), but I gather that there are newer, better options. I don't remember hearing a lot about people writing code directly in VB or Cwhatever to handle EDI, but I'm sure it's being done.

- EDIFecs SpecBuilder - if you can get your employer to buy this software, I totally totally recommend it. I believe its usual purpose is to help you create specification documents for your clients to follow, but I found it to be invaluable in helping me learn and interpret the structure of EDI documents. You can tell it what transaction type a text file is, and it will open the file up and connect all the bits of EDI text to what part of the EDI specification they represent, and it will tell you what all the weird 2-letter codes mean. It's fantastic.
posted by vytae at 8:13 PM on July 7

I worked at a company that had to handle EDI transactions. I wasn't the coder who handled it, but from what I understand you don't want to do it yourself. Find a library that knows how to generate and parse the files, and you can get by with less super-detailed knowledge that you'd need to know if you were doing the files. Plus you get a vendor to bitch at when something goes wrong.

This app was written in VB.Net incidentally, and worked fine. If you find a library that works in C#, most likely it'll work in VB.Net as well, since it's all .Net.
posted by cschneid at 9:06 PM on July 7