Skip to main content

Part 4. UN/EDIFACT Rules - Chapter 2.2 Syntax Rules

CHAPTER 2.2 - Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules

 

Table of Contents

 

FOREWORD

INTRODUCTION

1. SCOPE

2. NORMATIVE REFERENCES

3. DEFINITIONS

4. SYNTAX LEVELS

5. CHARACTER SETS

5.1 Level A Character Set
 

5.2 Level B Character Set

6. STRUCTURES

6.1 Interchange Structure

6.2 Order of Segments and Groups of Segments within a Message

6.3 Segment Structure

6.4 Data Element Structure
7. COMPRESSING

7.1 Exclusion of Segments

7.2 Exclusion of Data Elements by Omission

7.3 Exclusion of Data Elements by Truncation

7.4 Exclusion of Component Data Elements by Omission

7.5 Exclusion of Component Data Elements by Truncation

8. REPETITION

8.1 Repetition of Segments

8.1.1 Explicit Indication of Repetition

8.1.2 Implicit Indication of Repetition

8.2 Repetition of Data Elements

9. NESTING OF SEGMENTS

9.1 Explicit Indication of Nesting

9.2 Implicit Indication of Nesting
10. REPRESENTATION OF NUMERIC DATA ELEMENT VALUES

10.1 Decimal Sign

10.2 Triad Separator

10.3 Sign

FOREWORD
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. Amended reprint, 1990
This amended reprint has been prepared to correct two ambiguities in the original text. These concern segments UNG, S0008, and UNH, S0009. The convention for assigning message version number and message release number include the last two digits of the year. In order to avoid compression of leading zeroes in these fields, which is a normal procedure in many computer programs when the data type is specified to be numeric, and which would consequently distort the data, the data types for message version number and message release number have been changed from numeric (n) to alphanumeric (an). Additionally, experience has shown that the foot note which appears on page 17 of the 1988 edition has been misunderstood and in order to provide clarification, the footnotehas now been deleted and the status of of the message release number (0054) and controlling agency (0051) has been changed from conditionalto mandatory. In order to allow time for users to change their systems, and to provide a specific date for implementation of the changes, this amended and reprinted edition will become effective six months after publication, i.e. 1 May 1991.

INTRODUCTION


This International Standard includes, in a condensed form, therules on application level for the structuring of the user data andof the associated service data in the interchange of messages in anopen environment. These rules have been agreed by the United NationsEconomic Commission for Europe (UN/ECE) as syntax rules for Electronic Data Interchange For administration, Commerce and Transport (EDIFACT) and are part of the ECE Trade Data Interchange Directory which also includes Message Design Guidelines*). The Guidelines should be used in conjunction with this standard.The service specifications and protocols for Open Systems Inter-connection (OSI) based on the Reference Model in ISO 7498 and issuedby ISO, ITU-T, CEN/CENELEC etc. may be followed for the communicationof messages based on this standard. Such specifications and protocolsare outside the scope of this standard.Functional error indication/correction can be handled by specialservice messages following the syntax rules in this InternationalStandard. Normative annexes: Informative annex:A. Terminology C. Order of segments and groups of segments within a messageB. Service segment specifications

1. SCOPE


 This International Standard gives syntax rules for the preparation of messages to be interchanged between partners in the fields of administration, commerce and transport.

2. NORMATIVE REFERENCES


The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

ISO 31/0-1981      General principles concerning quantities, units and symbols
ISO 646-1983       Information processing - ISO 7-bit coded character set for information interchange
ISO 2382/1-1984  Data processing - Vocabulary - Part 01: Fundamental terms ISO 2382/4-1987 Data processing - Vocabulary - Section 04: Organization of data
ISO 6523-1984     Data interchange - Structures for the identification of organizations
ISO 6947/2-1983  Information processing - Coded character sets for text communication
ISO 7372-1986     Trade Data Elements Directory, (UNTDED)
ISO 7498-1984     Open Systems Interconnection - Basic Reference Model
ISO 8859-1987     Information processing - 8-bit single byte coded graphic character sets

3. DEFINITIONS


For the purpose of this International Standard, the definitionsin annex A apply.

4. SYNTAX LEVELS


