EANCOM® 2002 S4, Edition 2016 Part I EANCOM® MESSAGES

5. APPENDIX 1: UN/EDIFACT

5.1. Definition of UN/EDIFACT

United Nation's Directories for Electronic Data Interchange for Administration, Commerce and Transport. They comprise a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data, particular as related to trade in goods and services, between independent, computerised information systems.

Recommended within the framework of the United Nations, the rules are approved and published by the UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic business) in the United Nations Trade Data Interchange Directory (UNTDID) and are maintained under agreed procedures. UNTDID includes:

• EDIFACT - Application level syntax rules (Syntax version: 4);
• Message design guidelines;
• Syntax implementation guidelines;
• EDIFACT Data Elements Directory, EDED (a subset of UNTDED);
• EDIFACT Code list, EDCL;
• EDIFACT Composite data elements Directory, EDCD;
• EDIFACT standard Segments Directory, EDSD;
• EDIFACT United Nations Standard Messages Directory, EDMD;
• Uniform Rules of Conduct for the Interchange of Trade Data by Tele-transmission (UNCID);
• Explanatory material, as appropriate.

Actual information is available at http://www.unece.org/info/ece-homepage.html.

5.2. EDIFACT Syntax version 4 overview

This section is a summary of the document: "EDIFACT - Application level syntax rules (Syntax version 4)". Actual information is available at www.unece.org/cefact.

The UN/EDIFACT syntax rules set the rules for structuring data into segments, segments into messages, and messages into an interchange.

5.2.1. Interchange Structure

An interchange may consist of the following segments:

Segments starting with "UN" are called service segments. They constitute the envelope or the "packaging" of the UN/EDIFACT messages.

User data segments contain the information itself, in a format specific to each message type.

5.2.2. Message Structure

Each data segment has a specific place within the sequence of segments in the message. They may occur in any of the following three sections of the message:

1. Heading section - A segment occurring in this section relates to the entire message.
2. Detail section - A segment occurring in this section relates to the detail information only.
3. Summary section - Only segments containing totals or control information may occur in the summary section, e.g. invoice total amount, number of lines in a purchase order, etc.

The sequence of the three message sections can be represented by the following simple example:

The same segment type may occur in more than one of the message sections, for example in the header and in the detail section, and/or more than once in the same section.

Some segments may be repeated a certain number of times at their specific location in the message. The status, Mandatory or Conditional, and the maximum number of repetitions of segment types are indicated in the message structure.

Within a message, specific groups of functionally related segments may be repeated; these groups are referred to as "segment groups". The maximum number of repetitions of a particular segment group at a specific location is included in the message definition.

A segment group may be nested within other segment groups, provided that the inner segment group terminates before any outer segment group terminates.

5.2.3.  Segment structure

A segment consists of:

• A segment tag: identifies the segment type
• Data element separators
• Simple and/or composite data elements
• A segment terminator

Data elements can be defined as having a fixed or variable length.

A composite data element contains two or more component data elements.

A component data element is a simple data element used in a composite data element.

Example of a composite data element:

The date qualifiers: function and value are the component data elements.

A data element can be qualified by another data element, the value of which is expressed as a code that gives specific meaning to the data. The data value of a qualifier is a code taken from an agreed set of code values.

Within Syntax 4 it is also possible to repeat data elements or data element groups according to the possible repetitions stated in the standard. The asterisk ( * ) is used as a repetition separator. This feature is only used within the KEYMAN message (USA, S503). This feature is NOT used in any other messages or segments within EANCOM^® 2002 syntax 4.

Multiple occurrences of stand-alone simple or composite data elements are permitted.

5.2.4. Service characters

In EANCOM^®, four characters, extracted from character set level A, have a special meaning and act as the default service characters for EANCOM^®:

Within EANCOM^® 2002 syntax 4 the use of UNA is conditional.

Should trading partners agree to use any of the character sets from B to F (inclusive) and the default separators from UNOA, then the UNA segment must be provided to explicitly state the default separator values.

Example of an UN/EDIFACT segment:

5.2.5. Compression of data

In data elements for which the Trade Data Elements Directory specifies variable length and no other restrictions, non-significant character positions, (i.e. leading zeroes and trailing spaces) should be suppressed.

TAG = segment tag; DE = data element; CE = component data element.

• Exclusion of segments. Conditional segments containing no data should be omitted (including their segment tags).
• Exclusion of data elements by omission. Data elements are identified by their sequential position within the segments as stated in the Segment Directory. If a conditional data element is omitted and followed by another data element, its position should be indicated by retention of its data element separator.
  
• Exclusion of data elements by truncation. If one or more conditional data elements at the end of a segment are omitted, the segment may be truncated by the segment terminator.
  
