Defining EDI Testing Requirements

Electronic data interchange EDI- testing has become a controversial subject. There are probably as many opinions about how it should be done as there are trading partners. Each organization has its own reasons, priorities, budgets, and internal agendas. And those factors drive their methodologies.

If you are a supplier and you ve implemented EDI with more than one trading partner then you have likely had a different testing experience each time. And while the testing methodologies may have been different, the results may have had little correlation to the way the testing was conducted. While that seems counter-intuitive, it bears consideration and an in-depth look at what makes testing different, and how the differences bear on the results. Even more importantly, how the testing and results relate to the overall successful implementation. Last week I asked for your views on EDI testing. I was particularly interested in what your experiences have been, what you ve found to be useful, and what has turned out to be less than successful. I did hear from a couple of experienced users who have asked for anonymity, and I have included their comments in this report. Both my sources agree that testing needs to be done because it is the only way to get applications and their respective data to connect and synchronize properly. The methods used and assistance they received along the way turned out to be their biggest points of contention and comment. If we don t test with real data we are wasting our time. Even so, when we test with the broader set of data that covers every possible data element the trading partner may use with any of their trading partners, we end up with less than real world scenarios. This EDI Manager for an international manufacturer has had experience working with several 3rd party EDI providers. He adds that the testing he objects to includes not only every data element possible in every transaction the trading partner may make, but that the test data is not specific to the trading relationship. He comments further, The 3rd party company composes a document that covers every possibility for their client company. Then they use that same document for every trading partner, meaning it can t possibly be specific to any. Interesting Concept/Bad Practice In concept, creating a single document that can be used as a standard for multiple trading partners sounds like a good idea. The rationale goes like this: If a single document can be tested against the customer s system the hub-, half the testing is already resolved. And if that single document includes all the options possible for all the customer s trading partners, those partners can be successfully tested using that single document. Unfortunately that simplistic view rarely turns out to be reality. As one EDI professional commented, I don t use, keep, or even care about every data element in the transaction. We only need some specific data, and pull it from different areas, then interpret it as necessary to fit our needs. My preference would be to talk directly with the trading partner and ask them to send a test for our specific business relationship. What I ask for can make it hard for them because it means they would have to create something that pertains specifically to our business. In reality, if I wanted to I could simply reply to their test with a simple acknowledgement, and they would think we ve passed the test successfully. When sending documents back to the customer, the reverse situation holds true. One person comments that he is guilty of the same practice he endures when receiving the test documents. When I send documents back to the customer to confirm our test, I send our generic format. It usually has more content than they ask for, and so it s up to them to parse what they want. But that isn t the end of the process. He continues, The hub then usually wants us to customize our outbound documents to fit their own needs. That means tailoring documents for each trading partner, which is very labor intensive. The problem is the same for both the customer and the supplier, and stems from the reality that every trading relationship is different. Each relationship needs to be reflected in its trading documents, and every trading relationship is different in some way. According to another EDI professional, The customization of trading documents has been a stumbling block, and will continue to be a sore point because we will not customize our outbound documents for each relationship. And, we don t expect our trading partners to customize theirs either. Successful Connections This seemingly enormous disconnect between trading partners needs would seem to be a natural opening for 3rd party EDI enablement companies to assist with the process. One EDI professional commented that while he still isn t entirely satisfied with the level of assistance he gets from any of the 3rd party companies, at least one company has made some improvements that have helped the process. It used to be much worse than it is now to deal with the 3rd party providers because we would get a different technical contact at the company for each document type P.O., invoice, ASN, etc.-. That meant that his staff had to restart the conversation and describe their needs each time they began testing a document. It was very frustrating and time consuming. But now that we have a single point of contact for our testing with one of the companies, we get testing done more quickly. But even with a single technical contact, this person believes the process is slowed by having an intermediate company, and would prefer to work directly with his trading partners. Eventually I end up talking directly with the technical people at our trading partner s company to finalize the exchanges. He has found several of his trading partners don t want to work with him directly, and refer him to the 3rd party intermediary. It s part of their agreement with their provider, and I m sure it lightens the trading partner s load by having them deal with the majority of any new trading partners. However, even when we have successfully tested our transfers with the 3rd party and received certification that our transactions are valid, we end up working out the final details directly with our trading partners. Making a Difference When it comes to defining the types of testing, the documents to be tested, and the contents of the documents, there seems to be no consistency. As one source put it, The definition of the tests should be a two-way proposition. I have difficulty when one party is trying to call all the shots. I think that generally the 3rd party providers have tried to define the testing methods. I asked if either of my sources thought it would be possible or advisable to bypass the testing phase. One of them said, It would be a dangerous practice. I m very old-school about testing software and data exchange. The other said, It would be a mistake because on the first day of production you will find issues you never would have thought of, and they will only serve to delay your project. When it came to evaluating the differences between implementations, they responded, We continually work with the same three or four 3rd party enablers. Each has different practices. But we eventually get connected with all our trading partners. And, I prefer to work directly with our trading partners on each connection because I ve found that working through the intermediary generally delays the process. Paying for Testing Services Regardless of the number of trading partner connections, the number of documents, the type of testing, or the time required to validate successful transactions, testing is work. That work is paid for either by the trading partners as time spent by their employees or by charges from a 3rd party enabler. Source: line56.coma>