BooknetCanada: Real Life Standards and Usage Spec
From time to time I am asked if I know where such and such standard can be found. This is more than idle curiosity. People are trying to integrate, or update integrations, and the standard documentation is not available or has been lost. From the perspective of an integration engineer, such standards are more precious than gold. I keep a collection of the standards that I have used over the years, (something that I recommend) but what I really encourage is for companies to publish their standards in a publicly accessible location. Booknet Canada is an example of a company that has done this. Lets take a look and see what it says….
Here is the standard, if you want to look at what they have published. I will crop out a few pieces to talk about. You might want to look over the full published standard.
ISA
The ISA segment contains some essential information that your trading partners will need. Integrations of EDI rest on accurate trading partner values in the ISA values. Sometimes even trading partners with existing connections will need to verify the ISA information and trading partner IDs. For new trading partners, having this information available makes it possible for proactive partners to get a jump on integrations.
One thing of note here is their use of a sample segment to illustrate what the ISA segment will look like. This can be very useful especially when dealing with trading partners that lack EDI experience. Also useful when dealing with unusual segments or difficult to describe structures.
However, there is one caution. I once had a trading partner hard code all of the sample segments into their map. Thus we had an N1 with their ID and other information, and then an N1 with the same qualifiers but with the sample data from our specification. This caused some problems for both of us. Admittedly this only happened the once, but I was careful after that. In any case, be sure that your examples are clearly marked as such to avoid repeating this mistake.
BIG
Every document has a beginning segment that is specific to that document type. This segment will hold specific information that relates to that document type.
There are two things of note here. First, is that they have listed the “not used” segments in their specification. I don’t always to this myself but it can be done, and in this case illustrates one of the aspects of EDI good form practices. In the example segment they have none of the trailing elements that are not used, but they do have the one filed that is not used, but comes before a used element. Thus illustrating the “no trailing delimiters” best practices rule.
The Second thing of note is their use of “Notes” to leave indication of a precedence rule in their mapping. You can see here that they have a rule that uses the BIG_04 as the purchase order number only when there is no superseding PO number on the IT1 segment. This type of notation is really helpful to trading partners and others in your own company down the road when problems happened and people need to discover what went wrong.
N1
N1 segments and N1 groups are important segments and can contain valuable data. N1 segments are found in every EDI document that I have dealt with.
You’ll notice that there are three N1 segments listed in this Standards Document. We know that the N1 can repeat, but this is not the way that is indicated. This is one of the ways that the Standards Specification and the Usage Specification differ. In the Standard, we talk about what may happen, or what may occur. But in the Usage Specification, we talk about what should happen or what will occur.
All of the looping or repeating segment values have not been shown in this document. The looping of the IT1 and N1 still happen, but the looping is not pertinent to the Usage Specification here. (at least to BookNet) They have also included a short list of the acceptable code qualifiers to be used in the N1_03. And you will note that they have defined them so that trading partners won’t have to look them up, or guess, and have indicated their preference.
Standards
Crafting a Standard and Usage Specification can make a real difference in the ease of boarding trading partners. It can make future trouble shooting easier for your, and for others both at your company, and at the trading partner’s. And it can illustrate the look and feel of EDI to less EDI sophisticated individuals.
Now that you have looked over the BookNet specification, is there anything that you think they should have changed to add clarity? Or are there any thing that you have learned that you want to add to your own Usage Specification documentation?
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