• Exclusion of component data elements by omission. If a conditional CE is omitted and followed by another CE, its given position must be represented by its CE separator.
  
• Exclusion of component data elements by truncation. One or more conditional CE's at the end of a composite DE may be excluded by truncation by the DE separator or, if at the end of a segment, by the segment terminator.
  
• Exclusion of component data elements by omission. The position of an occurrence of a repeating data element may be significant in some cases (e.g., transfer array data). In such a case, if an occurrence of a repeating data element is omitted and is followed by another occurrence of the same repeating data element, its position shall be indicated by retention of the repetition separator which would normally follow it.
  
• Exclusion of component data elements by truncation. One or more conditional CE's at the end of a composite DE may be excluded by truncation by the DE separator or, if at the end of a segment, by the segment terminator.
  

5.2.6. Representation of numeric values

• Decimal sign. The representation for decimal sign is the point on the line (.). The decimal sign should not be counted as a character when computing the maximum field length of a data element. When a decimal sign is transmitted, there should be at least one digit before and after the decimal sign.
• To assist in-house file designers and data interchange partners, the following lengths may be used as a guideline:

• Triad separator. Triad separators should not be used in the interchange. (Allowed: 2500000; Not allowed: 2,500,000 or 2.500.000 or 2 500 000).
• Sign. Numeric data element values should be regarded as positive. Although a deduction is conceptually negative, it should be represented by a positive value, (e.g. in a credit note all values are positive, and the application software uses the message name coded (DE 1001) to convert all values into negative). In addition, some data elements and code combinations will lead to implied negative values, (e.g. data element 5463 with code value "A, Allowance" in an ALC segment in an invoice).
  If a value is to be represented as negative, in transmission it should be immediately preceded by a minus sign (e.g. -112). The minus sign shall not be counted as a character when computing the maximum field length of a data element.

Example 1 (INVOIC)

Example 2 (INVOIC)

As DE 5463 in the ALC segment contains code value A, the numeric values in MOA below should be interpreted as negative by the in-house application.

It is recommended to create one message for the invoice and one message for the credit note. As this is not always possible (e.g., an invoice for drinks with a negative deposit balance at detail level) the minus sign can be used in DE 6060 of the QTY segment and in DE 5004 of the MOA segment.

This rule is applicable for debit lines in credit notes and for credit lines in invoices/debit notes.

If allowances or charges are calculated backwards (credit note for a previously sent invoice) the code value in ALC DE 5463 is not changed.

5.2.7. Character set and syntax identifiers

Supported character sets

In syntax version 4 character sets level A, B, C, D, E, F, G, H, I, J, K, X and Y are supported. Also supported are the code extension techniques covered by ISO 2022 (with certain restrictions on its use within an interchange), and the partial use of the techniques covered by ISO/IEC 10646-1.

Within EANCOM^® the use of character set level A is recommended. Any user, wishing to use a character set level other than A, should first obtain agreement from the intended trading partner in order to ensure correct processing by the receiving application.

Character set level A

Character set level A (ISO 646 7-bit single byte code, with the exception of lower case letters and certain graphic character allocations) contains the following characters: 

Character set level B

Character set level B (ISO 646 7-bit single byte code, with the exception of certain graphic character allocations) contains the same characters as character set level A plus lower case letters "a" to "z".

Character sets level C to K

Character sets level C to K (ISO 8859 - 1,2,5,7,3,4,6,8,9 8-bit single byte coded graphic character sets) cover the Latin 1 - 5, Cyrillic, Arabic, Greek and Hebrew alphabets.

It is important to note that EANCOM^® users often need, in addition to the recommended character set level A, the following sub-set of supplementary characters taken from ISO 8859 - 1:

Character set level X

Character repertoire resulting from the application of the code extension technique as defined by ISO 2022, utilising the escape sequence technique in accordance with ISO 2375. For more details see ISO/ICE International Register of Coded Character Sets to be used with Escape Sequences.

Character set level Y

Character repertoire taken from ISO 10646-1 octet without the application of a code extension technique. See the appropriate details in ISO 10646-1.

Syntax identifier, ISO standard and supported languages

The following table contains the code values for the syntax identifier and explains which languages are catered for in which ISO standard.

Note that the last character of the syntax identifier (data element 0001) identifies the character set level used.

5.3. Directory status, version and release

All EANCOM^® 2002 messages are based on the UN/EDIFACT directory D.01B, which was released by UN/CEFACT in 2001. All messages contained in this directory are approved as United Nations Standard Messages (UNSM).

5.4. EANCOM^® message version