This International Standard specifies syntax levels A and B whichare identical in all respects except for the character sets used. Asrequirements for additional syntactical features appear, furtherlevels may be added.Unless interchange partners agree to use other or additionalcharacters, level A shall use only the character set specified inclause 5.1, and level B only the character set specified in clause 5.2.The conditional Service String Advice, UNA, (see Annex B) providesthe capability to specify the separator and other service charactersused in the interchange in case they differ from those in clause 5.

5. CHARACTER SETS


For the characters in the sets below, the 7-bit codes in the basic ISO 646 standard shall be used, unless the corresponding 8-bit codes in ISO 6947 and 8859 or other bit codes are specifically agreed
between the interchanging partners. See clause 4.

5.1 Level A Character Set

 
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)  /
Equals sign  =
    Reserved for use as:
Apostrophe segment terminator
Plus sign  + segment tag and data element separator
Colon  : component data element separator
Question mark ? release character
?  immediately preceding one of the characters ' + : ?   restores their normal meaning.
e.g. 10?+10=20 means 10+10=20. Question mark is represented by ??.

  
The following characters are part of the level A character  set but cannot be used internationally in telex  transmissions:
 
Exclamation mark  !
Quotation mark  "
Percentage sign  %
Ampersand &
Asterisk *
Semi-colon  ;
Less-than sign <
Greater-than sign >

5.2 Level B Character Set



This character set is not intended for transmission to telex machines.
Letters, upper case A to Z
Letters, lower case a to z
Numerals 0 to 9
Space character  
Full stop .
Comma ,
Hyphen/minus sign  -
Opening parentheses (
Closing parentheses )
Oblique stroke (slash) /
Apostrophe '
Plus sign +
Colon  :
Equals sign =
Question mark ?
Exclamation mark !
Quotation mark "
Percentage sign  %
Ampersand &
Asterisk  *
Semi-colon ;
Less-than sign <
Greater-than sign >

Information separator IS 4 segment terminator Information separator IS 3 data element separator Information separator IS 1 component data element separator

6. STRUCTURES

 

6.1 Interchange Structure



The Service String Advice, UNA, and the service segments UNB to UNZ shall appear in the below stated order in an interchange. There may be several functional groups or messages within an  interchange and several messages in a functional group. A message consists of segments. The structures for segments and for data elements therein are shown in 6.2 and 6.3. The contents of the service segments are shown Annex B.  See also Figure 1.
An interchange consists of:
            Service String Advice     UNA   Conditional
     _____  Interchange Header        UNB   Mandatory
    |  ___  Functional Group Header   UNG   Conditional
    | |  _  Message Header            UNH   Mandatory
    | | |   User Data Segments              As required
    | | |_  Message Trailer           UNT   Mandatory
    | |___  Functional Group Trailer  UNE   Conditional
    |_____  Interchange Trailer       UNZ   Mandatory
 
 -----------------------------------------
 |Establishment |CONNECTION| Termination | A CONNECTION contains one
 --------------------|--------------------   or more interchanges.
                     |                       The technical protocols
                     |                       for establishment
                     |                       maintenance and
                     |                       termination etc. are not
 +-------------------+-------------------+   part of this standard.
 |                                       |
 -----------------------------------------
 |Interchange |INTERCHANGE |Interchange  | An INTERCHANGE contains:
 -------------------|--------------------- - UNA, Service string
                    |                             advice, if used
                    |                      - UNB, Interchange header
                    |                      - Either only Functional
                    |                        groups, if used, or
                    |                        only Messages
                    |
 .....--------------+--------------------+ - UNZ, Interchange
 .   |                                   |        trailer
 -----------------------------------------
 |UNA|UNB|'|    Either    |or only |UNZ|'| A FUNCTIONAL GROUP
 |   |   | |FUNCTION.GRPS |MESSAGES|   | | contains:
 -----------------|----------.------------ - UNG, Functional group
                  |          .               header
                  |          .             - Messages of the same
 +----------------+----------.-----------+   type
 |               +........+..+           | - UNE, Functional group
 |               .        .              |   trailer
 -----------------------------------------
 |UNG |'|Message |MESSAGE |Message |UNE|'| A MESSAGE contains:
 --------------------|-------------------- - UNH, Message header
                     |                     - Data segments
 +-------------------+-------------------+ - UNT, Message trailer
 |                                       |
 -----------------------------------------
 |UNH |'|Data    |DATA    |Data    |UNT|'| A SEGMENT contains:
 |    | |segment |SEGMENT |segment |   | | - A Segment TAG  
 -------------------|--------------------- - Simple data elements or
                    |                      - Composite data elements
 +------------------+-------------------+    or both as applicable
 |                                      |
 ----------------------------------------
 |TAG |+|SIMPLE       |+|COMPOSITE    |'|  A SEGMENT TAG contains:
 |    | |DATA ELEMENT | |DATA ELEMENT | |  - A segment code and,  
 ---|--------------|----------|-----|----    if explicit indication,
    |              |          |     |        repeating and nesting
    |              |          |     |        value(s). See 8.1 and 9.
    |              |          |     |  
    |              |          |     |      A SIMPLE DATA ELEMENT
 --------------   -------   -------------  contains:
 |Code|:|Value|   |Value|   |COMP|:|COMP|  - A single data element
 --------------   -------   |D/E | |D/E |    value
                            |    | |    |  A COMPOSITE DATA ELEMENT
                            --|------|---  contains:
                              |      |     - Component data elements
                           ------- -------
                           |     | |     | A COMPONENT DATA ELEMENT
                           |Value| |Value| contains:
                           ------- ------- - A single data element
                                             value

 

 
 
      --.--                  --|--
        . means alternative to |


