Clarification of the basics:

Request: In the request, whether initiated by the company itself or by a customer/supplier, it must be made clear which data is expected in which form and on which transmission path. Let's take as an example an electronic invoice in EDIFACT INVOIC format to be sent via AS2.

Source: In order to produce the desired data format, it must first be known where the necessary invoice information is located in one's own company. Usually this will be a database, in the IBM i environment probably DB2. In addition, it must be checked whether a solution for communication is possibly already available internally. Let's stay with the example: The invoice information is in DB2, a new EDI standard solution is to be used for the AS2 transmission protocol.

Target: Either the company itself or the customer/supplier will specify which data format is expected, in our example EDIFACT INVOIC. For this, there must still be details such as version/directory/subset, which should be documented in a corresponding guideline. Sample files of the target format are also helpful. For the communication part the corresponding parameters have to be exchanged. (IP/port/certificates, if we stay with AS2 as an example.) This applies analogously for other communication protocols.

Conversion/Implementation:

Mapping/translation/conversion: Data source and target structure are now known. Consequently, either self-programmed or by means of standard software (recommended), the translation of the data can be started. Modern EDI converters like i‑effect^® provide intuitive and graphical mapping tools for this purpose. With the help of the data mapping, a "route planner" for the data is created, so to speak, in order to transfer it from source to destination. At the end, the desired file, in this case EDIFACT INVOIC, is available in the file system.

Transmission/communication: The communication parameters are now known. The communication system, e.g. i‑effect^®, can now be ideally guided and clearly filled with the necessary information and the communication can be set up this way. The file is now taken from the file system and transferred to the recipient.

Automation: At this point, the one-time EDI process is already completed. In the very least cases, however, data is transferred once; rather, this should be done on a regular basis. Basically, automated control can be time or event based, e.g. data should always be sent at a certain time in the evening or whenever a file is created in a certain directory.

Monitoring: The EDI process is now set up. Afterwards this will want to be supervised. Modern EDI solutions provide suitable interfaces at this point. i‑effect^®, for example, uses WebControl, a browser-based monitoring platform. Here, data input and output as well as the conversion processes can not only be monitored in different degrees of detail, but additionally, this interface is also suitable for setting up processes, maintaining master data and, of course, offering solutions in case of an error.

Which application areas or departments benefit most from an EDI infrastructure?

Focused on external data exchange, usually an exchange of documents such as purchase orders, delivery notes or invoices, this will certainly be sales or purchasing or financial accounting in particular. Basically, however, the entire company benefits if you broaden your view a bit. Of course, warehouses, logistics, production and last but not least the IT department itself can enjoy the benefits of a modern EDI software, either by using and exchanging suitable standard message types like ORDERS, DESADV or INVOIC, to name just a few common ones, or by using an EDI software as an EAI tool to mediate between different internal software solutions. Finally, an EDI software can be the central data hub for corresponding enterprise data.

What formats should an EDI solution be capable of?

A fully comprehensive software should have an answer to all common data formats. At least one could limit oneself to the widely used formats EDIFACT and XML, here e.g. UBL or openTRANS, but basically also XRechnung and ZUGFeRD. However, individual, non-standardized or older data formats are also used, such as CSV, flat files, or tradacoms. i‑effect^®, for example, is modularly structured, so that with this solution it is always possible to react specifically to the respective application and customer requirements.