Each EANCOM^® message carries its own subset version number, which allows the unambiguous identification of different versions of the same EANCOM^® message. The EANCOM^® subset version number is indicated in data element 0057 in the UNG and UNH segments. It is structured as follows:

EANnnn

where:

EAN = EANCOM is the name of the standard, GS1 is the agency controlling the subset.

nnn = Three-digit version number of the EANCOM^® subset.

Subset version numbers for formally released EANCOM^® messages start at the number "001" and are incremented by one for each subsequent version of the message.

5.5. Documentation conventions

5.5.1. Format and picture of data elements

The following conventions apply in the present documentation:

5.5.2. Indicators

Segment layout

This section describes the layout of segments used in the EANCOM^® messages. The original UN/EDIFACT segment layout is listed. The appropriate comments relevant to the EANCOM^® subset are indicated.

The segments are presented in the sequence in which they appear in the message. The segment or segment group tag is followed by the (M)andatory / (C)onditional indicator, the maximum number of occurrences and the segment description.

Reading from left to right, in column one, the data element tags and descriptions are shown, followed by in the second column the UN/EDIFACT status (M or C), the field format, and the picture of the data elements. These first pieces of information constitute the original UN/EDIFACT segment layout.

Following the UN/EDIFACT information, EANCOM^® specific information is provided in the third, fourth, and fifth columns. In the third column a status indicator for the use of (C)onditional UN/EDIFACT data elements (see description below), in the fourth column the restriction indicator, and in the fifth column notes and code values used for specific data elements in the message.

Status indicators

(M)andatory data elements or composites in UN/EDIFACT segments retain their status in EANCOM^®.

Additionally, there are five types of status with a (C)onditional UN/EDIFACT status, whether for simple, component or composite data elements. They are listed below and can be identified when relevant by the abbreviations.

If a composite is flagged as N, NOT USED, all data elements within that composite will have blank status indicators assigned to them.

Restriction indicators

• Restricted (*) - a data element marked with an asterisk (*) in the fourth column of the segment details of a message indicates that the listed codes in column five are the only codes available for use with the data element at the same level as the asterisk, in the current segment, in the current message.
  The reason for such restriction is to provide a subset of codes that may to be used in a given context. For example, in the BGM segment, only Document name codes (DE 1001) are restricted only to the values relevant for a given message. This restricted code set is different for every message.
• Open - all data elements in which coded representation of data is possible, and in which a restricted set of code values is not indicated, are open. The available codes are listed in the Data Elements and Code Sets Directory (Part III of this manual). Code values may be given as examples or there may be a note on the format or type of code to be used.

Different colours are used for the code values in the HTML segment details: restricted codes are in red and open codes in blue.

5.6. Message structure charts and branching diagrams

Within every EANCOM^® message two diagrams are presented which explain the structure and sequence of the message. These diagrams are known as the Message Structure Chart and the Message Branching Diagram.

The message structure chart is a sequential chart which presents the message in the sequence in which it must be formatted for transmission. Every message is structured and consists of three sections; a header, detail, and summary section. An example of a message structure chart follows:

The structure chart should always be read from top down and left to right (please note that the message detailed is simply an example message and does not bear any relevance to real EANCOM^® messages).

A message branching diagram is a pictorial representation (in flow chart style) which presents the logical sequence and relationships contained within a message.

Branching diagrams should be read, starting at the UNH segment, from left to right and top to bottom. The lines contained within a branching diagram should be considered as guides that must be followed in order to progress through the message.

5.7. Interchange structure and service segments

The interchange structure in an UN/EDIFACT transmission is organised through several grouping levels. The service segments are the envelope of the groups.

The first service segment possible in an interchange is the "UNA" segment which defines the service characters being used in the interchange.

The second service segment, "UNB", indicates the beginning of the interchange.

The next one, "UNG", indicates the beginning of a group of messages of the same type, or to create own identifiable application level envelope.

The last service segment, "UNH", indicates the beginning of a given message.

Each beginning service segment corresponds to an ending service segment (note: UNA is not a beginning segment).

• Service string advice: UNA
• Interchange envelope: UNB .... UNZ
• Group envelope: UNG .... UNE
• Message envelope: UNH .... UNT

The interchange can thus be represented like this:

Within the syntax 4 version of EANCOM^® the use of the UNA segment is not required.

Segment UNA is dependent on the character set being used. If the EANCOM^® default character set A is being used then the UNA segment is not required.

Segments UNB..UNZ and UNH..UNT are mandatory.

Segments UNG..UNE are conditional. Within EANCOM^® the use of the UNG..UNE segments should not be used for grouping of multiple message types in the same interchange as this is not considered good practice. However, they can be used by organisations to create their own identifiable application level envelopes, which can be addressed from the originating department to a department in the recipient's system, e.g. to group multiple issuers in one transmission file with invoices.

