When implementing EDI Software

  July 17, 2012       By Ray Atia
There are a lot of layers to software where EDI is concerned. The software that bundles the applications sits at the top of the pyramid where all the software is located, and this is where the data is going to end up. In order for the data to reach there, the incoming data has to travel through a complex EDI communications network at the bottom of the pyramid. It has to go through the translation software of the EDI software platform base, and it has to go through the interface bundle too. The outgoing data has to go back down within the pyramid structure prior to its being sent out to trading partners. When your organization first implements EDI, you have to look into how your software applications will have an ability to work with the EDI data. You need to seriously evaluate the application for its ability to develop, lease, and buy the different types of software that make up the EDI pyramid. There are many software layers that are needed for you to understand these several layers, but there are lots of issues with this software. There are a lot of thoughts on EDI when you first purchase the application software. You have to go down one layer and look at the interface software to learn a little more. You then look down and look at the communications software. EDI has a lot of alterations in business procedure that are incumbent upon it. The application software has to be able to deal with these changes. One of the changes, for example, is that a lot of retailers tend to mail out one purchase order with many points of shipping. For a big company, this may mean that a single purchase order is given to as many as 2,500 shipping points. In order to fill out all these orders, the suppliers have to change their order-entry programs to split up multiple shipping orders into multiple orders. In some other instances, companies have to send out data in an EDI purchase order that needs to be returned through another EDI document. The application software may not be able to handle this data. There are complementary files that have to be built in in order to handle it. EDI is altering a lot of normal business procedures, and it is causing disruptions in the way that manufacturers handle software. To make and integrate orders from the forecast data, or have the chance to make the necessary data to build into the production scheduling application. There are a lot of examples in these instances, and if you bring in EDI with your production scheduling software, you have to be able to change and increase things as needed.