When and When Not To Deviate From Standards
When two trading partners agree to send each other electronic documents. They begin by describing what EDI documents they will exchange and how the documents will flow. They should also exchange EDI specification documents. EDI usage or specification documents describe what fields and what segments a trading partner will send or expect to convey the information necessary to complete a transaction. It doesn’t matter if we are ordering widgets, or invoicing, or transmitting catalog data, or checking insurance claims eligibility, the EDI needs to contain the data that the two parties need to communicate. To explain this, and document it to that both trading partners know what is expected, we must create an EDI usage specification. Let's use the most popular term: Trading Partner Convention. There is no “law” that says what this like. It could a typed document or a “file” (which we will explain later).
So what is required? What is optional? Best description comes from EDI guru Harold DeWayne: “It's been my experience that (M)andatory is used to mean the X12 standards demand it (and therefore also commercial translators)... (R)equired has been used more by the trading partner to mean that WE REQUIRE it for our own use”
In the larger sense, the EDI specification is the set of rules that define each document type, the segments they contain, and the size and type of data in the elements. When we talk about the EDI Standard Specification, we are talking about the whole set of valid EDI document types. If something is valid EDI, then it complies with the EDI Standard Specification. However, this large, all encompassing specification is not useful in coordinating the exchange of documents between two trading partners.
What goes in an EDI Usage Specification?
So we take EDI Standard Specification and we reduce it. We remove the unused document types and the unused segments within the documents we will use. Then we remove the unused elements and encoded values within the segments we will use. At this point, we have created an EDI Usage Specification. (A “Trading Partner Convention”) We can also add to the specification by including values that we need, like designating an optional value or ID as required and specifying what type is should be.
How is an EDI specification Used?
Now that we have a usage specification we can use it to do to basic things: (1) source of information for us to set-up our integration for our EDI document exchange; (2) format that we validate our EDI documents with to determine a valid transaction; (3) source of data and integration documentation. This is important when the choices and information about how the EDI interface works is recorded into the notes of the Usage Specification.
As well as a visual representation, many specifications are available in the form of an SEF file which can be used in an EDI validation application. Now huge files can be interrogated for compliance and accuracy. SEF stand for Standards Exchange Format. Some applications use SEF files as part of their document creation and validation processes. Let's look at SEF files and what type of information they contain. It is really only at text file! It has “sections”: doc types, segments, elements, and encoded data. Could include version and name etc. SEF was created so that a computer application could understand an EDI file.
SEF is only useful if you are exchanging standards using the format. Your standard and usage could be in the form of a PDF or a spreadsheet.
Many implementation products exist that are helpful. After you have created your usage specification, it can be useful to use a validation tool to check to verify that new trading partners comply during your boarding process.
EDIdev has an SEF Manager
Yes, there are other ways too!
Remember though to Validate to Standard, not to spec