Electronic data exchange

Electronic data interchange ( English Electronic Data Interchange , EDI ) designated within the electronic data processing (EDP) as a collective term to exchange data using electronic transfer method. The application systems of the companies / organizations involved are directly involved (as the sender, carrier and recipient of the messages sent) .

In a narrower sense, EDI standards refer to specific procedures and agreements for data exchange that have been developed between companies or through standardization proposals from industry associations. In this context, the term only stands for the cross-company transfer of standardized business data.

features

Asynchronous: In the case of asynchronous data exchange methods, the data is transmitted in separate steps. The data is buffered several times en route, no immediate response is expected and transmitted. This process is also called store and forward . A typical example of an asynchronous method is the transmission of e-mail . E-mail is often used as a means of transport for EDI.
Synchronous: In contrast to this, there are synchronous data exchange processes in which a business-related and content-related response is received from the other party in the current connection or session. An example of this is querying the inventory for an item. The required information is obtained following the pull principle . The synchronous and automatic communication between distributed application systems is a possible use for queues .
Fully automatic: The main idea behind EDI is the fully automatic communication. The sending application system initiates the transfer and there is no human intervention, no human work step until the booking or pre- recording in the receiving system. This significantly reduces the number of input and data errors .
shipping: With EDI processes, communication always takes place in one direction: the sender sends messages to a recipient. In many EDI applications, the original recipient sends a message back later, but this is a different process that takes place separately in time and is again a pure sending process. In other words, EDI communicates according to the push principle .
Structured messages: An (electronic) message is a self-contained amount of data that consists of useful content and meta information . The useful content is exactly the data that is posted by the receiving system. The meta information primarily provides information about processing, especially routing to the recipient. An example of a message is email. In contrast to e-mails that people send each other, structured messages are used for EDI, i.e. these messages comply with the regulations or the syntax of a fixed structure. Such a structure consists of elements that are assembled into segments. The elements of the structure are specified with their properties such as length, position in the segment, type numeric / alphanumeric , must / can occur, possibly field separators and masking characters. The structure also specifies which segments may or must appear in which order and how often. The structure and the resulting syntax ensure that every date and every element can be posted to the right place in the receiving system.
Semi-structured messages: Since some data, such as CAD data, cannot be sent in a structured way, a so-called header or metafile must be created in which the names of the actual files are listed and further structured information is set for each file. This is practiced at ENGDAT , for example .
Application system: An application system here means a system made up of hardware and software that processes the received data in a business-related manner. Examples are Enterprise Resource Planning ( ERP ) systems, bank booking systems, production planning and control systems ( PPS systems ), warehouse management systems, sales or purchasing systems and many others. Direct recipients of messages are not people; only the data processed or at least pre-recorded by the application system are processed for a specific purpose if necessary and passed on to human users, for example in list form as an input, error or processing log.
Different institutions: Data exchange within an institution, which otherwise corresponds to the above definition, falls under the term Enterprise Application Integration (EAI). EDI, on the other hand, always means the participation of at least two different institutions. The tools used for EDI and EAI are very similar, which is why many tools are manufactured and used for both purposes at the same time. However, there are differences between EDI and EAI from an organizational point of view in that there is no single management over all affected systems, but consideration must be given to the respective partner and his individual situation. A contract must be concluded between the EDI partners, which defines the binding nature of the exchanged data and other aspects of electronic communication. In the case of EDI, greater difficulties have to be overcome due to the rather heterogeneous infrastructures on average, the need for additional encryption, greater distances and / or different skills and motivation of the people involved. The number of contacts required is often increased by the involvement of EDI service providers or other IT service providers. Institutions that use EDI are mainly larger companies, but increasingly also small and medium-sized companies as well as authorities and other organizations such as health insurance companies, associations and clubs; but not private individuals.

Implications

The above definition of EDI is independent of the application, the industry and the location of the participants, the products, structures and protocols used. As a result, it is especially not an exclusion criterion for EDI if the Internet or XML structures are used for the specific implementation, although this opinion is occasionally to be found - for example in advertising campaigns for Internet-based data exchange products, in which it is suggested that the supposedly "expensive EDI" will be replaced by the simple, cheap Internet and especially by XML. However, this idea is wrong because the challenges (see below ) to EDI implementations are always primarily of a technical / business nature, not tool or technology-dependent - and regardless of whether the data exchange is called "EDI" or not. For example, the semantic clarification of a term such as “delivery condition” between customer and supplier is always equally complex, regardless of whether an XML message or an EDIFACT message is used.