In addition to the above service segments, the service segment UNS can, when required, be used to divide a message into sections. See Annex B.
Figure 1 - Hierarchical structure of an interchange UNA, UNB, UNZ, UNG, UNE, UNH and UNT are Service segments, see 6.1 and Annex B.

In the diagram, the level A separators/terminators have been used, see 5.1.


 

6.2 Order of Segments and Groups of Segments within a Message


A message structure diagram and the order of the segments following the processing rules in the ECE Message Design Guidelines is shown in annex C.

6.3 Segment Structure

 

Segment Tag, composed of
  Segment Code

Mandatory
Mandatory component data element

  Component data element separator
  Nesting and repeating indication

Conditional
Conditional component data element (s)

Data element separator
Simple or composite data elements

Mandatory
Mandatory or conditional as specified in the relevant segments directory, see 6.4

Segment Terminator

Mandatory




 

6.4 Data Element Structure



Simple Data Element, or                     Mandatory or conditional as specified in the relevant segments directory
Composite Data Element 
with
Component data elements and
Component data element separators   Mandatory (see restriction below)
Data element separator                      Mandatory (see restriction below)



There shall be no component data element separator after the last component data element in a composite data element and no data element separator after the last data element in a segment.

7. COMPRESSING


In data elements for which the Data Elements Directory specifies variable length and there are no other restrictions, insignificant character positions shall be suppressed. In the case of insignificant characters, leading zeroes and trailing spaces shall be suppressed.
Note, however, that a single zero before a decimal mark is significant (see clause 10.1) and that a zero may be significant (e.g. to indicate a temperature) if so stated in the data elements specification.
When compressing messages, the rules below shall be followed.
In the following examples of the rules, "Tag" represents a segment tag, "DE" a data element and "CE" a component data element. The separators in level A in clause 5.1 are used.

7.1 Exclusion of Segments


Conditional segments containing no data shall be omitted (including their segment tags).

7.2 Exclusion of Data Elements by Omission


Data elements are identified by their sequential positions within the segment as stated in the Segment Directory. If a conditional data element is omitted and is followed by an other data element, its position shall be indicated by retention of its data element separator
Tag+DE+DE+++DE+DE+DE' 
          ||_________ These two data elements are omitted

7.3 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, i.e. contiguous trailing data element separators are not required to be transmitted.
    Tag+DE+DE+++DE'  Using the example from 7.2, the last two
                 |   data elements have been omitted and
                 |__ the segment truncated


7.4 Exclusion of Component Data Elements by Omission


Component data elements are identified by their given sequential positions within a composite data element. If a conditional component data element is omitted and is followed by another component data element, its given position must be represented by its component data element separator.
    Tag+DE+CE:CE+CE:::CE'    Two component data elements omitted
                    ||______ in the last composite data element


7.5 Exclusion of Component Data Elements by Truncation


