EDI Inspector

The Tediware EDI Inspector

X12 is designed to be compact, not legible. A purchase order starts with BEG*00*SA*TEDIPO0001**20260101 and getting anything out of that line means knowing that the first element is a transaction set purpose code where 00 means Original, that the second is a purchase order type where SA means Stand-alone Order, and that the last is a date in CCYYMMDD. That's no easy task!

The Inspector puts that knowledge into the document. It rewrites the interchange one segment per line, names every segment and every element, and spells out what each coded value means, so FOB*PP reads as Shipment Method of Payment, Prepaid (by Seller).

It then checks the document against the X12 release its sender declared in GS08. Every finding carries the line it belongs to, so a violation points at the segment that caused it.

What the validator checks

The checks run against the base X12 reference for the sender's release, the same data behind the X12 reference pages.

• Element lengths, minimum and maximum. Digits only for numeric types, since a minus sign and a decimal point do not count toward an X12 length.
• Data types. A numeric element has to be digits with an optional leading minus, a decimal has to parse as one, a DT element has to be a real calendar date in CCYYMMDD or YYMMDD, and a TM element has to be a valid time in HHMM, with seconds optional.
• Code lists. An ID element's value has to appear in the code list the standard defines for it. Where the reference holds no codes for an element, its values pass rather than all of them failing.
• Mandatory content. Required segments, elements, composite components and loops, each reported against the container it is missing from.
• Repeat limits. A segment or a loop appearing more times than its position allows.
• Syntax rules. The paired, conditional, exclusive, required and list-conditional notes attached to a segment, named by rule and by the elements involved.
• Segments the parser rejected, with the reason it rejected them.

What it checks beyond the standard

A schema check can only speak about segments that reached the parse, so two further passes cover what it cannot see.

The framing pass compares the decoded document against the text it came from and reports where the two stop describing the same file: the point the parser stopped reading, data left sitting after the interchange trailer, elements dropped because a segment carried more than the standard defines, and an ISA whose fixed element widths are wrong. These are the faults that let a truncated file look clean, because the part that never parsed produces nothing to check.

The envelope pass holds the document to its own claims. Every ISA, GS and ST has to be closed by its trailer, each trailer's control number has to match its header's, and the counts the trailers carry have to be the counts actually present: segments in SE01, transaction sets in GE01, functional groups in IEA01. The Envelopes section of the developer guide covers what those numbers are for.

Inspect from the terminal

The same inspection runs in a shell with the tedi CLI, which reads files on your own machine and builds no browser tree, so it takes documents up to 256KB:

tedi edi inspect invoice.edi     # decode and validate a document
tedi edi obfuscate invoice.edi   # replace personal data, runs locally

inspect prints the decoded document and its findings, and takes --format markdown for uncolored output you can pipe or redirect. obfuscate replaces the personal data in a document without leaving your machine, so a file can be cleaned before it goes anywhere.

Limits

Signed-out limits are counted per IP address, so an office behind one address shares them. Your document is sent to our server to be inspected, and it is not stored.

Related

To turn a document into JSON, use the EDI Translator. The developer guide covers X12 structure and how inbound and outbound processing work, and Anatomy of the Segment explains the data structure the Inspector decodes.