Demarcation

In contrast to EDI, there are a number of other procedures and standards for electronic data interchange. In order to differentiate EDI from some of these processes, the term classic EDI is used more precisely , in contrast to WebEDI or Internet EDI, for example . However, even in the professional world, no clear distinction is made between EDI as an umbrella term and, for example, EDIFACT as a specific expression. RosettaNet as the new XML standard is normally not regarded as an EDI standard, although it is difficult to clearly distinguish it.

history

It is believed that EDI was first used in the United States in the 1960s . Message structures were defined for specific needs, standards did not yet exist. The data was transmitted using the means available at the time via telephone and telex lines.

The emergence of Value Added Networks (VAN), privately operated networks, enabled institutions to subsequently exchange EDI messages with all partners involved in the network through a single connection to the network. In addition, the operators of the networks offered advice and support.

In 1977 SEDAS was introduced as the standard message format for the exchange of invoices and orders (purchase orders) in the consumer goods trade.

The first message standard for delivery schedules, VDA 4905, the first data exchange between VW and Hella, appeared in 1978 as the first important message standard.

1988: First adoption of the UN / EDIFACT message standard by the United Nations (UN)

The advent of the Internet (the WWW ) triggered the e-business euphoria. The new common network induced completely new ideas for electronic business data exchange beyond previous borders.

Electronic marketplaces , especially B2B marketplaces , once again used the idea of value added networks, this time using the new possibilities of the Internet, as a business model.

Closed networks were formed for individual industries and applications with the help of Internet technologies. Well-known examples are RosettaNet, ANX and its European offshoot ENX .

New initiatives such as ebXML , RosettaNet and new technologies such as web services expand the possibilities of electronic communication between institutions in the direction of synchronous processes that go beyond EDI.

Basic idea and potential

The fundamental and decisive advantage of using EDI lies in the high speed of electronic transmission in connection with the avoidance of human errors when transmitting information from one institution to the other. EDI makes it possible to exchange business data between the application programs of the partners involved without intervention. This results in the maximum rationalization of a business process such as the transmission of an order: The customer's order is recorded almost instantly, reliably and exactly as an order in the supplier's system. There is no post delivery time compared to the use of paper and compared to fax or e-mail there is no manual entry of the order in the supplier system, as well as the post-processing of a quota of incorrectly entered orders. EDI is used all over the world, in all industries, for a wide variety of applications. EDI contributes by far the largest share of the data volume electronically exchanged worldwide. Despite its long history for IT, it is still modern, and its use continues to grow.

Challenges

The implementation of EDI depends on the requirements of the partners involved. Since these can be very different and are often mutually unknown, the implementation is always a project. There are major differences between EDI in the German and Japanese automotive industries, in the grocery trade in Spain, in interbank transactions in Austria or in American industry.

Project management is therefore required. In practice, this point is often underestimated, which can lead to long project runtimes, budget overruns and general frustration. Basically, in addition to a project organization first organizational arrangements of all parties are required: Which business processes will be supported by EDI, as for these business processes is and should defined on both sides of what happens in case of error?

Another point that is often not sufficiently considered is the necessary master data. With manual processing of business processes, a lot of information about the business partner and his customs is available "in the head" of the processor. When automating via EDI, you often find that master data is not completely available in the application system. Material numbers in logistical processes represent another problem area . Questions arise such as: Does the customer use the supplier's material number or his own? Does the supplier know the material number used by the customer? Is there a clear assignment between customer and supplier material numbers? Problems in this area have led, for example, in the consumer goods industry to the development of EANCOM , a Europe-wide system of master data for articles and trading partners.

If ambiguities in the manual process are clarified by asking, there is no chance of this in the automatic process. All data must be harmonized in advance, otherwise the automatic process cannot work.

The SINFOS master data pool as an ECR tool offers help in harmonizing master data . The pool offers a multilateral exchange of master data between suppliers and dealers as well as extensive validation instruments.

