Fog Creek Software
Discussion Board

X12 820 Parser

I have been handed a project to deal with the translation of an EDI file to a custom file layout (the tool we have doesn't work with out upgraded OS and invoices are backing up).

The file EDI file layout *looks* fairly simple ... I have done basic proof-of-concept parsing in both Java and Perl, but the hierarchy rules are very positional (unlike XML, say).

Does anyone have any suggestions for tools (free or $) for Java, Perl, etc. that would be quick to acquire and learn.  Or recommendations on a better forum for asking this question.

Wednesday, August 18, 2004

Perl is really-really good at using regular expressions.

It is also free ( for Windows), and implements the 'write-once, run-anywhere' approach really well.

Having said that, it provides a very nice language for parsing your input records, storing the data in a meaningful way, and producing your output records.  Shouldn't be more than a few 100 lines of code, if that much.

Since it is so simple, I don't think there is an off-the-shelf solution for this -- you could easily write it yourself.

Wednesday, August 18, 2004

Oh, the good old X12 820. However I would recommend to do it with the AC84 911 or AC13 991. Both are way better. Also you can try it with OO39 394 and AX123 234.

Wednesday, August 18, 2004

As ANSI documents go the 820 is very easy.  Rolling your own translator should not be bad, and I would just use whatever language you feel most comfortable with.

If you really want to use something prefab, the guys at do a lot of HIPAA stuff and probably have something for the 820.  I wouldn't bother, though.

I've written a couple of ANSI document parsers.  I don't claim to have the best practice approach, but they work.  Feel free to email me if you've got questions.  I check this address every couple of days.

Matt Conrad
Wednesday, August 18, 2004

Step 1: Get sample data from every trading partner. Refuse to do anything until you have this. Claim work stoppage, announce loudly at meetings you're stalled, send emails to VP's, whatever - GET DATA FROM EVERY PARTNER BEFORE STARTING.

Step 2: Make zero assumptions. Provide error cases for every possibility

Step 3: Get the ANSI X12 specs for the document. Read them. Compare the sample data from #1 to them. Be prepared to create program flows for every line in the implementation guides BUT look for lines that aren't used by your partners. Any line you can't find being used, document it. Once you have a full list, send that list to your manager for "I don't see these fields being used - do we need to implement them?" Get the answer in writing.

Step 4: Make sure your code can provide for the lines in step 3 when some partner starts using one of them the day after you deploy.

The hardest part about EDI is that the rules are observed mainly in the breach, and nobody makes partners follow the rules. I built my 810/850 parser as a class hierarchy, which ended up serving me VERY well - it was very modular, and changes like those in step 4 above turned out to be relatively straightforward.

Final note: make sure you know what versions the partners are using, too. :-)


Wednesday, August 18, 2004

Listen to Philo. No one follows the edi specs so make your code very flexible. No if/else chains to accomodate one partners unique layout. You'll end up with a mess. I would suggest a language like perl or python for speed of development and the continual changes that will occur.

Tom Vu
Wednesday, August 18, 2004

Welcome to hell. Everything Philo mentioned is pure molten golden advice.

I'll add: are you the hub or out on a spoke? I think you are probably a spoke (standards taker) who should demand implementation detail from the hub before doing anything else - don't rely on reading the ANSI or EDIFACT standards, you won't win any arguments. Do it their way.

If you are the hub, cover every case and mandate your standard without mercy.

Document mapping requires exceptional negotiation and documentation skills, so half your code will be in English ;)  As for the coding, I would suggest awk or nawk, but Perl trumps that.

Wednesday, August 18, 2004

Philo's dead on with his advice.  I've written several complete systems and I got killed every time I deviated from the plan he outlined.

Since you're comfortable with Java, that's what I would recommend.  Perl I mostly recommend you get from oysters, but your experiences may be different.  I've had my best luck using C and C++, which leads me to believe that Java is going to be the best bet for you.

Something else to consider is your transport mechanism. Transport has traditionally been the single biggest point of failure. That might not be so crucial for invoices, but I was dealing with the 830, 862 and 856 documents, which are used for Just In Time supply chain management. A little communications glitch can really cause a lot of trouble. Don't rely on manual transport mechanisms though if timely delivery is important. Manual methods lead to one person bottlenecks. I've seen it happen, and it can do terrible things to a company.

Clay Dowling
Wednesday, August 18, 2004

Concur with Philo.

The X.12 standard is so "loose" that everyone interprets critical elements in their own, uhhh, unique, way.  You *will* end up writing custom code for each trading partner.

Probably a good time to bone-up on your O-O inheritance.
Or GoF "factory" patterns.
Or both.

Wednesday, August 18, 2004

*  Recent Topics

*  Fog Creek Home