In EDI traffic, where the exchange of data and thus information is concerned, mapping is needed to correctly assign the data source (sender) and destination (recipient). Internal formats are transformed into standardized, uniform message formats and vice versa. The EDI mapping provides specific instructions for this. Thus, proprietary customer interfaces and individual settings for data exchange with each trading partner can be represented as well as any standardized data exchange procedure. By standardizing the data formats, EDI traffic runs more smoothly, and specific programming is not necessary.

Translation basis for the EDI converter

The mapping connects the source and target fields of the two formats. It provides the work instructions for the EDI converter, so to speak. It is a conversion software that converts data from the in-house system (the source) into a standard format (e.g. CSV, XML. EDIFACT, X.12, FLATFILE). Conversely, the converter writes incoming data from this format to interfaces (e.g. DB2 databases) at the receiver as the target.

In the mapping, the converter will find all specifications and instructions, with which it can create the new file in the desired standard format. Using the mappings also offers a high degree of possible flexibility. If, for example, you create customer-specific mappings, you can quickly and easily respond to your partners' change requests - as long as you either have extensive specific expertise in EDI programming or a suitable tool.

Guide to the data

In menten's EDI converter i‑effect^®, for example, mapping takes place in the central area of MapGui (graphical tool for creating mappings). The required fields (invoice date, number, and amount) are dragged from the source area to this area, where they are adjusted as needed (using many of the tasks available in i‑effect^®) and then converted into the required format. The EDI-mapping thus becomes a kind of "signpost for the data". By visualizing these assignments (mappings) you always keep an overview of your conversion tasks and processes and can easily react to changes. The created mappings are stored transparently in a structure (XML) that can be read by all participants.

Example: The customer generates a purchase order in SAP's own IDoc format, which he must convert into EDIFACT format readable for the vendor. In the course of mapping from source format to target format, essential information such as the purchase order date is not changed in terms of content, but converted so that it is readable in EDIFACT format ORDERS and can therefore be processed further. The same applies to incoming invoices, for example. Mappings are therefore ideally named "speaking" after the target module/message, in the case of the invoice thus: EDIFACT_INVOIC_D96A.map. It is important that the mapping is not only about a technically correct conversion. Rather, the data transmitted by the sender must also be correctly interpreted so that its specifications can be met.

Of course, there are sometimes special features in the communication between trading partners that require greater expertise in handling mappings and mapping tools. These include specifications agreed with the partners, special message types or field functions. In these cases, existing mappings must be adapted to the conditions of the special communication features. An EDI partner can take over such work and train the subsequent user group in the daily use of the functions and the application.