If the UNG..UNE segments are used, then it should be noted that it is not possible in the EANCOM^® CONTRL message to report syntactically on a functional group.

The message itself is structured with a Header, a Detail and a Summary section. In messages where there may be ambiguity between the sections, the UNS segment may be used as a separator.

The layout of the service segments UNA, UNB - UNZ, UNG - UNE, and UNH - UNT- used in EANCOM^® is presented in this section.The Section control segment (UNS), Anti-collision segment group header (UGH) and Anti-collision segment group trailer (UGT) are not shown here. Their usage is defined in those EANCOM^® messages where the segments are actually used.

 Segment Layout - UNA segment

Segment Layout - UNB segment

Segment Layout - UNG segment

Segment Layout - UNH segment

Segment Layout - UNT segment

Segment Layout - UNE segment

Segment Layout - UNZ segment

Example of an interchange:

An interchange contains two sets of messages: three Despatch Advices and two Invoices. The interchange is sent on 2 January 2002 by a company identified by the GLN 5412345678908 to a company identified by the GLN 8798765432106.

5.8. Digital signature in EANCOM^®

5.8.1. Introduction

Economic tendencies towards electronic business carried out over non-secure networks (such as Internet) require the use of additional measures to protect the information being sent and received. In order to successfully conduct any business activity over the net, a company should be considered by the consumers as a trusted entity that protects their identity and personal data (i.e. home address, credit card number,). The use of the digital signature, an optionally encryption techniques, within business boundaries and activities, constitutes a true value added tool and service that provides end-users with the enough degree of confidence towards the transactions they are involved in.

Signatures are commonly used to authenticate documents. Similarly, digital signatures are used to authenticate the content of electronic documents (EDI messages, PDF files, e-mail messages, and word processing documents). To digitally sign a document, you must have a digital certificate which can be obtained from various certification authorities. Once you have a digital certificate, the digital signature can be generated using any software that supports digital signatures.

The digital signature is simply a small block of data attached to documents you sign. It is generated from your digital certificate, which includes both a private and public key. The private key is used to apply the signature to the document, while the public key is sent with the file. The public key is used to check the integrity of the content.

5.8.2. Benefits

The use of the digital signature technique in EANCOM^® messages brings forward different value added services. Regarding to the electronic exchange over the net, Digital Signature techniques represent a real countermeasure and security solution to protect the information against most common threats. The use of the digital signature avoids:

• Content Integrity
  This solution protects against modification of the data exchanged.

  The sender applies an algorithm to the message before sending it to obtain an integrity control value that is included with in the message. The receiver applies the same algorithm to the received message (following the corresponding instructions) and the result must match the integrity value sent.

• Origin Authentication
  This solution protects the receiver against processing the data from a party claiming to be another party.

  Authentication codes are transmitted within the message to the receiver to ensure the identity of the sender. These authentication codes (digital certificate) are generated by a third authorised and trusted agent (Authority of Certification) and SHOULD be exchanged between the trading partners before any transaction takes place. The receiver validates that the digital signature values match the authentication codes contained in the digital certificate.

• Non-repudiation of Origin
  This solution protects the receiver of the message from the sender's denial of having sent the message.

  The sender digitally signs the message. The receiver uses the check code contained in the digital signature and the certificate associated to the sender to validate the message.

  Hence, if the message is valid, the sender must have sent it. There is no possibility that another party had generated that message without getting an error during the verification process.

• Non-repudiation of Receipt (if a response message is implemented)
  This solution protects the sender of a message from the receiver's denial of having received the message.

  The sender must request an acknowledgement from the receiver that the message has been received. The receiver should include with the acknowledgement a digital signature to guarantee the integrity of the acknowledge message and to authenticate the receivers identity.

5.8.3. Implementation Guideline

GS1 has developed a guide on how to secure EANCOM^® messages to highlight some possible safeguards available within the UN/EDIFACT standard. The decision to use security solutions in an EDI environment will depend on the data exchanged and the potential losses which might occur through the accidental or malicious corruption of a message.

Implementation Guideline of EANCOM^® Digital Signature is freely available at http://www.gs1.org/docs/ecom/eancom/eancom_Digital_Signature.pdf.

To date (January 2014), the obligation of use of digital signature depends on the legislation of each particular country. It is recommended that your local GS1 Member Organization should be contacted for further information.

5.9. Object segments

EANCOM^® offers the possibility to attach an object (an image, a report or a digital certificate) to any message using UNO-UNP segments. Segment UNO is used to head, identify and specify an object and segment UNP is used to end and check the completeness of an object.