One or more conditional component data elements at the end of a composite data element may be excluded by truncation by the data element separator or, if at the end of a segment, by the segment terminator.
    Tag+DE+CE+CE'   Using the example from 7.4, the last
             |  |   component data element in the first composite
             |  |   data element has been omitted and also three
             |  |   component data elements in the last composite
             |  |   data element. In both cases the composite
             |  |   data elements have been truncated, indicated
             |  |   in the first case by the data element
             |  |   separator and in the second case by the
             |__|__ segment terminator.
 

 
 

8. REPETITION


8.1 Repetition of Segments


Within a given message type, either explicit or implicit repetition techniques shall be used and this decision shall be taken during message design. The two techniques shall not be mixed within the same message.
Indication of repetition shall either be explicit as a component data element being part of the segment tag composite data element that heads a segment (see clauses 8.1.1 and 9.1) or be implicitly understood from the sequence of the segments as stated in the relevant message specification (see clause 8.1.2).
Segments at level 0 (see annex C) shall not be repeated and their tags include no repeating indication.
Service segments (see annex B), excluding TXT, shall not be repeated and their tags include no repeating indication.
8.1.1 Explicit indication of repetition In the segment tag, the first component data element shall be the segment code and the last of the subsequent component data elements shall indicate the incidence of repetition of the segment. See clause 9.1.
8.1.2 Implicit indication of repetition The segments within a message shall appear in the order stated in the message type specification. Therefore it can be implicitly understood which segments are repeated, identified by their ordinal positions.

8.2 Repetition of data elements



Data elements (DE) shall not be repeated within a segment more than the number of times prescribed in the relevant segment directory. If less, the exclusion rules in clauses 7.2 to 7.5 shall apply.
    Tag+...+DE1+DE1+++...'
                    ||  2 of prescribed up to 4 repeats of DE1
                    ||_ omitted.

It is, however, sometimes practical to structure repeatable elements as component data elements (CE) in composite elements, thereby allowing truncation by the data element separator. This may also apply to specified repeatable sequences of data elements, e.g. the sequence CE1:CE2:CE3.
    Tag+...+CE1:CE2:CE3:CE1:CE2:CE3+...'
                                   |  Truncation by the data
                                   |  element separator after
                                   |_ 2 sequences.

9. NESTING OF SEGMENTS


A segment may depend on a segment on a higher hierarchical level in the message structure and consequently be nested in that segment.
Within a given message type, either explicit or implicit nesting techniques shall be used and this decision shall be taken during message design. The two techniques shall not be mixed within the same message.
Indication of nesting shall either be explicit as component data elements being part of the segment tag composite data element that heads a segment (see clause 9.1) or be implicitly understood from the sequence of the segments as stated in the relevant message specification *) (see clause 9.2).
Service segments (see annex B) and other segments at level 0 (see annex C) shall not be nested and their tags include no nesting indication.

9.1 Explicit Indication of Nesting


