Over the years as EDI consultants, we have done modifications to many maps-ones we created and ones created by others. We have seen a great variety of maps, from well thought out and well constructed to “what were
they thinking!” Once an EDI map is written, tested, and in production it should run with no errors that were caused by the map. (Please do not get me started on errors
caused by incorrect or missing data from the ERP system!) So why have we spent so much time “fixing” maps that are in production and have been running fine for a long time? All of the examples below are emergency
situations, which always seems to occur when there is a big rush order.
Maps made of Straw: The prime thing we see in these maps is that the original author of the map hard coded data that should have been retrieved from the database. Sure, you only sell to one department of a company today so why bother trying to find out where that data is on the database? And if it is not stored on the database, why be the squeaky wheel who insists that the data should be a field on the invoice file?
Maps made of Wood: Another “fix” we have done many times is to add segments for discounts and allowances. Again, the map had been working and now it does not cross-foot. What is happening in reality here is changes in business processes – these maps didn’t suddenly “break.” But Management does not see it that way. Another issue is 3rd party testing. Management has had to pay extra to go through testing the EDI documents for a new customer. They expect the maps to work perfectly as soon as that testing is done. It is hard to explain that testing with “Widgets” (rather than real items), is not the same as testing with real data. In other words, this 3rd party testing is not truly testing the maps, it is really only testing the connection. Unless you have built this post-testing phase into your budget, you will have issues defending the additional time it takes to get a map running smoothly.
Maps made of Brick: These are the maps where the map author took the time to hard code as little as possible, did a careful review of the mapping specifications to ensure all segments are coded properly and tested for as many situations as possible. Granted, you cannot anticipate every situation and you cannot guarantee that your trading partners will adhere to their own standards, but focus on what you can control and take the time to integrate the map as closely as you can to your ERP system. This will result in a map that has a solid foundation, and will avoid some of these pitfalls described above.
Get started with EDI: Speak to an expert
