Usage of EDI specifications
When two trading partners agree to send each other electronic documents. And they begin to describe 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 create an EDI usage specification.
EDI Specifications
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. And we even remove the unused elements and encoded values within the segments we will use. At this point, we have created an EDI Usage Specification. We can also add to the specification by including values that we need, like designating the 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. First, it is the source of information for us to set-up our integration for our EDI document exchange. And Second it is the format that we validate our EDI documents with to determine a valid transaction.
EDI Usage Specifications can be a source of data and integration documentation. This can become extremely valuable when the choices and information about how your EDI interface works is recorded into the notes of the Usage Specification.
Beyond a visual validation of looking at the EDI file and comparing it with the specification, many times a specification can be found in the form of an SEF file. The SEF file can be used in an EDI validation application. This allows a potentially large and unwieldy EDI file to be scanned for compliance and accuracy.
There may be other uses, but these are the main two, integration data repository, tool for EDI validation.
EDI Specification Examples:
To walk through how a usage specification works, and is used, check out this review of BookNet Canada’s specification.
Then you can take a look at the EDI specifications published by Macy’sNet that they keep online to assist their trading partners in making and keeping effective integrations.
Sometimes we only use the EDI specification, they way we have always used them. It can be instructive to browse the usage specifications of other companies. We see what they remove, what they include, what comments they make, and what rules they document. And seeing how others do things can help us to be more effective in how we use EDI specification documents.
