“To be, or not to be, that is the question.” This well known quote from Shakespeare’s Hamlet has intrigued scholars as well as theater connoisseurs since it was first spoken in the early 15th century.. While I can’t claim that EDI mapping causes one to question one’s own existence as Hamlet did (although at times it can be the cause of you questioning your sanity), there are definite parallels. In this case, managing a bank of EDI translation maps equivalent could be more like “One to one, or one to many, now THAT is the question.”Answering this question is an important piece of your EDI program as the path chosen has major implications in risk, cost, and the potentially the reputation of the entire company.
First is the paradigm that utilizes one map for each transaction. In this environment, each document type has its own map regardless of number of partners a company trades with. Each partner that is on-boarded, regardless of required specs, is forced into the existing map. While it does offer one central file name and location for backup and maintenance of the map, this method can be very dangerous for two reasons. One is that if that file gets accidentally deleted, corrupted, or is not backed up properly, the results are a catastrophic impact to the entire EDI community. Secondly, with this scenario comes the complexity of massive amounts of conditional logic within the map. One missed condition could spell disaster for every partner that receives that particular document.
The second method is a more lenient version of the one to all. In this case, during the on-boarding process the EDI analyst attempts to find an existing map that will require a minimal amount of conditional logic, and if that cannot be found then a new map created. Since there will likely be several maps spread across the trading partner community, the risk of error or map can be reduced, depending on the number of trading partners one map supports. I have found this to be a happy medium when a company is outsourcing their mapping function as it will greatly reduce the cost behind mapping, since editing an existing map is usually cheaper than creating a new one.
The last philosophy is the one to one model. In this case, each trading partner has their own set of translation maps, and when a new trading partner is added, they get their own set of maps separate from any other partner. In a SasS environment, utilizing one to one could be cost aversive, but as a whole it is the method that I personally prefer over the others. First, if a trading partner requires a change, fighting through spaghetti code to ensure other trading partners will not be affected is not an issue. Second, if an issue arises with the map, one to one minimizes exposure to other partners. While it may be require more server space, as well as more robust file handling routine, once implemented offers the cleanest, safest method of managing your map set.