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:

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:

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:

image503.gif

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®:

Apostrophe

'

= segment terminator

Plus sign

+

= segment tag and data element separator

Colon

:

= Component data element separator (separating simple data elements within a composite data element)

Question mark

?

= Release character which, when immediately preceding one of the service characters, restores that character's normal meaning. For example, 10?+10=20 means 10+10=20. Question mark is represented by ??

Asterisk

*

= repetition separator

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:

image504.gif

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.

5.2.6. Representation of numeric values

Numeric Class

Format

Integer Digit

Decimal Digit

Amounts

n..18

12

6

Control Values

n..18

14

4

Cubes

n..9

5

4

Currency Rates

n..12

6

6

Other Range Value

n..18

15

3

Percentages

n..10

6

4

Percentage Range Value

n..18

14

4

Quantities

n..15

12

3

Rate per Unit

n..15

12

3

Tax Rates

n..17

13

4

Unit Prices

n..15

11

4

Unit Price Basis

n..9

6

3

Weights

n..18

15

3

Example 1 (INVOIC)

image511.gif

Example 2 (INVOIC)

image512.gif

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: 

Letters, upper case

A to Z

Numerals 

0 to 9

Space character

 

Full stop

.

Comma

,

Hyphen/minus sign

-

Opening parentheses

(

Closing parentheses

)

Oblique stroke (slash)

/

Equal sign

=

Exclamation mark

!

Quotation mark

"

Percentage sign

%

Ampersand

&

Asterisk

*

Semi-colon

;

Less-than sign

Greater-than sign

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:

Number sign

#

Commercial at

@

Left square bracket

[

Reverse solidus

\

Right square bracket

]

Circumflex accent

^

Grave accent

