EDI Recommendations Service segments   1. Introduction Language select:

Preface

The aim of the brochure on hand is to offer documentation to describe an EANCOM^® transmission file.

The basis of this elaboration is the international standard EANCOM^® 2002. GEFEG.FX (Gefeg mbH, Berlin) was used as the documentation tool.

Please be aware to know that this booklet does not replace the complete specifications in the original chapters or other relevant instructions within the EANCOM^® 2002 documentation. Instead, it deals with the description of segments, data elements and codes to be used for a specific task.

The current documentation has been produced by the GS1 Germany GmbH in Cologne. GS1 Germany assumes no liability for any damages incurring from the use of this documentation. This brochure or extracts thereof may only be published or forwarded to third parties with the express written consent of GS1 Germany, which holds copyright on this work.

GS1 Germany thanks all experts who contributed significantly to these guidelines with knowledge from their daily business.

Important note:

To fulfill the requirements of directive 2003/58/EG, article 4, C058 has been opened in NAD segments identifying a message sender. If the place in the 5 DE 3124 is not sufficient, the following RFF segments can be used, qualified with DE 1153 = GN. DE 1154 has got a capacity of 70 digits. Only in those cases, when no RFF segment follows NAD, a RFF+GN can be used in the heading section of the message. Within the EDI recommendations of GS! Germany this is only applicable for the messages REMADV and SLSFCT..

Conventions

This brochure offers different ways to start:

Section 2, "Business Terms", is a table which links directly to the sequence numbers of the segments.

Section 3, "Message Structure Chart", is a list of all used segments in the same sequence as they are defined in the EANCOM^® message. In general, for each piece of information one single segment is provided. Exeptions may arrise when the the occurence of a segment is limited and can contain alternative information (e.g., segment BGM).

Section 4, "Branching Diagram", is a hierarchical graphic depiction of all used segments in the same sequence as they are defined in the EANCOM^® message. However, every segment is shown only once, and it is therefore possible that the sequence numbering is interrupted.

Section 5, "Segments Description", is a brief summary of the use of each segment.

In Section 6, "Segments Layout", an illustration that has been chosen to match the business terms (data from the inhouse application) with the elements from the EANCOM^® syntax.

In Section 7, "EANCOM^® Segments Layout", the message is presented in a similar layout as in the EANCOM^® manual.

Note on sections 6 and 7:

An additional column (GER) to provide a German status has been added to the layouts. An entry indicates that the recommended status differs from the EANCOM^® status. If the recommended status is weaker than the EANCOM^® status, the data element (or, if only one term exists the entire segment) can be omitted.

In general, code names are presented in red; these must to be understood as restricted and should not be changed/modified without bilateral agreement with the partner. If codes are given as examples, they are represented in blue (e.g., measurements). In this case, all codes of the relevant code list can be used.

Section 8, "Example(s)", provides at least one message example with comments.

Please note that, for technical reasons, the examples can contain component data element separators, which would otherwise be represented as data element separators in the original messages.

The following conventions apply to this brochure:

Project description

This documentation describes the construction of an EDI interchange file used by EANCOM^® users to exchange messages or message groups. Message groups may only contain messages with one unique type (UNH DE 0065), the interchange can contain different message groups or messages. Message groups in EANCOM^® should only be used in exceptional cases. One of a possible exception is a corporate computer centre sending invoice data from different issuers to regulators or payment service providers. In this case the use of message groups offers a possibility to sort the data.

Basic rule:

If an interchange file contains only data from one sender the level "message group UNG...UNE" is left out.

Construction of the interchange

After connection establishment the data transmission starts by sending the service segment UNB (Interchange header). The use of a preceding UNA segment is required when using a character set other than level A. The actual messages will follow the UNB segment always starting with UNH (Message header) and ending with UNT (Message trailer) . Messages can be covered by message groups (Service segments UNG...UNE). The transmission file will be ended by use of the service segment UNZ (Interchange trailer). Finally the connection can be terminated..

One single message contains a heading section to indicate the interchange partners and a summary section to provide accumulated values. Inbetween the detail section provides information about products or services.

Structure of an interchange: