About 20 years ago, the consensus in the IT industry was to purchase a professional RDBMS (Relational Database Management System), hire a handful of programmers, and independently develop a proprietary ERP that was completely geared to the requirements of the respective company. The AS/400 designed by IBM, in particular, was the tool of choice at the time, and there were sufficient RPG programmers capable of mapping all of a company’s use cases in the form of an ERP application. This situation has since changed fundamentally. Most companies today use standard ERP applications such as SAP, MS Dynamics, Infor, or Abas, whose wide range of functional scope options maps all company operations relevant to business processes. There are also a large number of ERP industry solutions geared towards the specifics of certain industries.
Numerous ERP in-house developments still in use
Despite this development, a number of proprietary ERP systems have remained in daily use; some of these are ERP systems whose original manufacturers are no longer available or versions that no longer received support from the manufacturer and were consequently further developed by the respective IT departments on an application-specific basis.
RDBMS remains the basis for all business processes
One aspect, however, unites standard and proprietary ERP systems: both variants use the relational database as the linchpin of all business processes and thus as the basis for all application-specific program routines. The spectrum of deployed RDBMS ranges from exotic database variants to widely used database systems such as DB2, Oracle, MS SQL, Informix, and MySQL. The conventional method of using file-based interfaces such as XML or ASCII/TXT to integrate EDI processes can be extended by Softzoll technology to include the option of database-supported EDI integration, especially for ERP systems developed in-house. All variants of the Softzoll EDI solutions (both in-house and outsourced) offer the possibility to instrumentalize relational databases as source and target of all relevant EDI data contents with read or write access via a suitable database gateway (e.g., ODBC). The advantage of such a strategy is that savvy ERP programmers can use the development tools and database tools of their choice to organize the supply of EDI native information to a native database table without any external help. Their only task is now to read clearly defined information relevant to the EDI (e.g., invoice date, delivery note number) from an internal database table and to transfer it to a second table on the same database system or vice versa. They can therefore bring their accumulated expertise on the application and development level to supplying the EDI interface without having to deal with the EDI syntax in any way. This is a task that any ERP developer would be happy to perform.
Central documentation for global message types
Click on the image to enlarge
On request, Softzoll can provide a standardized table structure of the EDI database for this integration variant which is capable of mapping more than 700 inbound and outbound business processes in a single database table. The field characteristics of this EDI table are defined according to ISO 9735, a basis that also uses standard communication formats such as EDIFACT, BizTalk.org, OpenTrans, and the SAP XML IDOC interfaces, etc. Optionally, Softzoll provides the field assignment for the most important EDI business processes (PRICAT, ORDERS, DESADV, INVOIC, RECADV, IFTMIN, etc.), which means that 90% of the EDI content in use worldwide is predefined for programmers. This makes it possible to develop a globally valid EDI supply to the proprietary ERP system at business process level from the front.
Complex ERP interfaces complicate the integration of EDI third-party systems
Users of standard ERP systems also use a variant of database-driven ERP integration of EDI processes. The file-based interfaces for connecting external systems sometimes have such a complex structure that it is almost impossible to parameterize these interfaces for connecting third-party systems without the help of specialized ERP consultants. Owing to the resulting costs, the bypassing of the functionalities within the interface modules is consciously accepted and a direct connection of the necessary ERP database tables is preferred. In these scenarios, there are usually several database tables per business process that have to be read or populated by the EDI system. The cost savings resulting from this rather unconventional approach nevertheless cause numerous users of standard ERP systems to accept this method despite the resulting disadvantages (e.g., porting of functionality during release upgrades).