Studying EDI Guideline

EDI guideline for a particular Retailer is prepared by an EDI analyst after analyzing the Business process flow and the specific requirement of the customer concerned. The analyst has to finalise the required Business Documents flow, Standards, Versions etc to facilitate successful EDI data transmission.

Who is required to understand the Retailers’ EDI guideline ?

Frankly speaking, for a map developer it is not mandatory to understand the intricacy of EDI guideline, but I suggest they should also study this for better understanding of the customer’s EDI requirement. So far the EDI Gap Analyst and tester is concerned, understanding of EDI guideline is must as they have to create the Field Mapping Document (FMD) considering the Application Layout and the EDI guideline. A tester is required to create multiple test data for a particular Inbound map to test multiple scenario as mentioned in the FMD. Hence it is of utter importance to understand the requirements mentioned in EDI guideline for creation of Test data and actual testing against the approved Test Plan.

What to look for in the Retailers’ EDI guideline ?

We have to look for the special features in the Guideline which will be used for application set up, development, test plan creation and testing.

A few important points are noted below :

1. Doc ID, Standard and version : it may so happen that for various docs, the Retailer might use different versions. So while generating outbound X12 we have to keep this point in our mind.

2. Segments and elements used : We have to see the segments used and the elements as it becomes important while mapping from FMD. It would become useful while preparing multiple Test data with various combinations. The other most important aspect is, while the vendor will send the outbound X12 we have to see whether required data is being carried over from the inbound X12 as desired by the Retailer. The Header and Detail level segment looping is another important aspect to be studied carefully.

3. Purpose of segment and its element : Its of utter importance to understand the purpose of each segment. The developers have a knack just to map but if they understand a bit more then unit testing becomes easier and meaningful. There are a few segments which carry almost same type of data but for different purpose with different qualifiers. We need to understand all these things.

4. Sender and Receiver ID in ISA segment : Depending on flag passed in ISA15 (P/T) the Receiver ID will get changed. We have to pass the correct IDs in ISA06 and ISA08 in the in bound X12 otherwise while translation an error will be thrown. The ISA segment should be constructed in such a way that it would match with the backend setup. Some Retailers will tell about different IDs to be used for Test or Production mode while some might not say anything, in that case we have to ask the Retailers about the IDs.

5. Sender and Receiver ID in GS segment : In general, I have seen that Sender and Receiver IDs as passed through ISA segment match with the GS Sender and Receiver IDs. But if it differs, it would be mentioned in the guideline. Again the backend should be set up accordingly.

6. Segment Usage factor : So far EDI standards are concerned, depending on the message type, generically some segments are Mandatory and some are optional. But for a particular Retailer, amongst optional segments a few may be mandatory. This can be found from the EDI guideline only.

7. Segment loop structure and Minimum/ maximum occurrence of segments : From the bare X12 test data its not possible for us to understand the parent child tree structure of various segments. That’s why we have to take help of EDI guideline where all these things are explicitly described.

8. Syntax and Symantic Note : EDI syntax note is nothing but rule for various elements in a segment. In other words, it’s the dependency rule for contained elements. For example, if N103 is present then N104 is required. If this rule is flouted then while translation, an error will be thrown. Under Syntax rule, mandatory and optional elements falls. Under the Syntax data type and max/min length is also covered. Symantic notes are basically retailer specific. By this note it can be clearly understood that which data element should contain what type of information against a particular qualifier.

9. Acceptable Identifiers for a particular Retailer : ANSI X12 and Edifact standards are teeming with a whole lot of Identifiers. The required identifiers for a particular element of a segment are spelt out in the EDI guideline. We must understand the meaning of each identifier and the purpose thereof. A sample is given below.

10. Explanations provided by the Retailer under a particular element : Many times it is found that the Retailer explains in brief about the significance of the content. We have to understand them clearly and follow accordingly. I am sighting an example below :


PO101 350 Assigned Identification O 1 AN 1/20 This element will be present for *designated trading partners* to indicate an item level purchase order assigned ID number. Assigned ID values may be different for each line item and should be referenced and returned on the 810 invoice in the IT101. When present in conjunction with a BEG01 value of 22 (information only), the PO101 is to be used for logistical information ONLY.
(Contact Food Lion Procurement for clarification of *designated partners.)