In the segment tag, the first component data element shall be the segment code and be followed by conditional component data elements indicating both the level and the incidence of repetition of the segment as stated in clause 8.1.1.
The number of component data elements used for this purpose depends upon the hierarchical level in which the segment appears in the message structure diagram. See annex C. After the segment code, the next component data element (which is for the first control count) shall be used if the segment appears at level one, the second as well if it appears at level two, the third as well at level 3 etc.
When a conditional segment on a higher level is not used in an application, the level indication shall show component data element separators for the levels not used and the segment shall appear before segments which include an indication at that level. See example below.
*) See Message Design Guidelines
EXAMPLES of messages using explicit repeating and nesting indication
Level A separators have been used in the examples. See Annex C for further diagram explanations.
EXAMPLE 1. Message with one level of mandatory segment nesting:
    Level                 Message

            __________________________________
            |    |    |        |        |    |
      0    UNH  AAA   |      __|__     EEE  UNT
           M 1  M 1   |      |   |     C 1  M 1
      1              BBB     |CCC|
                     M 2     |M 1|
                             | | |
                             | | |
      2                      |DDD|
                             |M 9|
                             |___|
                             |M 2|
                             |___|
    
     Segments              Explanations
    
     UNH+data'
     AAA+data'
     BBB:1+data'         Item 1 of BBB
     BBB:2+data'         Item 2 of BBB
     CCC:1+data'         Item 1 of CCC
     DDD:1:1+data'       Item 1 of DDD in CCC(1)
     DDD:1:2+data'       Item 2 of DDD in CCC(1)
     CCC:2+data'         Item 2 of CCC
     DDD:2:1+data'       Item 1 of DDD in CCC(2)
     EEE+data'
     UNT+data'
    

    In string form:

    UNH+dat'AAA+data'BBB:1+data'BBB:2+data'CCC:1+data'DDD:
    1:1+data'DDD:1:2+data'CCC:2+data'DDD:2:1+data'EEE+data'
    UNT+data'

    EXAMPLE 2 - Message with two levels of conditional segment
    nesting which could be containers (CCC), boxes (DDD) and
    goods items (EEE):

    Level                 Message
            _____________________________
            |    |    |        |        |
      0    UNH  AAA   |      __|__     UNT
           M 1  M 1   |      |   |     M 1
      1              BBB     |CCC|
                     M 2     |C 1|
                             | | |
                             | | |
      2                      |DDD|
                             |C 9|
                             | | |
                             | | |
      3                      |EEE|
                             |M 9|
                             |___|
                             |M20|
                             |___|


     Segments        Explanations

     UNH+data'
     AAA+data'
     BBB:1+data'     Item 1 of BBB
     BBB:2+data'     Item 2 of BBB
     EEE:::1+data'   Item 1 of EEE without DDD and CCC
     EEE:::2+data'   Item 2 of EEE without DDD and CCC
     CCC:1+data'     1st occurrence of CCC
     DDD:1:1+data'   1st occurrence of DDD within CCC(1)
     EEE:1:1:1+data' EEE(1) within DDD(1) within CCC(1)
     EEE:1:1:2+data' EEE(2) within DDD(1) within CCC(1)
     DDD:1:2+data'   DDD(2) within CCC(1)
     EEE:1:2:1+data  EEE(1) within DDD(2) within CCC(1)
     CCC:2+data'     CCC(2)
     EEE:2::1+data'  EEE(1) within CCC(2) without DDD
     UNT+data
    
    In string form:
    
    UNH+data'AAA+data'BBB:1+data'BBB:2+data'EEE:::1+data'EEE:
    ::2+data'CCC:1+data'DDD:1:1+data'EEE:1:1:1+data'EEE:1:1:
    2+data'DDD:1:2+data'EEE:1:2:1+data'CCC:2+data'EEE:2::1+
    data'UNT+data'
 

 
 

9.2 Implicit Nesting Indication


The order of the segments specified in the message structure diagram (top to bottom, left to right) shall be followed strictly. Thereby the nesting relation between the segments is implicitly evident and no further indication is required for processing.

10. REPRESENTATION OF NUMERIC DATA ELEMENT VALUES

 

10.1 Decimal Mark

 

The ISO representation for decimal mark is the comma ( , ) but point on the line ( . ) is allowed. See ISO 31/0-1981. Both these characters are part of the Level A and B sets in clause 5 and both alternatives are allowed.


When the Service string advice, UNA, is used, its third character specifies the one character used in the interchange to represent decimal mark and thus overrides the above alternative use.
The decimal mark shall not be counted as a character of the value when computing the maximum field length of a data element. However, allowance has to be made for the character in transmission and reception.
When a decimal mark is transmitted, there shall be at least one digit before and after the decimal mark. For values represented by integers only, neither decimal mark nor decimal zeroes are used unless there is a need to indicate the degree of precision.
Preferred 0,5 and 2 and 2,0
Allowed 0.5 and 2 and 2.0
Not allowed: ,5 or .5 or 2, or 2.
 

10.2 Triad Separator


Triad separators shall not be used in interchange.
Allowed: 2500000
Not allowed: 2,500,000 or 2.500.000 or 2 500 000
 

10.3 Sign


 Numeric data element values shall be regarded as positive.
 Although conceptually a deduction is negative, it shall be represented by a positive value and such cases shall be indicated in the data elements directory.
 If a value is to be indicated to be negative, it shall in transmission be immediately preceded by a minus sign e.g. -112.
 The minus sign shall not be counted as a character of the value when computing the maximum field length of a data element. However, allowance has to be made for the character in transmission and reception.