There are compelling reasons why worldwide EDI transaction volume continues to grow. EDI can lower costs, improve accuracy, increase efficiency, improve fulfillment times, etc. However, it is virtually impossible to recognize any of these benefits if EDI transactions are not integrated with an Enterprise Resource Planning (ERP) system. If a company is receiving 1000’s of orders per day electronically, but must key them into their fulfilment system manually, it is unlikely there will be a material benefit to sending and receiving transactions via EDI.
While EDI integration to an ERP is critical, surprisingly, most leading ERP packages do not provide “out of the box” support for EDI. EDI support or integration is typically provided by third parties, or ISV solutions. These third-party solutions have features that make them unique but fundamentally they come in only one of two flavors: embedded or stand-alone. An embedded solution is one in which the ISV has modified the source code, screens, business logic, and database objects of the ERP application to support EDI. A non- embedded or stand-alone solution is one that does not require modifications to the source code or the database objects of the ERP application. The concept is simple, and the differences may seem obvious, however, the ramifications of choosing one approach vs. the other can be significant.
Stand-Alone is Less Strain on Your ERP
The Data Masons EDI solution is a stand-alone application. All transaction processing, cross reference checking, mapping, error handling, exception reporting, etc. is managed outside of the ERP. The Data Masons application communicates directly with the ERP application in real time via the ERP’s native integration layer protocols (oData, Data Endpoints, Integration Ports, etc.). This is the ERP companies’ recommended approach, because it removes the resource intensive processing of transactions from the ERP. It also allows the EDI solution to remain decoupled from ERP. This insulates the stand-alone EDI application from any disruptive changes to ERP introduced by customizations or upgrades and conversely protects the ERP application by not requiring code changes or customizations to support EDI integration.
There is a vast amount of processing and business logic involved in integrating EDI transactions into an ERP system. In addition to reporting, notifications, exception handling, and transaction processing, it is akin to essentially connecting the ERP system of one company to another. Item numbers, ship to locations, customer codes, discount codes, freight providers, etc. all need to be translated or mapped from one system to another. EDI standards facilitate this integration to an extent, but EDI has grown far beyond the traditional ANSI X12 or EDIFACT standards. EDI encompasses ecommerce: cXML, XML, Flat File, X12, EDIFACT, Punch Outs, API’s via https, Amazon Web Services, Blockchain, Web Shopping Carts, etc. Embedding all the functionality required to support ecommerce into to an existing ERP system radically alters the underlying system. It requires significant invasive code changes and customizations to the ERP code base, business logic, and database objects.
Could Embedded EDI Still be Worth It?
ERP customizations are not uncommon, however. Anyone who has implemented an ERP system has experienced the dilemma between altering the ERP to fit a business process vs altering the business process to fit the ERP. In the short term it is tempting to modify the ERP application, especially if it is something minor such as adding a new field or simply changing a label.
However, long term, even simple changes to ERP source code can have long lasting and painful consequences. For this reason, conventional wisdom and ERP vendors caution against significant customizations to ERP. Each change to ERP source code adds to the complexity and cost of supporting and maintaining the system. Customized ERP systems can be a nightmare to upgrade because all customizations must be re-introduced or migrated into the new code base and then all changes must be tested again. This reengineering and regression testing process is at the very least expensive and time consuming and at its worst can be cost prohibitive. It is not uncommon for customers with heavily customized ERP systems to remain on outdated versions indefinitely. This inability to upgrade is a problem for not only the customer but also the ERP vendor.
Embedded EDI is a problem for the customer in that they are not able to take advantage of critical fixes or enhancements that are introduced by the ERP vendor. They are in effect receiving zero return for the support and maintenance fees they are paying for their system if they are not upgrading regularly. It is a problem for the ERP vendor in that they must continue to support outdated systems and technology. They are required to spread their resources across multiple supported versions.
Listen to Your ERP Provider
Not surprisingly ERP vendors have taken steps recently to mitigate this problem, particularly within the SaaS ERP solutions. Customers are being strongly discouraged from making any changes to core code, but more importantly customers will no longer be able to remain on a version indefinitely. Microsoft, for example, has implemented a policy of "One version, with all customers on the latest available version". With this policy effective as of January 31, 2019, all users were required to update to a specific version. Going forward there will be twice per year (April and October) mandatory upgrades for all customers using the Microsoft flagship D365 suite of ERP.
Microsoft will disable potentially disruptive new features by default and intends to make the releases backwards compatible to minimize impact to customizations. However, the impact to customers with an embedded EDI solution or a heavily customized ERP will most likely be extensive twice annual regression testing, followed by more code changes and updates to take advantage of new functionality. This will most likely make an embedded EDI solution very difficult and expensive to maintain and why Data Masons promotes the stand-alone approach.