EDI GAP Analysis

The dictionary meaning of Gap is the difference, in the context of EDI the Gap analysis is generally referred to the gap between Retailer’s business requirement and the available EDI guideline. If you search on the net then you will get lot many documentation in this line. But to me, it’s a bit different. I like to share my thoughts with you .

I worked on an US project (Easylink’s EDI platform migration) where we had to create the FMD (mapping instructions and rules) for different customers on a standardized application template. The application template and mapping template was maintained by the VAN and used for various retailers to meet their web EDI requirement. The application layout was not so flexible and dynamic hence we have to find the gap between the retailers EDI requirement and the capability of handling the same by the Van’s support system. Firstly we had to study the document wise EDI guidelines to understand the EDI requirement of the retailer. There can be certain specific information which the Retailer wants to pass on to vendors but we found no scope of mapping in the VAN’s application layout. We have to see if the requirement is mandatory on Retailer’s part then it was a “Show stopper’. Otherwise it was our responsibility to find a way out how to accommodate in the existing application framework with help of coding or tweaking the backend Progress application setup. At times it was found that many identifiers were not considered in the backend codes whereas the Retailers need them to transmit. Under such circumstances, we had to see if there are some unused qualifiers in the backend which can be replaced with the required qualifiers so that without much change in back end coding and configuration set up, the problem can be arrested.
The GAP analysis was performed for various major functional areas of VAN’s requirement for catering the Retailer concerned as also the corresponding Vendors. The major functional areas are listed below:

1 Summary : This is for providing the relevant details of the Retailer concerned. Sometimes we found that some mandatory information is not present in EDI guideline and some other relevant data is missing. There can be lot many other gaps for fulfilling the requirement of VAN.

2 Registrations : When a vendor wants to be associated with a particular Retailer then he has to go by the Retailer’s requirement. The requirement details are agreed upon between the parties in paper documents when they enter into a contract. But when there can be gaps between the VAN ‘s web layout and the Retailer’s requirement. Hence it becomes necessary to analyze and rectify these gaps.

3 Application Layouts : These are the web lay outs for various business documents (850,856,810,820 etc) where user posts in the data against required labels. For inbound transaction there would be only one form but for outbound docs there would be two separate forms, one input form and other is confirmation form. The available forms were generated from the standard master template but to accommodate Retailer’s requirement, we had to add, modify and also delete some of them. We had also to consider proper sequencing and displaying of objects. So that gaps between Retailer’s requirement and web display can be minimized.

4 Mapping instruction and Rules : Based on the mapping instruction the map developer does the coding , the translator translates with the provided test data and the database is populated. From the database the front end display is being generated. This is the process in a nut shell by which the EDI web display is happened. In the retailers’ guideline there can be lot many conditions, rules to be followed, many data fields have to be generated or displayed while there might be no such field in the database. But we have to fulfill the Retailer’s requirement to the extent possible. Although it was a tough call but met it. I am sighting an example to illustrate the scenario.

In the database, there was provision for storing 3 product identification numbers against one particular item. They were namely UP code, Retailer SKU # and Vendor’s Item #. The Retailer wanted to pass on another #, Catalogue ID. But there was no provision for Catalogue # in the database. We looked for an unused field where this sort of value can be stored and retrieved. Through the coding tweak we handled the situation and displayed the Catalogue # in at the desired location in the Web Display page. The relevant caption display was managed through modification in the back end Application setup through Progress Tool.

There were even more serious GAPs which we could not fix and referred to VAN’s Backend architects to fix. One example may be sighted. In the VAN’s template of 850 document there was provision for displaying only one type of Charges in the header section. But Wallmart wanted to pass three types of charges through the SAC segment in 850 X12. So this was a showstopper as transmitted data was required back by the Retailer in the 810 (Invoice X12). VAN did change the database structure, flat file layout, display application layout to accommodate multiple charges and after that we modified coding instruction and our Test Plan.
I worked for some of the leading retailing chains like Walmart, Walgreen, BB&B, Costco, Bloomingdales, AAFES and many more and also got the appreciation note from Easylink.
I dedicate this success to all my team members, namely, Anirban Dutta, Maitrayee Biswas, Chinmoy Chakroboty and Sumanta Banerjee without whom the success remained unfelt.