Tediware
Sign In
All updates

The EDI Inspector: decode a document and check it against the standard

Adrian Duyzer

Adrian Duyzer

feature edi

Here is a real 990 (Response to a Load Tender) from a carrier, with one thing broken in it on purpose:

ISA*00*          *00*          *02*TSVL           *14*006922827DPS1  *240425*1637*U*00401*000003286*0*P*>~GS*GF*TSVL*006922827DPS1*20240425*163757*000003286*X*004010~ST*990*000003286~B1*TSVL*79567092*20240425*Q~N9*CN*TISOFA12259~SE*4*000003286~GE*1*000003286~IEA*1*000003286~

If you can find the problem in that block of text without looking anything up, you have been doing this for a very long time.

The way most people go about finding errors in EDI documents is to use a tool that does exactly that. Until now, Tediware didn’t have one built in. I’ve changed that with a web-based Inspector at tediware.com/tools/inspector.

It’s much the same as other web-based inspection tools, but I’ve taken it a step farther and given you access to this tool via the command line, which is something no other tool provides.

What it does with that 990

First it puts one segment on each line:

ISA*00*          *00*          *02*TSVL           *14*006922827DPS1  *240425*1637*U*00401*000003286*0*P*>~
GS*GF*TSVL*006922827DPS1*20240425*163757*000003286*X*004010~
ST*990*000003286~
B1*TSVL*79567092*20240425*Q~
N9*CN*TISOFA12259~
SE*4*000003286~
GE*1*000003286~
IEA*1*000003286~

Then it annotates every segment and every element with its name from the standard, and where an element is a coded value, it decodes the code too. The B1 on line 4 is decoded like this, but of course, in a more designed fashion than this block of text:

B1  Beginning Segment for Booking or Pick-up/Delivery
  01      Standard Carrier Alpha Code       TSVL
  02      Shipment Identification Number    79567092
  03      Date                              20240425
  04      Reservation Action Code           Q

And then it validates the whole thing against the X12 standard for the release in the envelope, which in this case is 004010, and reports that line 4, B1-04, Q is not a code.

In the browser the findings sit in a bar above the panes, and clicking one scrolls the source pane to line 4, so you can find the issue easily. Every finding carries the line it came from, because the formatted text and the parsed tree are produced from the same parse and stay in the same order, so the Nth segment of the tree is always the Nth line of the text.

What the validator checks

It reads the X12 reference data, so what it knows is what ASC X12 published for that release:

  • Element and component lengths, against the minimum and maximum for that element. Numeric types count digits only, so a minus sign and a decimal point don’t push a value over the limit.
  • Element types: N values must be digits (a leading minus is allowed), R must be a decimal number, DT must be a real calendar date in CCYYMMDD or YYMMDD, TM must be a real time in HHMM with optional seconds. 20240230 is caught, since February didn’t have a 30th.
  • ID values against the element’s code list. That is the check that got our Q. If the dictionary has no codes loaded for an element, the check is skipped rather than reporting everything as wrong.
  • Mandatory segments, elements, and components that were not sent, including the first segment of a mandatory loop, which is reported against the container that should have held it.
  • Repeat caps on both segments and loops, anchored at the first occurrence over the limit.
  • Segment syntax notes, all five condition types: required, paired, conditional, excluded, and list conditional. If you send N9-06 without N9-05, the C0605 rule fires.
  • Segments the parser rejected outright, with the parser’s own reason.

A transaction set that isn’t in the reference data for that release comes back as a notice saying it was skipped, rather than silently passing.

The envelope is displayed too, in full. ISA and GS get decoded the same as everything else, so ISA-05 reads 02 (SCAC (Standard Carrier Alpha Code)) and GS-01 reads GF (Response to a Load Tender (990)) instead of you looking up the I-series element definitions for the fifteenth time this year.

The same thing from the terminal

The Inspector is also a CLI command, which is extremely handy when you are working with EDI files on your local machine:

tedi edi inspect invoice.edi

That posts the document to POST /api/edi/inspect and prints the result. I’d show you an example, but it’s cool enough that you really need to try it yourself. It’s free!

There is also tedi edi obfuscate, which replaces personal data in a file and runs entirely on your machine. If you want to inspect something that has real names and addresses in it, obfuscate it first and inspect the result.

Try it at tediware.com/tools/inspector, or install the CLI from tediware.com/resources/cli and run tedi edi inspect on something that’s been giving you trouble. If it reports something you think is wrong, or misses something it should have caught, email me at adrian@tediware.com and send me the document, obfuscated is fine.