Eliminate trailing delimiters.
When EDI was first created, modems were much slower, and high speed internet and Wi-Fi didn’t exist. Moving large, verbose files over a network took time, and e-commerce solutions charged by the kilo-character. This means that having unneeded characters cost money.
EDI, in good form tries to eliminate extra characters.
The rule is to keep your segments as compact as possible by eliminating optional trailing data elements.
Choosing Effective Delimiters
It is illegal to have a delimiter as part of the data in any data field. There is no escape character that will allow it. That being said, many systems will allow EDI that breaks this rule to be formed, as it does not harm the system sending the message.
However, it becomes impossible for the receiver to read the message properly. (I know that some of you have encountered and scripted solutions for this type of thing, but this is about good form, not work-a-rounds for bad form.) If you are lucky, this violation only errors out of translation. If you are not so lucky, the translation succeeds and you have corrupt data in your system.
The rule is to select delimiters that will never appear in your output data.
Avoid Unnecessary Repetition
Some segments can be found in multiple locations in an EDI document. This allows for a flexible and context sensitive usage of segments and data.
Lets take the N1 segment and group for example. In a shipping notice you can use the N1 in the header section before any of the line items, but you can also use it in the line level. This gives you power to specify specific shipping locations for the line.
This is great if each line is going to a different locations, but if most of the time this means that the N1 group repeats the same information over and over, then we are wasting space and are not in good form. It would be best if we place as much information where it will only be displayed once if it is the same. And in our shipping example, we can specify that N1 only appears in the line if and when there is an overriding shipping locations. (this is where having effective usage specs comes in handy.)
The rule is to avoid repitiion of any data that can be represented in a non-repeating structure.
Remove Excess White Space
Just like any other character spaces take up room in the file. Outside of the ISA segment, no EDI fields should contain leading or trailing white space.
The rule is to trim or remove any whites space in an EDI field.
Send EDI in Wrapped form
When EDI is wrapped it looks like one continuous line of text characters. When EDI is unwrapped each line appears on its own line. Normally people do this by inserting carriage returns and line feeds after each segment delimiter. Humans have an easier time reading an unwrapped EDI files. So in most of the examples of EDI that I use here are unwrapped EDI.
Wrapped and unwrapped EDI are both EDI and most parsers don’t have a problem with either one. But line feeds and carriage returns are characters and take up space. And because in good form EDI eliminates excess characters, these should be eliminated as well.
The rule is, always transmit wrapped EDI.
Some people try to have the best of both worlds and try to use a line feed as a segment delimiters. This is a bad idea. First, delimiters are supposed to be a single character, second, different operation systems treat these characters differently. And some systems pre process files and remove carriage returns and line feeds. Basically, its not a nice way to do it and will eventually cause someone trouble.
What all these rules have in common?
What all of these rules have in common is saving space. Creating EDI that uses extra or unnecessary characters is bad form.
| < Prev | Next > |
|---|