EANCOM® 2002 S3, 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 3 overview

This section is a summary of the document: "EDIFACT - Application level syntax rules (Syntax version 3)". 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.

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 ??

Within EANCOM® 2002 syntax 3 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 F

Character sets level C to F (ISO 8859 - 1,2,5,7 8-bit single byte coded graphic character sets) cover the Latin 1 - 2, Cyrillic and Greek 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

}

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 part of ISO-8859.

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

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