`

Left curly bracket

{

Vertical line

|

Right curly bracket

}

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.

Syntax identifier

ISO standard

Languages

UNOA

646

 

UNOB

646

 

UNOC

8859 - 1

Danish, Dutch, English, Faeroese, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish, Swedish

UNOD

8859 - 2

Albanian, Czech, English, Hungarian, Polish, Romanian, Serbo-Croatian, Slovak, Slovene

UNOE

8859 - 5

Bulgarian, Byelorussian, English, Macedonian, Russian, Serbo-Croatian, Ukrainian

UNOF

8859 - 7

Greek

UNOG

8859 - 3

Maltese

UNOH

8859 - 4

Estonian, Latvian, Lithuanian, Greenlandic, Lappish

UNOI

8859 - 6

Arabic

UNOJ

8859 - 8

Hebrew, Yiddish

UNOK

8859 - 9

Turkish

UNOW

10646 - 1

ISO 10646-1 Octet with code extension technique to support UTF-8 (UCS Transformation Format, 8 bit) encoding.

UNOX

2022
2375

Character sets level C to K supported languages, Asian (e.g. Japanese, traditional Chinese language,...) and other languages that are based on character sets compliant with ISO 2022 and ISO 2375.

UNOY

10646 - 1

Aimed to cover all written languages of the world.

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:

Character type:

 

a :

alphabetic characters

n :

numeric characters

an :

alpha-numeric characters

Size:

 

Fixed :

all positions must be used

Variable :

positions may be used up to a specified maximum

Examples:

 

a3 :

3 alphabetic characters, fixed length

n3 :

3 numeric characters, fixed length

an3 :

3 alpha-numeric characters, fixed length

a..3 :

up to 3 alphabetic characters

n..3 :

up to 3 numeric characters

an..3 :

up to 3 alpha-numeric characters

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.

  •    

REQUIRED   

R

   -   

Indicates that the entity is required and must be sent.

  •    

ADVISED   

A

   -   

Indicates that the entity is advised or recommended.

  •    

DEPENDENT   

D

   -   

Indicates that the entity must be sent in certain conditions, as defined by the relevant explanatory note.

  •    

OPTIONAL   

O

   -   

Indicates that the entity is optional and may be sent at the discretion of the user.

  •    

NOT USED   

N

   -   

Indicates that the entity is not used and should be omitted.

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

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).

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

UNA - C 1 -

Service String Advice

Function :

The service string advice shall begin with the upper case characters UNA immediately followed by six characters in the order shown below. The same character shall not be used in more than one position of the UNA.

Segment number :

 

 

EDIFACT

GS1

*

Description

UNA1

Component data element separator

M an1

M

*

Used as a separator between component data elements contained within a composite data element (default value: ":")

UNA2

Data element separator

M an1

M

*

Used to separate two simple or composite data elements (default value: "+" )

UNA3

Decimal notation

M an1

M

*

Used to indicate the character used for decimal notation (default value:".")

UNA4

Release character

M an1

M

*

Used to restore any service character to its original specification (value: "?").

UNA5

Repetition separator

M an1

M

*

Used to indicate the character used for repetition separation (value: " * " ).

UNA6

Segment terminator

M an1

M

*

Used to indicate the end of segment data (default value: " ' ")

Segment Notes:

This segment is used to inform the receiver of the interchange that a set of service string characters which are different to the default characters are being used.

When using the default set of service characters, the UNA segment need not be sent. If it is sent, it must immediately precede the UNB segment and contain the four service string characters (positions UNA1, UNA2, UNA4 and UNA6) selected by the interchange sender.

Regardless of whether or not all of the service string characters are being changed every data element within this segment must be filled, (i.e., if some default values are being used with user defined ones, both the default and user defined values must be specified).

When expressing the service string characters in the UNA segment, it is not necessary to include any element separators.

The use of the UNA segment is required when using a character set other than level A.

Example:
UNA:+.?*' 

Segment Layout - UNB segment

UNB - M 1 -

Interchange Header

Function :

To identify an interchange.

Segment number :

 

 

EDIFACT

GS1

*

Description

S001

SYNTAX IDENTIFIER

M

M

.

See Part I chapter 5.2.7 and segment notes.

0001

Syntax identifier

M a4

M

*

UNOA = UN/ECE level A
UNOB = UN/ECE level B
UNOC = UN/ECE level C
UNOD = UN/ECE level D
UNOE = UN/ECE level E
UNOF = UN/ECE level F
UNOG = UN/ECE level G
UNOH = UN/ECE level H
UNOI = UN/ECE level I
UNOJ = UN/ECE level J
UNOK = UN/ECE level K
UNOW = UN/ECE level W
UNOX = UN/ECE level X
UNOY = UN/ECE level Y

0002

Syntax version number

M an1

M

*

4 = Version 4

0080

Service code list directory
version number

C an..6

N

.

0133

Character encoding, coded

C an..3

N

.

S002

INTERCHANGE SENDER

M

M

.

0004

Interchange sender identification

M an..35

M

.

GLN (n13)

0007

Identification code qualifier

C an..4

R

*

14 = GS1

0008

Interchange sender internal identification

C an..35

O

.

0042

Interchange sender internal sub-identification

C an..35

N

.

S003

INTERCHANGE RECIPIENT

M

M

.

0010

Interchange recipient identification

M an..35

M

.

GLN (n13)

0007

Identification code qualifier

C an..4

R

*

14 = GS1

0014

Interchange recipient internal
identification

C an..35

O

.

0046

Interchange recipient internal
sub-identification

C an..35

N

.

S004

DATE AND TIME OF
PREPARATION

M

M

.

0017

Date

M n8

M

.

CCYYMMDD

0019

Time

M n4

M

.

HHMM

0020

Interchange control reference

M an..14

M

.

Unique reference identifying the interchange. Created by the interchange sender.

S005

RECIPIENT REFERENCE/ PASSWORD DETAILS

C

O

.

0022

Recipient reference/password

M an..14

M

.

0025

Recipient reference/password qualifier

C an2

O

.

0026

Application reference

C an..14

O

.

Message identification if the interchange contains only one type of message.

0029

Processing priority code

C a1

O

.

A = Highest priority

0031

Acknowledgement request

C n1

O

.

1 = Requested

0032

Interchange agreement identifier

C an..35

O

*

EANCOM......

0035

Test indicator

C n1

O

.

1 = Interchange is a test

Segment notes :

This segment is used to envelope the interchange, as well as to identify both, the party to whom the interchange is sent and the party who has sent the interchange. The principle of the UNB segment is the same as a physical envelope which covers one or more letters or documents, and which details, both the address where delivery is to take place and the address from where the envelope has come.

S001: The character encoding specified in basic code table of ISO/IEC 646 (7-bit coded character set for information interchange) shall be used for the interchange service string advice (if used) and up to and including the composite data element S001 'Syntax identifier' in the interchange header. The character repertoire used for the characters in an interchange shall be identified from the code value of data element 0001 in S001 'Syntax identifier' in the interchange header. The character repertoire identified does not apply to objects and/or encrypted data.

The default encoding technique for a particular repertoire shall be the encoding technique defined by its associated character set specification.

DE 0001: The recommended (default) character set for use in EANCOM® for international exchanges is character set A (UNOA). Should users wish to use character sets other than A, an agreement on which set to use should be reached on a bilateral basis before communications begin.

DE 0004, 0008, 0010, 0014, 0042 and 0046: Within EANCOM® the use of the Global Location Number (GLN) is recommended for the identification of the interchange sender and recipient.

DE 0008: Identification (e.g. a division) specified by the sender of the interchange, to be included if agreed, by the recipient in response interchanges, to facilitate internal routing.

DE 0042: Sub-level of sender internal identification, when further sub-level identification is required.

DE 0014: The address for routing, provided beforehand by the interchange recipient, is used by the interchange sender to inform the recipient of the internal address, within the latter's systems, to which the interchange should be routed. It is recommended that the GLN be used for this purpose.

DE 0007: Identification (e.g. a division) specified by the recipient of the interchange, to be included if agreed, by the sender in response interchanges, to facilitate internal routing.

DE 0046: Sub-level of recipient internal identification, when further sub-level identification is required.

DE S004: The date and time specified in this composite should be the date and time at which the interchange sender prepared the interchange. This date and time may not necessarily be the same as the date and time of contained messages.

DE 0020: The interchange control reference number is generated by the interchange sender and is used to identify uniquely each interchange. Should the interchange sender wish to re-use interchange control reference numbers, it is recommended that each number be preserved for at least a period of three months before being re-used. In order to guarantee uniqueness, the interchange control reference number should always be linked to the interchange sender's identification (DE 0004).

DE S005: The use of passwords must first be agreed bilaterally by the parties exchanging the interchange.

DE 0026: This data element is used to identify the application, on the interchange recipient's system, to which the interchange is directed. This data element may only be used if the interchange contains only one type of message, (e.g. only invoices). The reference used in this data element is assigned by the interchange sender.

DE 0031: This data element is used to indicate whether an acknowledgement to the interchange is required. The EANCOM® APERAK or CONTRL message should be used to provide acknowledgement of interchange receipt. In addition, the EANCOM® CONTRL message may be used to indicate when an interchange has been rejected due to syntax errors.

DE 0032: This data element is used to identify any underlying agreements which control the exchange of data. Within EANCOM® , the identity of such agreements must start with the letters 'EANCOM', the remaining characters within the data element being filled according to bilateral agreements.

Example :

UNB+UNOC:4+5412345678908:14+8798765432106:14+20020102:1000+12345555+++++EANCOMREF 52'

Segment Layout - UNG segment

UNG - C 1 -

Functional Group Header

Function :

To start, identify and specify a functional group.

Segment number :

 

 

EDIFACT

GS1

*

Description

0038

FUNCTIONAL GROUP IDENTIFICATION

M an..6

M

 

Identification of a message contained in the functional group, e.g. INVOIC.

S006

APPLICATION SENDER’S IDENTIFICATION

M

M

 

 

0040

Sender identification

M an..35

M

 

GLN (n13)

0007

Identification code qualifier

C an..4

R

*

14 = GS1

S007

INTERCHANGE RECIPIENT

M

M

 

 

0044

Recipient identification

M an..35

M

 

GLN (n13)

0007

Identification code qualifier

C an..4

R

*

14 = GS1

S004

DATE / TIME OF PREPARATION

M

M

 

 

0017

Date

M n6

M

 

YYMMDD

0019

Time

M n4

M

 

HHMM

0048

Functional group reference number

M an..14

M

 

Unique reference identifying the functional group. Created by the interchange sender.

0051

Controlling agency

M an..2

M

*

UN = UN/CEFACT

S008

MESSAGE VERSION

M

M

 

 

0052

Message type version number

M an..3

M

*

D = UN/EDIFACT directory

0054

Message type release number

M an..3

M

 

The value of this data element depends on the message type.

0057

Association assigned code

C an..6

R

 

The value of this data element depends on the message type.

0058

Application password

C an..14

D

 

The use of this data element depends on agreements between the trading partners.

Segment notes :

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.

Example :

UNG+INVOIC+5412345678908:14+8798765432106:14+20020102:1000+471123+UN+D:01B:EAN010'

Segment Layout - UNH segment

UNH - M 1 -

MESSAGE HEADER

Function :

To head, identify and specify a message.

Segment number :

 

 

EDIFACT

GS1

*

Description

0062

Message reference number

M an..14

M

Unique reference number assigned to a message within an interchange by the sender. Same reference number as in DE 0062 of the UNT segment of the message.

S009

MESSAGE IDENTIFIER

M

M

0065

Message type

M an..6

M

*

Identification of a message.

0052

Message version number

M an..3

M

*

D = UN/EDIFACT Directory

0054

Message release number

M an..3

M

*

01B = Release 2001 - B

0051

Controlling agency

M an..2

M

*

UN = UN/CEFACT

0057

Association assigned code

C an..6

R

*

EANnnn = EANCOM® subset version. EAN represents GS1. "nnn" is the subset version number of the EANCOM® message.

0110

Code list directory version number

C an..6

O

E4yyyy = EANCOM® code list version number.
"E" represents GS1.
"4" stands for ISO 9735-Syntax version 4.
"yyyy" is the year of publication.

0113

Message type sub-function
identification

C an..6

N

0068

Common access reference

C an..35

N

S010

STATUS OF THE
TRANSFER

C

N

0070

Sequence of transfers

M n..2

0073

First and last transfer

C a1

 

S016

MESSAGE SUBSET
IDENTIFICATION

C

N

 

0115

Message subset identification

M an..14

 

0116

Message subset version
number

C an..3

 

0118

Message subset release
number

C an..3

 

0051

Controlling agency, coded

C an..3

 

S017

MESSAGE IMPLEMENTATION
GUIDELINE IDENTIFICATION

C

N

 

0121

Message implementation
guideline identification

M an..14

 

0122

Message implementation
guideline version number

C an..3

 

0124

Message implementation
guideline release number

C an..3

 

0051

Controlling agency, coded

C an..3

 

S018

SCENARIO IDENTIFICATION

C

N

 

0127

Scenario identification

M an..14

 

0128

Scenario version number

C an..3

 

0130

Scenario release number

C an..3

 

0051

Controlling agency, coded

C an..3

 

 

Segment Notes :

This segment is used to head and uniquely identify a message in an interchange.

DE 0062: It is good practice to have the message reference number both unique and incremental.

S009: Identification of an EANCOM® message.

The content of data elements 0065, 0052, 0054 and 0051 must be taken from the related UN/EDIFACT standard message.  

The content of data element 0057 is assigned by GS1 as part of the EANCOM® maintenance process.

DE 0065: Data element 0065 identifies a UN/EDIFACT message whereas the exact usage of the message is specified in BGM data element 1001. E.g. UN/EDIFACT invoice message serving as a credit note: UNH DE 0065 = INVOIC, BGM DE 1001 = 381.

DE 0110: This data element can be used by the trading partners to identify an EANCOM® code list, different from the code list published as an integral part of EANCOM® syntax version 4, 2002 release, they have mutually agreed to use when interchanging a message.

The combination of the values carried in the data elements 0062 and S009 shall be used to uniquely identify the message within the interchange for the purpose of acknowledgement (ref. UNB - data element 0031).

Example :

UNH+1+INVOIC:D:01B:UN:EAN010'

Segment Layout - UNT segment

UNT - M 1 -

MESSAGE TRAILER

Function :

To end and check the completeness of a message.

Segment number :

 

EDIFACT

GS1

*

Description

0074

Number_of style='color:white'>_segments in the message

M n..10

M

.

Total number of segments in a message.

0062

Message_reference style='color:white'>_number

M an..14

M

.

Same reference number as in DE 0062 of the UNH segment of the message.

Segment Notes :

This segment is used to end and provide information for checking the completeness of a message.

The segment number shows the position of the segment in a message. It must always be the last segment in a message.

DE 0074: Count of all segments in a message, UNH and UNT included.

Example :

UNT+103+1'

Segment Layout - UNE segment

UNE - C 1 -

FUNCTIONAL GROUP TRAILER

Function :

To end and check the completeness of a functional group.

Segment number :

 

 

EDIFACT

GS1

*

Description

0060

Number of messages

M n..6

M

 

Number of messages in the group.

0048

Functional group reference number

M an..14

M

 

Identical to DE 0048 in UNG segment.

Segment Notes :

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.

Example :

UNE+25+471123'

Segment Layout - UNZ segment

UNZ - M 1 -

INTERCHANGE TRAILER

Function :

To end and check the completeness of an interchange.

Segment number :

 

EDIFACT

GS1

*

Description

0036

Interchange control count

M n..6

M

.

Number of messages or functional

groups within an interchange.

0020

Interchange control reference

M an..14

M

. lang=EN-GB style='color:red'>

Identical to DE 0020 in UNB segment.

Segment Notes :

This segment is used to provide the trailer of an interchange.

DE 0036: If functional groups are used, this is the number of functional groups within the interchange. If functional groups are not used, this is the number of messages within the interchange.

Example :

UNZ+5+12345555'

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.

Unbenannt.GIF

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:

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.

Segment number: 1

UNO - M 1 -

Object header

Function:

To head, identify and specify an object.

 

EDIFACT

GS1

*

Description

0800

Package reference number

M an..35

M

 

Unique package reference number assigned by the sender

S020

REFERENCE IDENTIFICATION

M

M

 

 

0813

Reference qualifier

M an..3

M

*

1= Object identification number

0802

Reference identification number

M an..35

M

 

Reference number to identify a group which relates to the object.

S021

OBJECT TYPE IDENTIFICATION

M

M

 

 

0805

Object type qualifier

M an..3

M

 

48 = Filter type

0809

Object type attribute identification

C an..256

R

 

EDA = UN/EDIFACT EDA filter

EDC = UN/EDIFACT EDC filter

HEX = Hexadecimal filter

0808

Object type attribute

C an..256

N

 

 

0051

Controlling agency, coded

C an..3

N

 

 

S021

OBJECT TYPE IDENTIFICATION

M

M

 

 

0805

Object type qualifier

M an..3

M

 

62 = Certificate format

0809

Object type attribute

identification

C an..256

R

 

PCKS7 = PKCS#7 format including the whole certification path if wished.

0808

Object type attribute

C an..256

N

 

 

0051

Controlling agency, coded

C an..3

N

 

 

S022

STATUS OF THE OBJECT

M

M

 

 

0810

Length of object in octets of bits

M n..18

M

 

Length of the object attached in bytes

0814

Number of segments before object

C n..3

N

 

 

0070

Sequence of transfers

C n..2

N

 

 

0073

First and last transfer

C a1

N

 

 

S302

DIALOGUE REFERENCE

C

N

 

 

0300

Initiator control reference

M an..35

N

 

 

0303

Initiator reference identification

C an..35

N

 

 

0051

Controlling agency, coded

C an..3

N

 

 

0304

Responder control reference

C an..35

N

 

 

S301

STATUS OF TRANSFER - INTERACTIVE

C

N

 

 

0320

Sender sequence number

C n..6

N

 

 

0323

Transfer position, coded

C a1

N

 

 

0325

Duplicate Indicator

C a1

N

 

 

S300

DATE AND/OR TIME OF INITIATION

C

N

 

 

0338

Event date

C n..8

N

 

 

0314

Event time

C an..15

N

 

 

0336

Time offset

C n4

N

 

 

0035

Test indicator

C n1

N

 

 

Segment Notes:

This segment is used to head, identify and specify an object.

The digital certificate will be attached using PKCS#7 format because it allows including more than one digital certificate (User Certificate and the Certification Chain).  This file will be filtered using EDC or Hexadecimal filter.

Once the file is filtered, the total number of bytes of the object to be attached will be obtained and detailed in DE0810.

Example:

UNO+OB000001+1:CER123+46:EDC*62:PKCS7+1238'

 

Segment number: 2

UNP - M 1 -

Object trailer

Function:

To end and check the completeness of an object.

 

EDIFACT

GS1

*

Description

0810

Length of object in octets of bits

M n..18

M

 

This Data Element shall be identical to DE0810 of UNO segment.

0800

Package reference number

M an..35

M

 

This Data Element shall be identical to DE0800 of UNO segment.

Segment Notes:

To end and check the completeness of an object.

Example:

UNP+1238+OB000001'

 

© Copyright GS1 Edition 2016