UN/EDIFACT is an abbreviation for “United Nations Electronic Data Interchange for Administration, Commerce and Transport” and thus gives a first indication that this format is in fact the only really internationally valid EDI standard, which furthermore addresses all industries in which EDI data exchange plays a serious role.
Continuous improvement of data quality through regular new versioning
Although EDIFACT is a globally valid EDI standard, it is subject to alternating versioning, so that different variants are subsumed under the UN/EDIFACT umbrella and differentiated by year. Two different variants are thus published each year by the CEFACTBoard affiliated with the United Nations. In addition to the publication year, these variants are identified by the suffix A (published April 1) and B (published October 1) (e.g., D.96A, D.01B, D.07A, etc.). In general, with each publication of a new EDIFACT directory (= EDIFACT version) the number of included EDIFACT message types and the possible range of information to be transmitted in the form of EDIFACT data elements increase. This fact is the main reason why in existing EDI connections with large-scale market participants a change to a newer EDIFACT version is requested every 3-6 years, such as the change from D.96A to D.01B among the EZHG suppliers. Consequently, this not only entails a change in the EDIFACT exchange format but also an expansion of the semantic data scope, i.e., an improvement in EDI data quality. However, the request to switch to a newer EDIFACT version often also means a complete EDIFACT format change within an existing EDI connection. The EDI technology of the majority of EDI providers operating on the market is designed as a flat file converter that uses IF-THEN-ELSE mechanisms to map a rigid point-to-point connection between the export and import formats of the ERP interface and the EDI format of the partner. Therefore, this requirement is usually synonymous with a costly re-implementation of an existing EDI connection.
Easy changeover to new EDIFACT versions with Softzoll
The technology of Softzoll EDI systems uses the original EDIFCAT rules of the UN/EDIFACT board for conversion. Via an interface, the individual EDIFACT vintages and versions can be imported as *.xsd schemas into the underlying EDI software. This activates a new blueprint for the corresponding EDIFACT version within a very short time. These EDIFACT rule sets are available on demand as a component within a partner-specific EDI workflow. Based on this EDI technology, Softzoll can not only provide its customers with the required EDIFACT rule sets free of charge, but when they switch to a different EDIFACT format, the appropriate rule set is simply exchanged with a click of the mouse. This leads to a considerable reduction in EDI follow-up costs and limits the necessary work to the additional EDI data elements that may need to be included, as well as their processing via the ERP interface.
EDIFACT subsets for industry-specific standardization
Furthermore, EDIFACT subsets must additionally be defined within individual industries. These are subsets of an EDIFACT directory where special attention is paid to the content of an EDIFACT variant. In this way, an attempt is made to achieve further standardization for the industry in question—an industry-specific standard, as it were.It is hoped that this will simplify EDI connections between the EDI exchange partners involved in an industry.
Positive example of successful standardization: EDITEC
A noteworthy example of the successful standardization of an EDIFACT communication within an industry is the EDIFACT subset EDITEC. Although the EDITEC subset exists in different versions (EDITEC 2.2, EDITEC 3.0, EDITEC 4.0, etc.), care has been taken within these versions to ensure that the content scope of the EDIFACT data elements included in these versions has been precisely defined in a maximum specification. This has the effect that all EDIFACT message types (e.g., ORDERS, DESADV, REMADV, etc.) defined within the EDITEC subset are identical for each version. The technical EDI implementation of an EDI connection based on EDITEC is therefore reproducible and can thus be reused for connecting further partners.
EDIFACT message types
Another important characteristic of the EDIFACT format is the subdivision of an EDIFACT version into individual EDIFACT message types. The message types mapped in the EDIFACT standard represent partly industry-typical, but also cross-industry EDI business processes. The naming and intent of the individual EDIFACT message types remind us that often the corresponding paper document served as the source of an EDI business process. As the meaning and differentiation of individual message types are fundamental for the understanding of modern EDI data exchange, Softzoll pays special attention to this subarea in particular.
Some information about the syntax of EDIFACT messages
The syntactic structure of an EDIFACT message is often compared to an envelope. The beginning of an EDIFACT message consists of a UNB segment. The sender and recipient are defined in this UNB segment. In order to make this identification as unambiguous as possible and at the same time machine-readable, the use of identification numbers has become established here, representing this information in coded form. Since EDI data exchanges are becoming increasingly internationalized in the course of globalization, many EDI users use a GLN number (Global Location Number), which is unique worldwide and serves to unequivocally assign the parties involved in the EDI data exchange (companies, plant locations, etc.). In addition, information on time specifications and review elements is transmitted in the UNB segment, which can be used to check an EDIFACT message for its consistency. Optionally, the UNB segment can be preceded by a UNA segment in which a separator is defined for segment, element and decimal separators. The end of an EDIFACT message is the UNZ segment; together with the UNB, it encloses the actual EDIFACT message with the detailed contents of the business process concerned. The technical details of the EDIFACT syntax will not be discussed further here; corresponding explanations can be found on almost all websites dealing with EDI and EDIFACT-related topics. However, acquiring a fundamental understanding of the EDIFACT syntax and its proper application requires many years of practice. Generally, it is sufficient to know that an EDIFACT message is composed of segments whose individual data elements are defined by standardized abbreviations and code lists. The content of a data element can be described precisely in this way, enabling the understanding and automated processing of an EDIFACT message across language barriers and national borders.
In everyday EDI, the devil is often in the details
In addition, the individual segments and data elements of an EDIFACT message are subject to restrictions regarding the maximum usability within a transmission message; the codes used to qualify message content are also precisely specified. Often the contents of an EDIFACT message are additionally divided into must and can elements. This distinction is especially helpful when connecting and integrating source and target systems involved in EDIFACT data exchange or when avoiding unnecessary efforts in the course of EDI integration projects. The restrictions defined in the standard are not always suitable for EDI practice. Not least for this reason, there are quite a few application scenarios in which the sender and recipient define the EDIFACT framework parameters bilaterally in accordance with the in situ requirements for a workable EDI data exchange process. These bilateral agreements often form the nucleus of the above-mentioned industry-internal EDIFACT variants or subsets.