In the technical part of the project the following points have to be done:

Agreement on the structure and semantics of the message
The message must, byte for byte, exactly meet the specifications and agreements so that automatic posting in the receiving system is possible. Important items to be agreed:
1. Use of a standard such as EDIFACT or develop your own structure
2. Identification / designation of sender and recipient
3. Clarification of properties and semantics for each field of the structure
  The structure of the message that the sending system sends and the structure that the receiving system can process almost always do not match. Then you need at least one further processing step:
Mapping one structure to another, that is, creating a mapping for converting messages
. Standards, such as EDIFACT, are often used as an intermediate format . The sender converts its structure, which is specified by the application system, into EDIFACT. The recipient then converts the EDIFACT message into the structure that his application system “understands”. So two conversions are applied. The reason for using a standardized intermediate format is that it would be far too complicated to generate each individual structure of all possible partners by direct conversion.
Message transport and processing
With a very low error rate, it must be guaranteed that every message sent reaches the recipient once and only once. In some applications, the sequence ( serialization ) of several messages must also be observed or additional steps must be carried out depending on certain events or content.
1. possibly implementation of coding / code page
2. Use of the transmission protocol and medium
3. Management of parameters for sender and receiver depending on the protocol
4. possibly compression
5. possibly encryption
6. possibly signature / authentication of sender or recipient
7. possibly status reports about processing and sending to the sender
Emergency measures in the event of failure of the system or parts of it
Particularly in the case of central systems, the failure of a system is often not easy for the user to recognize. Failures can range from a local program crash to line damage in the public area between the partners. Emails can be lost or filtered out before the recipient receives them. Since EDI is often a time-critical application or a business process depends on it, it is important to provide mechanisms with which the respective partner is informed promptly about problems and can take alternative measures, which ideally are agreed with each other in advance.

Billing in the EDI procedure

The EDI process is also being used more and more frequently in the area of electronic billing, as it can sometimes achieve significant savings. According to a study by the European Commission, conventional paper invoices cause costs of EUR 16.60, but EDI accounting can reduce costs by over 70 percent. With around six billion invoices per year across Germany, of which only six percent have so far been sent electronically, this is a savings volume of around 60 billion euros per year. When billing in electronic form, however, the sales tax requirements of § 14 Paragraph 3 UStG must be observed. Various implementation variants are available here. A common implementation variant is the so-called EDI procedure, which is based on an EDI agreement between the invoice creator and the invoice recipient to recognize the input tax deduction.

Tasks of an EDI system

For the ongoing processing, the transport and, if necessary, the conversion of the messages and status reports, i.e. the execution of the EDI functionalities according to points 2 and 3 as described above, an EDI system or an EDI system is required on the side of the sender and the recipient. Service company required.

restrictions

Similarity: Full automation, which is the basic idea of EDI, can ideally be achieved if the data transmission processes are as similar as possible. EDI is therefore often used in production-related logistics processes , for example for calling up raw materials that are always the same over months or years. Banks, too, often exchange transaction or account balance data with each other and with their business customers via EDI. On the other hand, processes relating to constantly changing goods, with changing material numbers or prices that fluctuate on a daily basis are only of limited use. Processes such as tenders and auctions with previously unknown business partners cannot be mapped with EDI alone.
Minimum number: EDI represents a high degree of integration of the systems involved. There is a certain one-time expenditure for the production of this integration, as well as ongoing expenditure for the operation of the EDI system. These factors are relatively independent of the number of transfers. The cost of implementing and running an EDI application is not associated with a factor of one hundred, depending on whether there are ten or a thousand transmissions per day later. In contrast, the optimization potentials correlate directly with the number of data transmission processes. The more processes are affected, the greater the benefit and the more it pays to use EDI. A minimum number of transmissions per partner must therefore be given for economic use.
diversity: The standards allow a wide spectrum within each business case. Each user uses a different part of the spectrum. It usually depends on the economic strength of a partner what the agreement of the news looks like. As a rule, the automobile manufacturers provide their suppliers with the respective data content. The suppliers, on the other hand, have to react very flexibly to a larger number of customers in order to satisfy all customers, which on the other hand often makes the system more expensive.

