EDI: An Overview
EDI stands for Electronic Data Interchange. Many EDI guys and girls try to present it as a rocket science, and it seems like it is at the first glance. If I show you an EDI document, you will probably see incomprehensible syntax (gibberish). But there is a pattern that underlies the syntax and, in this article, we will look into that.
I began looking into EDI to explore the options that can enhance the current implementation and automation of electronic data interchange in THG. EDI is a method of data transformation following some protocols. Usually, EDI is used to tackle B2B processes to minimise time and human error e.g., it can automate the process of issuing purchasing orders, delivery dates, returns and invoicing between THG and many suppliers. Let’s look into a scenario to validate what I have just written.
Suppose there is a guy called Toby at THG whose responsibility is to buy beauty products from suppliers for our retail businesses. Toby forecasts our requirements and orders products to meet forecasted demand. Suppose Toby’s model recommends ordering 1000 lipsticks from a supplier on Tuesday to be delivered for a weekend promotion. In a manual world, Toby would generate a purchase order and email it to the supplier. If Toby mistakenly ordered 100 rather than 1000, he might not catch his error until the supplier confirmed the order, again manually by email, quite possibly after the supplier has begun processing the order.
But hang on, Toby wanted to order 1000 lipsticks, but he mistakenly ordered 100. So, what now?
Now, the only thing Toby can do is to attempt to amend the order or place another order for the 900 missing lipsticks. The new order will join the supplier’s queue again and another confirmation notice will be issued by the supplier. 900 lipsticks are potentially delayed before an important promotion. The manual process of sending, queuing and receiving the order is responsible for wastage of time and resources. The above scenario is just one of many that impact the overall business. Human error cannot be eliminated; errors can be made from our side or from the side of supplier and that is where EDI shines.
Now, let’s look at the same scenario using EDI. Toby used our internal purchasing system, approved the items and quantities, and submitted the order electronically to the supplier. In a few seconds, the EDI implementation on the other side checked the availability of the item and sent the confirmation from the supplier with delivery slot. If there was a mistake in quantity, Toby could fix it straightaway by amending the order and the supplier’s system can acknowledge the change straight away. The EDI system from the supplier’s end will send an acknowledgment of the change in order (using the 997 acknowledgment call back of EDI).
Consider this automated process in context of more than 1500 suppliers THG is dealing with and the difference in time, efficiency and resource management is huge.
In order to transform THG’s internal system representations of purchase orders, shipping notifications, invoices and the like to EDI messages a counter-party can understand, we need an entity called an EDI translator. Therefore, with n number of suppliers, we need n number of translators if every one of them uses a different message format. Before discussing the tiring task of writing these translators, let’s inspect the components and standards of EDI.
The two most popular standard to implement an EDI system in the world of e-commerce are ANSI X12 and EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce and Transport). Other standards are directed to other domains e.g., health records etc. In this article we will cover ANSI X12. From now on, I will address ANSI X12 as X12.
In X12, there are three segments that make the outline of an EDI document. These segments are ISA, GS and ST.
ISA:
ISA always consists of 106 characters precisely e.g.,
ISA*00* *00* *12*senderid. *ZZ*receiverid. *100429*1113*U*00501*000000001*0*T*>~
In the above ISA syntax, each entity enclosed by ** represents one ISA parameter. Therefore, ISA will always have sixteen parts consisted of 106 characters overall. They are referred as ISA01-ISA16. Let’s have a look at what each part represents. The above line is the first line of every EDI document written using X12.
ISA01 is 00 means no authorisation information available. If a document has to be verified by someone, that 00 will be replaced by some other code. ISA01 takes 2 characters.
ISA02 takes 10 characters and it is blank in our case as ISA02 represents the entity that authorise the document. As our ISA01 is 00 therefore, we do not need authorisation.
ISA03 and ISA04 are used for security information. ISA03 is again 00 in this case, so we do not have anything to fill at ISA04. ISA03 takes two characters and ISA04 takes 10 characters.
ISA05 and ISA07 represents the sender’s and receiver’s information. 05 and 07 are identifiers whereas, 06 and 08 are the values e.g., ISA05 has value 12 in the above example, where 12 means telephone number. ISA06 will have the actual telephone number. ISA05 can be a fax number or any other mechanism or identifier that is identified by both sender and receiver (X12 defines identifiers for fax, telephone etc.). Same goes for the ISA07 and 08 but a sender will be replaced by a receiver. One thing to note is that ISA has to be precisely 106 characters long therefore, you have to compensate the empty places with spaces. ISA05 and 07 take two characters and ISA06 and 08 take 10 characters each.
ISA09 is the date of creation of the document. In the above example it is 29/04/10. It takes 6 characters.
ISA10 is time of creation and in the above example it is 13:11. It takes four characters.
ISA11s U represents that it is a X12 document. That is all we need to know.
ISA12 represents control version e.g., in the above example it is 00501 (zeroes on the left to full 5 characters spaces). It acknowledges something, and we will know in a minute what it acknowledges
ISA13 is a nine-character control number and it is used to verify the end of the document.
ISA14 is always zero unless you are dealing with health-related records.
ISA15 can be T or P and these characters represent testing or production.
ISA16 is called element separator and it is denoted by >
Now, if we add all these characters from ISA01 to ISA16, we will get 2+10+2+10+2+15+2+15+6+4+1+5+9+1+1+1=86 but an ISA is supposed to be 106 characters, right? Let’s do the math.
The word ISA takes 3 characters and asterisk takes 16 characters. Overall, 86+3+16= 105 and do not forget the ~ (represents end of line) that makes it 106. Finally, it is not gibberish text anymore is it?
GS:
GS represents the group level and it shows the actual department within a company e.g., it can be an EDI document generated by sales department or by supply chain department etc.
Unlike ISA, GS does not consist of a fixed number of characters and hence no white spaces are needed to fill the characters. It can be as compact as you want it to be. It ranges from GS01 to GS08 whereas, GS01 represents type of document (e.g., X12 defines PO for purchasing order and SH for shipping notice), GS02 shows sender id code, GS03 represents receiver id code, GS04 represents date, GS05 shows time, GS06 represents the GS control number, GS07 is always X to show X12 and GS08 is release version of the document e.g.,
GS*PO*senderid*receiverid*20190329*1213*24700*X*004030~
Map the above information on the given GS and you will know what each entity represents.
ST:
ST is the actual body of the document e.g.,
ST*850*1135~
850 shows that this is a purchasing order. There is a whole list of numbers that define different categories of documents. ST02 is the control number which is 1135 in the above example. One EDI document can have many STs but only one ISA and GS.
So, overall an EDI document consists of ISA-GS-ST. ISA is like a mail box, GS is like an envelope to post and ST is the actual document to post.
The. ISA-GS-ST segments need to be closed by their trailers knows as SE-GE-IEA (acknowledgment). In order to verify a document, the values of SE-GE-IEA should be the same as assigned to the control numbers of ISA-GS-ST. The ST section contains more categories of X12 to write down entities like per unit price, VAT, import duty etc. If you are interested, you can explore the composition of ST to compose your first EDI document.
The bodies of STs vary from company to company e.g., THG may have different composition of ST than Mac and Revlon. Many companies also define customised categories of documents with customised ST numbers, therefore THG needs EDI translators that can translate our EDI implementation to the notation of suppliers EDI notation. It is of course a tedious task and that is why VAN (value added network) based companies that provide EDI as a service charge millions of pounds (not an exaggerated amount) per year to their users. These companies provide translation between different EDI systems and also offer APIs to integrate the EDI with pre-built in-house services.
One common way to balance between time and cost of translator implementations is to provide a web portal for smaller counter-parties to use. Bigger suppliers already have their own EDI systems and THG needs EDI translators to integrate/automate the supply chain/purchasing with them. The VAN based companies usually charge per supplier therefore, we can reduce the overall cost by going forward with this hybrid approach. At the moment, THG uses XML to deal with information that is related to suppliers and purchases however, in order to automate and enhance the functionality, EDIFACT or X12 is an ideal option to write EDI translators for better integration and automation with bigger suppliers.
Let’s see what the future holds for e-commerce and EDI. The applications of EDI are not limited to supply chain automation, EDI is also used as a translator to migrate legacy data to a new architecture (perhaps a discussion for another time).
We’re recruiting
Find out about the exciting opportunities at THG here:
