EDI Standards Reference
I have sitting on my desk, a very expensive book published by the ASC that contain the guidelines for the X12 3010 EDI standard. I have rarely used them. The EDI standards tool that I have used the most and can highly recommend is EDISIM from Foresight. The last version that I used was version 5.0 and they are on version 6.8 as I write this post. But for a long time, Foresight has nailed the conceptualization of working with EDI standards.
One of the things that in invaluable is the ability to share your standard documentation both internally and externally. EDISIM is a tool that has allowed me to do that. They produce a very professional looking document for external consumption and the standard is exportable so that everyone using EDISIM can share the same standards file in a format called SEF.
Features of a Good Standards Reference
Navigate Standards (multiple versions, doctypes, segments, etc)
A Standards Reference needs to offer a navigation interface of some kind. You need to be able to see the versions, standards and document types. You will also want to drill in and view the reference outside of the document types, and browse the segments or data element definitions. But at the core, you need to be able to see a graphical representation of the standard, view the format and see the structure of how data will be represented in the EDI format and document.
Edit Standards
Just browsing the standard is not going to get the job done. You need to be able to make alteration so that you don’t just have the high level X12 standard, like the book on my desk, but can make a standard that is your usage specification. This means you will need to be able to do two operations on the standard.
First you will need to make changes to what elements and segments are displayed, and make changes to the encoded values that these elements support. Editing these structures will aid you when you use the standard to validate and check for compliance based on your usage specification, and when creating documents to share and publish.
Second you will be able to add some of your business rules documentation to clarify the default definition of the standard. This is especially useful if you need to pass some data that uses a mutually defined qualifier. This lets you define what the “mutually defined” value should be. This again helps when you publish and share your standard.
Export and Import (Read SEF)
All of the standards references that I have used had the ability to import and export a standard in an SEF file format. SEF or “Standard Exchange Format” is a file that holds the standard dictionary and format for EDI files. This is a nice way to not only transfer and store the standard your company uses so that everyone has a copy of the same usage implementation. But if no proprietary information is stored in the notes, it can be sent to trading partners out side of the company to aid in their integration efforts. Any other export and import is a bonus, but SEF is a requirement..
Print (export to doc or pdf, or printer)
In spite of all this paperlessness, some times we still need to print things out. Printing to a pdf or printing to paper is useful when sharing the standard and usage specification in a non-editable format so that others can view it, and make use of the information. So for managers, or clients, or other parties that only need a viewable format to follow, this feature is a must have.
Save as editable file (RTF or other.)
Ok, just like printing, sometimes companies want all of their documentation to look the same. To facilitate this, it is nice to be able to save the specification out to a rtf, or doc, and then add the company header, logo, watermark, etc. This allows you to take the standards reference and really own the edits and notes that you have added. For companies that have extensive documentation processes, this feature is a must have.
Other Good Reference Features
Validation
Validation is not a feature of an EDI standards reference, but it is a good tool that sometimes comes with them. Validation tools read and EDI file, and compare the contents with the standard. They should then identify all of the errors they can see and report on them.
In my experience validations may need to be run repeatedly as some errors in an EDI file will mask following errors. For instance, if the N1 segment is wrong, the validator may not be able to tell if all of the other lines in the N1 loop are valid. So when I validate an EDI file, I correct the errors seen on the first pass and re-validate. This has saved me from telling a trading partner to fix an issue, only to have to tell them about another issue later. After all, we do want our integrations to go quickly.
Test Data
Sometimes looking at the standard is just not enough to show us how things will look when formed into the document. Seeing sample data is essential, and one of the first things I request at the beginning of any integration project. A Standards Reference will sometimes have tools that will create a test data EDI file based on the standard. This can be useful if you are working with a new document type that you haven’t encountered before and need to see how the standard looks in the formed document.
Evaluation of Standards Reference Technologies
Is there a feature that I have missed? Please let me know. Also,what EDI standards reference tools have you used? What do you like or dislike about them? How about any non-EDI specific tools? Please let me know what you have used. I would like to compile a list of tools and run some comparisons of what is out there.
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