Message standards

So that EDI messages can be processed by the recipient, they must correspond to a previously known structure (" exchange format ") . There are countless different structures for EDI messages around the world. Some important standards are listed below:

SWIFT - for banks

UN / EDIFACT - the most comprehensive and globally used standard, is the responsibility of the Economic Commission for Europe (UN / ECE) of the United Nations . Within EDIFACT there are branch-specific subsets such as B. EDIFICE and EANCOM

ANSI ASC X12 - standard mainly used in the USA

GTDI (Guidelines for Trade Data Interchange) - a standard format developed by the UN / ECE in Geneva and still widely represented in Great Britain today. Together with ANSI ASC X12, it was the basis for UN / EDIFACT .

VDA - standard of the German automotive industry. There is no further development. EDIFACT messages are a replacement.

GAEB - for the building industry (Joint Committee Electronics in Building)

ODETTE - standard of the European automotive industry. Odette's own formats still exist. Today, new developments are only developed and published on the basis of the EDIFACT syntax.

GALIA - automotive standard especially in France, very similar to ODETTE

ebXML - open standard from OASIS and CEFACT

Fortras - for data exchange between forwarding agents

XBRL - Financial Reporting

railML - Open data exchange format in the rail sector for timetables , train compositions and route features
RosettaNet - a non-profit consortium in which over 600 companies, mainly from the electronics industry, participate. The aim is to develop and introduce open e-business standards and services in industry.
myOpenFactory - German standard for electronic data exchange for inter-company order and project processing
openTRANS - transaction standard for exchanging business documents such as invoices , orders or shipping notifications and payment notifications . There is a specification for each type of document.
UNIDOC - XML standard for the exchange of business documents of all kinds, with the special feature that the same data structure is used for all document types.

In addition, there are countless national, product or industry-specific message standards as well as standards within the framework of marketplaces and VANs such as

SEDAS for the consumer goods trade
e-CODEX for cross-border access to law and justice
xCBL - XML Common Business Library (xCBL), originally defined by Commerce One
Data carrier exchange procedure (DTA): Standard for the transmission of payment orders to your banks (in Germany)
ELSTER : The electronic tax return of the German tax authorities
E-Rates : Transmission of air freight rates from airlines to air freight forwarders
eXTra standard : Federal standard of the BMWi , is z. As the sole transmission standard for employers messages in the German social security used

Transmission protocols

For EDI it is necessary to transport the user data from the sender to the recipient via any intermediate points. There are a number of network protocols for this, some of which are particularly common are listed here:

Older EDI transmission protocols

X.400 e-mail standard of the ITU
OFTP oftp 1, can be applied to ISDN , TCP / IP , X.25 or X.31 Place
FTAM File Transfer Access and Management

In addition, some protocols from the Internet protocol family are in use, in particular:

SMTP Simple Mail Transfer Protocol
HTTP / HTTPS Hypertext Transfer Protocol
FTP / SFTP File Transfer Protocol

Based on the Internet protocols, there are communication standards which, in addition to the pure data transport, contain additional properties such as encryption, authentication and compression. Examples are:

AS1 Internet EDIINT Protocol (Applicability Statement 1) (SMTP)
AS2 Internet EDIINT Protocol (Applicability Statement 2) (HTTP)
AS3 Internet EDIINT protocol (Applicability Statement 3) (FTP)
AS4 (Applicability Statement 4), based on AS2 and ebMS 3.0
EBICS Electronic Banking Internet Communication Standard (HTTP)
OFTP2 Odette File Transfer Protocol 2.

The older protocols usually do not use encryption because either a point-to-point connection is used or the network is trusted. When using the Internet, however, encryption is usually used. The EDIINT protocols can encrypt both the line and the file. Compression is also possible with the EDIINT protocols. In addition, there is an unknown number of national, product or industry-specific protocols or communication standards, for example in the context of marketplaces and VANs .

Web links

Individual evidence

↑ G. Nöcker: The paperless forwarding agency. 2002, p. 11.
↑ RFC 3335 . - MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet . September 2002. (English).

[Nöcker-1] G. Nöcker: The paperless forwarding agency. 2002, p. 11.

[2] RFC 3335 . - MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet . September 2002. (English).