If one searches the Internet for EDI service providers, almost every result will proclaim they have “Simplified EDI”. Yet customer testimonials boast of implementing a new EDI trading partner “in 6 weeks instead of 6 months”.

If all EDI service providers have simplified EDI, why isn’t EDI simple?

EDI still takes too long and costs too much because it is too complicated. Developers are still required for EDI mapping. The mere numbers of EDI service providers prove it is not simple, else they would not be needed. Simple technology does not require so many 3rd party providers as well as an army of developers.

We make the same claim; International Electronic Business III have simplified EDI. Our new process requires no developers and partners can be added in minutes. None the less, there are ways each company can simplify EDI unilaterally. Some changes would require cooperation from software developers. But we need no permission from the useless EDI standards bodies. As mentioned, we have just finished developing our new EDI solution. Anyone who develops EDI translation software will encounter and must overcome the same old problems. Most unnecessary.

Here are just three examples of ways we, who implement EDI, can simplify it without permission. There’s much more!

1) ANSI x12’s PO1 and IT1 segment’s pairs of Qualifier and Part Number.

Looking for the UPC, qualifier UA, we are supposed to map after this fashion:

  • If PO106 is ‘UA’ then PO107 is the UPC
  • Else if PO108 is ‘UA’ then PO109 is the UPC
  • Else if PO110 is ‘UA’ then PO111 is the UPC etc. etc. etc. etc. etc. etc. etc.

This is not just too much to code up in a map it is even too much to write. There are 10 of those statements needed for each part number mapped. I wager no one has ever mapped this correctly. I have not for any company I’ve worked for nor any client. Are you listening, ANSI x12? You broke your own models to give us this giant mess of pairs. EDIFACT did it right. There is a place for one qualifier and part number in the LIN segment. Additional part numbers go in the simple PIA repeating segment. The later solution is easy to map.

What everyone does, for the example above, is just map UPC to PO109, qualifier not checked. Proof of this is right there in the example. Between the UA and UD pairs is an empty pair from some part number no longer sent. Why not move the UD pair over one to the left? Because all maps would fail as they have the UD number in PO113 not PO111.

We resolved this specific problem at IEB3 in our Pattern Keys by defining the difference between qualifier and data. For the example above as “+1”. Our translator finds the ‘UA’ and gets the next field. This is simple EDI. Our processing will work no matter how you map your part numbers. Our Pattern Key processing would find the UPC no matter where it is in the segment and would work if each PO1 in a multiple item order had the part numbers in different places.

Unilateral Fix: We could all deploy the EDIFACT model in x12 by using only the 1st pair on PO1 and putting other part numbers in ref segments, mimicking EDIFACT’s PIA.

2) Multiple Transactions per Interchange and Transaction Groups.
Both x12 and EDIFACT were created back in the days of 300 bytes or characters per second data transfer speed, if one can call that speed. These days also gave us Y2K, where we skipped the century to save 2 bytes. Packing 20 invoices in one interchange saves 19 ISA segments or about 1900 bytes. As in Y2K, this is no longer needed. Transfer speeds are millions of bytes per second. I won’t even explain groups as in my 30+ years in EDI I have never seen them used. Listening standards bodies? This one is true of EDIFACT as well.

Translation software would be much simpler if we didn’t have to code for multiple transactions and group types. Unless you’ve done this it’s hard to appreciate how difficult it is. Processing these is also more complex and therefore has higher degree of risk.

Unilateral Fix: We could all start sending single transactions per Interchange. This simplifies processing the original transactions and immensely simplifies acknowledgements, both creating and reconciling them.

3) EDI Syntax Validation

“Trailing delimiters” are one of my favorites. For example;    PO4*24****~

These four asterisks just before the tilde segment terminator are called trailing delimiters because they trail any data and therefore are not needed. This transaction will fail in all EDI translation software I have ever known. This one is true of EDIFACT as well. IEB3 processing does not care about trailing delimiters and would never fail to book your order because of something so entirely insignificant.

If you receive a purchase order for a million dollars would you reject it for four insignificant delimiters? Ask your EDI team if that would happen in your company today! Simple question: do we reject transactions for trailing delimiters? If the answer is yes, your million dollar order will be automatically rejected.

ISA Version, however, is my all-time fav! In the example below this version is 00401.
ISA*00*          *00*          *ZZ*SAFEWAY        *ZZ*DEMOCLIENT1    *180817*2130*U*00401*000051793*0*T*^~

I have seen transactions rejected because this version number was 00501 instead of 00401. As I said, I have been in EDI for 30+ years yet I do not know any significance of 00501 vs. 00401. This is a version number just for the ISA segment itself, the whole transaction’s version in the GS segment. The ISA segment needed its own version because it’s so fragile. The delimiters and segment terminators needed to parse the transaction are foolishly defined at the end. Therefore, the ISA is the only positional segment in x12 and must retain spaces, so avoided back in the day! If you e-mail a transaction and it compresses the spaces as it sometimes does nothing works. EDIFACT does not have this issue as they wisely defined default delimiters that almost everyone uses. To override the defaults, one uses the UNA which is not positional or mandatory.

Because of all this the ISA segment has never changed, that I know of? Proof of this is right there in the example; the date (180817) does not contain the century. Remember the lunacy that planes would fall from the sky because of Y2K? The pressure of those Y2K days was indescribably immense, yet the ISA segment remained unchanged. Oh, the danger! Why? Because if the ISA changes, half century of installed EDI would fail. Same million-dollar question. Do you want to risk losing a million by rejecting an order for this insignificant version number?

Unilateral Fix: We could all turn off inbound validation. Outbound we’d need to keep on for those who have not yet turned off their inbound validation.

As far as what IEB3 has done to simplify EDI,
watch our 5-minute YouTube channel “Product Review”.