Distr.
RESTRICTED

TRADE/WP.4/R.1157
19 September 1995

ENGLISH ONLY
ECONOMIC COMMISSION FOR EUROPE
COMMITTEE ON THE DEVELOPMENT OF TRADE

 Working Party on Facilitation of
 International Trade Procedures
 (Item 3 of the provisional agenda
 of the Meeting of Experts on Data
 Elements and Automatic Data Interchange(GE.1)
 Fifty-third session, 18-19 March 1996)

* * *

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

Part 1:
Syntax rules common to both batch and
interactive EDI


* The present document is reproduced in the form in which it was received by the secretariat.


  

Contents

                                                Page

Foreword                                          4

Introduction                                      5

1  Scope                                          6

2  Conformance                                    6

3  References                                     6

4  Definitions                                    7

5  Service characters                             7

6  Character repertoires                          8

7  Syntax structures                              8

8  Inclusion and exclusion                        10

9  Suppression of characters within data elements 13

10 Representation of numeric data element values  14

11 Dependency notes                               14

Annex A: Definitions                              16

Annex B: UNA service string advice                21

Annex C: Order of segments and groups of segments
         within a message                         22
           
           
           
           
           
           
           
           
           Foreword
           
           
           (Foreword to be added)
           
           In this Part 1, annexes A and B form an integral part of
           this International Standard.
           Annex C is for information only.








Introduction

This International Standard includes the rules at the application level
for the structuring of data in the interchange of electronic messages
in an open environment, based on the requirements of either batch or
interactive processing.  These rules have been agreed by the United
Nations Economic Commission for Europe (UN/ECE) as syntax rules for
Electronic Data Interchange for Administration, Commerce and Transport
(EDIFACT) and are part of the United Nations Trade Data Interchange
Directory (UNTDID) which also includes both batch and interactive
Message Design Guidelines.

These syntax rules may be used in any application, but messages using
these rules may only be referred to as EDIFACT messages if they comply
with other guidelines, rules and directories in UNTDID.

Communications specifications and protocols are outside the scope of
this standard.

UN/EDIFACT CD 9735 consists of eight parts:

                          UN/EDIFACT CD 9735-1     -    Syntax rules
                          common to both batch and interactive EDI

                          UN/EDIFACT CD 9735-2     -    Syntax rules
                          specific to batch EDI, plus batch EDI service
                          directories

                          UN/EDIFACT CD 9735-3     -    Syntax rules
                          specific to interactive EDI, plus interactive
                          EDI service directories

                          UN/EDIFACT CD 9735-4     -    Syntax and
                          service report message for batch EDI (Message
                          type - CONTRL)

                          UN/EDIFACT CD 9735-5     -    Security
                          (authenticity, integrity and non-repudiation)

                          UN/EDIFACT CD 9735-6     -    Secure
                          authentication and acknowledgement message
                          (Message type - AUTACK)

                          UN/EDIFACT CD 9735-7     -    Security
                          (confidentiality) for batch EDI

                          UN/EDIFACT CD 9735-8     -    Associated data
                          in UN/EDIFACT data interchange

UN/EDIFACT CD 9735-1 shall be used in combination with either
UN/EDIFACT CD 9735-2
or UN/EDIFACT CD 9735-3.






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

Part 1:
Syntax rules common to both batch and interactive EDI


1  Scope

This International Standard specifies syntax rules for the formatting
of messages to be interchanged between computer application systems.


2  Conformance

Conformance to a standard means that all of its requirements, including
all options, are supported.  If all options are not supported, any
claim of conformance shall include a statement which identifies those
options to which conformance is claimed.

Data that is interchanged is in conformance if the structure and
representation of the data conforms to the syntax rules specified in
this International Standard.

Devices supporting this International Standard are in conformance when
they are capable of creating and/or interpreting the data structured
and represented in conformance with the standard.

Conformance shall be based on Part 1, and at least either Part 2 or
Part 3 of this International Standard.

When identified in this International Standard, provisions defined in
related standards shall form part of the conformance criteria.


3  References

3.1  Normative references

The following standards contain provisions which, through reference in
this text, constitute provisions of this International Standard.  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 646  Information processing - ISO 7-bit coded character set for
         information interchange

ISO 2022 Information technology - ISO 7-bit and 8-bit coded character
         character sets - code extension techniques

ISO 2382-1    Data processing - Vocabulary; Part 1: Fundamental terms

ISO 2382-4    Data processing - Vocabulary; Part 4: Organisation of
         data

ISO 6093 Information processing - Representation of numerical values in
         character strings for information interchange

ISO 6429 Information processing - Control functions for 7-bit and 8-bit
         coded character sets

ISO 10646-1   Information technology - Universal Multiple-Octet Coded
         Character Set (UCS); Part 1: Architecture and basic
         multilingual plane


4  Definitions

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

5  Service characters

The service characters are the component data element separator, data
element separator, release character, repetition separator, and segment
terminator.

The component data element separator, data element separator,
repetition separator, and segment terminator delineate various syntax
structures as defined in clause 7.

The purpose of the release character is to allow the use of a character
that would otherwise be interpreted as a service character.  The
character immediately following the release character in a interchange
shall not be interpreted as a service character.

When used, the release character is not counted in the length of the
data element value.

NOTE - Using default service characters shown below, 10?+10=20
appearing in a data transfer shall be interpreted on receipt as
10+10=20.  A question mark in a data element value is represented in
transfer as ??.

5.1  Default service characters

The default service characters reserved for use in this International
Standard are:


                  Graphic      
   Name        Representatio   Functionality
                     n
   Colon             :         component data element
                               separator
   Plus sign         +         data element separator
   Question          ?         release character
   mark
   Asterisk          *         repetition separator
   Apostroph         '         segment terminator
   e


5.2  UNA, service string advice

The conditional service string advice (UNA) provides the capability to
specify the service characters used in the interchange (see annex B).
The UNA service string advice shall be used if the service characters
differ from the defaults (see clause 5.1). Its use is optional if the
default characters are used.

When used, the service string advice shall appear immediately before
the interchange header segment, and applies only to that interchange.


6  Character repertoires

For UN/EDIFACT, the character repertoire used (and the languages
covered) is identified from the code value in data element 0001 in the
interchange header.

Unless otherwise agreed in the partners' interchange agreement

   -                     a default coded character set shall be used
   to enable unambiguous processing of the Service String Advice (if
   used) up to and including composite data element S001 in the UNB
   segment;

   -                     the default is the encoding specified in the
   basic code table of ISO 646 (7-bit coded character set for
   information interchange).

The default encoding technique for a particular character repertoire is
the one defined by its associated character set specification.  If the
default option is not used, a code value from the code set from the
data element "Character encoding, coded" in composite S001 in the UNB
segment shall be used.

Characters used to indicate  code extension are not counted in the
length of a data element, and shall not be used as service characters.

In calculating data element length, one graphic character counts as one
character, irrespective of the number of bytes/octets required to
encode it.

The use of code extension techniques (ISO 2022) shall only be allowed
in an interchange after composite data element S001 in the UNB segment.


7  Syntax structures

The definitions in this clause specify logical syntax structures.
Rules to be applied for their usage are defined in clause 9.

7.1 Interchange structure

An interchange shall be started either by a service string advice or by
an interchange header, shall be identified by an interchange header,
shall be terminated by an interchange trailer, and shall contain at
least one group, or one message or object.  There may be more than one
message and/or object within an interchange, each identified by its own
header and terminated by its own trailer.

An interchange shall contain either group(s) only, or message(s) and/or
object(s)

For the contents of the service string advice see annex B.

For the contents of the service segments and the specific interchange
structures, see Part 2 for batch EDI, and Part 3 for interactive EDI.

NOTE - Segments for use in UN/EDIFACT messages are defined in the
United Nations Trade Data Interchange Directory (UNTDID).

7.2  Group structure

A group is a conditional structure which is located between the
interchange header and trailer and which comprises one or more messages
and/or objects.

A group shall be started and identified by a group header, shall be
terminated by a group trailer, and shall contain at least one message
or object.

7.3  Message structure

A message comprises an ordered set of segments (see annex C).  Segments
may be grouped.  Each segment's position, status, and maximum number of
occurrences shall be stated in the message specification.

A given segment within a message specification shall have a status of
mandatory or conditional.

A message specification shall ensure unambiguous identification of each
message segment upon receipt. Identification shall be possible on the
basis of the segment tag and the segment's position in the transferred
message.  Identification shall not depend on a segment's status or
maximum number of occurrences.

A message shall be started and identified by a message header, shall be
terminated by a message trailer, and shall contain at least one
additional segment.

7.4  Segment group structure

A segment group comprises an ordered set of segments:  a trigger
segment and at least one more segment or segment group.  The trigger
segment shall be the first segment in the segment group, shall have a
status of mandatory and a maximum number of occurrences of one.  Each
segment group's position, status, and maximum number of occurrences
within the message structure shall be stated in the message
specification.

Segment groups may contain one or more dependent segment groups.  When
a segment group is contained within and directly subordinate to another
segment group, the subordinate segment group is referred to as the
child, and the other segment group is referred to as the parent.

A given segment group within a message specification shall have a
status of mandatory or conditional.

7.5  Segment structure

A segment comprises an ordered set of stand-alone data elements and/or
composite data elements.  Each stand-alone or composite data element's
position, status and maximum number of occurrences shall be stated in
the segment specification.  A segment shall be started and identified
by a segment tag which references a specific segment specification.  A
segment shall contain at least one data element in addition to the
segment tag.

A given data element within a segment specification shall have a status
of mandatory or conditional.

7.6  Segment tag structure

A segment tag is a simple data element.

Segment tags starting with the letter "U" (e.g. UNB, UCS) shall be
reserved for service segments.

7.7  Composite data element structure

A composite data element comprises an ordered set of two or more
component data elements.  Each component data element's position and
status shall be stated in the composite data element specification.

A given component data element within a composite data element
specification shall have a status of mandatory or conditional.

A component data element shall not be a repeating data element.

7.8  Simple data element structure

A simple data element contains a single data element value.

A simple data element is used either as a stand-alone data element or
as a component data element.  A stand-alone data element occurs in a
segment outside a composite data element.  A component data element
occurs within a composite data element.

Each simple data element's data value representation shall be stated in
the data element specification.

7.9  Object structure

An object shall be started and identified by an object header, shall be
terminated by an object trailer, and shall contain one package.


8  Inclusion and exclusion

The rules in this clause shall be applied when a message is prepared
for transfer.  Under these rules, certain segment groups, segments,
data elements, and characters within a data element value, shall be
present while others may be omitted.

8.1  Determination of presence

A simple data element is considered present if its data element value
contains at least one character.

A composite data element is considered present if at least one of its
component data elements is present.

A segment is considered present if its segment tag is present.

A segment group is considered present if its trigger segment is
present.

8.2  Inclusion of segment groups

A mandatory segment group which is not contained within another segment
group shall be present.

A mandatory child segment group shall be present if its parent segment
group is present.

A single occurrence of a segment group having a status of mandatory is
sufficient to satisfy the mandatory requirement.

8.3  Exclusion of segment groups

If a segment group is omitted, all of its segments and any dependent
segment groups contained within it, regardless of their status, shall
also be omitted.

8.4  Inclusion of segments

Segments shall appear in the order stated in the message specification.

A segment shall be terminated by a segment terminator.

A mandatory segment which is not in a segment group shall be present.

A mandatory segment contained in a segment group shall be present if
the segment group is present.

A single occurrence of a segment having a status of mandatory is
sufficient to satisfy the mandatory requirement.

Using a fictitious segment tag of ABC as an example, a mandatory
segment defined as containing only conditional data elements for which
no data is present at the time of transfer, shall be transferred in the
form ABC'.

8.5  Exclusion of segments

A conditional segment for which only the segment tag is present shall
be omitted in its entirety.

8.6  Inclusion of data elements

Data elements shall appear in the order stated in the segment
specification.

Adjacent non-repeating data elements in the same segment shall be
separated by a data element separator.

Adjacent occurrences of the same repeating data element in a segment
shall be separated by a repetition separator.

Adjacent component data elements in the same composite data element
shall be separated by a component data element separator.

A mandatory stand-alone data element in a segment shall be present if
the segment is present.

A mandatory composite data element in a segment shall be present if the
segment is present.

A mandatory component data element in a composite data element shall be
present if the composite data element is present.

A single occurrence of a repeating data element having a status of
mandatory is sufficient to satisfy the mandatory requirement.

8.7  Exclusion of data elements

In the figures in the following sub-clauses, "Tag" represents a segment
tag, "DE" represents a composite data element or stand-alone data
element, and "CE" represents a component data element.  The default
service characters are used.

8.7.1     Exclusion of non-repeating composite data elements and stand-
alone data elements

If a non-repeating composite data element or stand-alone data element
is omitted and is followed by a different composite data element or
stand-alone data element in the same segment, its position shall be
indicated by retention of the data element separator which would
normally follow it.

    
    Tag+DE+DE+++DE+DE+DE'
                                  Two data elements have been
                                  omitted.
    




Figure 1 - Exclusion of non-repeating data elements within a
segment


If one or more non-repeating composite data elements or stand-alone
data elements at the end of a segment are omitted, the data element
separators which would normally follow them shall also be omitted.

    
    Tag+DE+DE+++DE'
                                  Using the example structure in
                                  figure 1, the last two data
                                  elements have been omitted.
    

     Figure 2 - Exclusion of non-repeating data elements at the end of
a segment


8.7.2     Exclusion of component data elements

If a component data element is omitted and is followed by another
component data element in the same composite data element, its position
shall be indicated by retention of the component data element separator
which would normally follow it.

    
    Tag+DE+:CE:CE+CE:::CE'
                                  Two component data elements
                                  have been omitted.
              
                                  One component data element has
                                  been omitted.
    

     Figure 3 - Exclusion of component data elements within a composite
data element


If one or more component data elements at the end of a composite data
element are omitted, the component data element separators which would
normally follow them shall also be omitted.

    
    Tag+DE+:CE+CE'
                                  Using the example structure in
                                  figure 3, the last component
                                  data element in the first
                                  composite data element and the
                                  last component data element in
                                  the last composite data element
                                  have been omitted.
    

     Figure 4 - Exclusion of component data elements at the end of a
composite data element


8.7.3     Exclusion of occurrences of repeating data elements

The position of an occurrence of a repeating data element may be
significant, for example, to 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 data element, its
position shall be indicated by retention of the repetition separator
which would normally follow it.

    
    Tag+DE+DE*DE***DE+DE*DE'
                                  Two occurrences of a repeating
                                  data element have been omitted.
    

           Figure 5 - Exclusion of occurrences within a repeating data
           element


If one or more occurrences of a repeating data element at the end of a
repeating data element are omitted, the repetition separators which
would normally follow them shall also be omitted.

    
    Tag+DE+DE*DE+DE'
                                  Using the example structure in
                                  figure 5, the last occurrence
                                  in the first repeating data
                                  element, and the last
                                  occurrence in the last
                                  repeating data element have
                                  been omitted.
    

           Figure 6 - Exclusion of occurrences at the end of a
           repeating data element


9  Suppression of characters within data elements

In variable length data elements, insignificant characters shall be
suppressed (i.e. omitted from the transfer), while significant
characters shall be present.

9.1  Insignificant characters

In variable length numeric data elements, leading zeroes shall be
suppressed.  Nevertheless, a single zero before a decimal mark is
allowed.  In variable length alphabetic and alphanumeric data elements,
trailing spaces shall be suppressed.

9.2  Significant zeroes

Significant zeroes shall not be suppressed.  A single zero may be
significant, for example, to indicate a temperature or tax rate.
Trailing zeroes following the decimal mark may be significant to
indicate precision.

9.3  Significant spaces

Significant spaces shall not be suppressed.  Leading and embedded
spaces may be significant.
A data element value containing only space(s) shall not be allowed.


10 Representation of numeric data element values

For the purposes of this standard, the representation of numeric data
element values shall be any of the representations as specified by ISO
6093 (which excludes the use of triad separators), with the following
exceptions:

     -    The encoding specified in ISO 646 shall not be required.

     -    For variable length numeric fields, the rules for
     suppression apply (see clause 9).

     -    The space character and plus sign shall not be allowed.

     -    The full stop and the comma are allowed to represent the
     decimal mark.  Either or both may be used within the same
     interchange.

     -    The length of a numeric data element value shall not include
     the minus sign (-),
          the decimal mark (. or ,), or the exponent mark (E or e).

     -    When a decimal mark is transferred, there shall be at least
     one digit after the decimal mark.

Examples using decimal marks:

     Allowed (full stop):          2 and 2.00 and 0.5 and .5
     Not allowed (full stop): 1. and 0. and .

     Allowed (comma):    2 and 2,00 and 0,5 and ,5
     Not allowed (comma):     1, and 0, and ,


11 Dependency notes

11.1 General

If required, dependency notes shall be used in the message or segment
specification to express relationships.

In a dependency note, a list is defined as two or more entities:
segment groups, segments, or data elements.

Any entity may be subject to more than one dependency note.

11.2 Dependency notes in the message specification

Dependency notes in the message specification are used to describe the
relationship between segments, between segment groups, or between
segments and segment groups.  These entities shall be at the same
hierarchical level and within the same parent structure.

Message level dependency notes shall be specified in the message
segment table.

11.3 Dependency notes in the segment specification

Dependency notes in the segment specification are used to describe the
relationship between stand-alone data elements, between stand-alone
data elements and composite data elements, or between composite data
elements.  These entities shall be in the same segment.

Dependency notes shall not be used to describe a relationship between
stand-alone data elements and component data elements, nor between
composite data elements and component data elements.

11.4 Dependency notes in the composite data element specification

Dependency notes in the composite data element specification are used
to describe the relationship between component data elements.  These
entities shall be in the same composite data element.

11.5 Notation for dependency notes

The notation for dependency notes comprise a dependency identifier
followed by a list, in parenthesis, of position identifiers separated
by commas e.g. D3(0030,0060,0090).  The position identifier identifies
an entity by its position number in its parent entity.  The dependency
identifier identifies the type of dependency between the entities in
the list.

A list shall contain at least two position identifiers.  The order of
position identifiers in a list may be different from that implied by
their value.

Dependency identifiers are described below.

      D1   ONE AND ONLY ONE
           One and only one of the entities in the list shall be
      present.

      D2   ALL OR NONE
           If one entity in the list is present, the rest shall be
      present.

      D3   ONE OR MORE
           At least one of the entities in the list shall be present.

      D4   ONE OR NONE
           No more than one entity in the list shall be present.

      D5   IF FIRST, THEN ALL
           If the first entity in the list is present, then all of the
      others shall be present.  It is permissible that one or more of
      the entities not specified as the first entity in the list may
      be present, without requiring the first entity to be present.

      D6   IF FIRST, THEN AT LEAST ONE MORE
           If the first entity in the list is present, then at least
      one more shall be present.  It is permissible that one or more
      of the entities not specified as the first entity in the list
      may be present, without requiring the first entity to be
      present.

      D7   IF FIRST, THEN NONE OF THE OTHERS
           If the first entity in the list is present, then none of
      the others shall be present.
                                  
                               Annex A
                             (normative)
                                  
                             Definitions
                                  

NOTES:

1. When a word or phrase appears in italics within a definition, this
means that a definition exists in this annex for this word or phrase.

2. The terms are classified alphabetically; an identifier is added at
the end of the definition, in square brackets, to facilitate the
comparison between different linguistic versions. For example the
English term "Alphabetic character set" is called in French "Jeu de
caracteres alphabetique", and will not appear at the same alphabetic
place in the two versions of the syntax; the identifier in brackets
shall nevertheless remain "[ 1 ]".

3. Where ISO standards are referenced, the definitions have been taken
from the referenced standard.


A.1 alphabetic character set: A character set that contains letters
    and/or ideograms, and may contain other graphic characters except
    digits   [ 1 ]

A.2 alphanumeric character set: A character set that contains letters,
    digits and/or ideograms, and may contain other graphic characters
    [ 2 ]

A.3 attribute: A characteristic of an object or entity   [ 3 ]

A.4 batch EDI: electronic data interchange in which no strong
    requirements exist for formalised telecommunication association
    between the parties using query and response   [ 4 ]

A.5 character: A member of a set of elements used for the
    organisation, control, or representation of data (ISO 10646-1)   [
    5 ]

A.6 character repertoire: The set of graphic characters of a coded
    character set, considered independently of its encoding   [ 6 ]

A.7 code extension: The techniques for the encoding of characters that
    are not included in the character repertoire of a given coded
    character set   [ 7 ]

A.8 code list: The complete set of data element values of a coded
    simple data element   [ 8 ]

A.9 code list directory: A listing of identified and specified code
    lists   [ 9 ]

A.10coded character set: A set of unambiguous rules that establishes a
    character set and the one-to-one relationship between the
    characters of the set and their bit combinations (ISO 6429)   [ 10
    ]

A.11component data element: A simple data element used within a
    composite data element   [ 11 ]

A.12component data element separator: A service character used to
    separate the component data elements within a composite data
    element   [ 12 ]

A.13composite data element: An identified, named and structured set of
    functionally related component data elements, as described in a
    composite data element specification.  In transfer, a composite
    data element is a specific ordered set of one or more component
    data element(s) in conformance with a composite data element
    specification   [ 13 ]

A.14composite data element directory: A listing of identified, and
    named composite data elements with their composite data element
    specification   [ 14 ]

A.15composite data element specification:  The description of a
    composite data element in a composite data element directory,
    including the specification of the position and status of the
    component data elements constituting the composite data element
    [ 15 ]

A.16conditional: A type of status, used in a message specification,
    segment specification, or composite data element specification, to
    specify that a segment group, segment, composite data element,
    stand-alone data element or component data element is used
    optionally or when the appropriate conditions occur   [ 16 ]

A.17control character: A character whose occurrence in a particular
    context specifies a control function (ISO 2382-4)   [ 17 ]

A.18data: A representation of facts, concepts or instructions in a
    formalised manner suitable for communication, interpretation or
    processing by human beings or by automatic means (ISO 2382-1)
    [18 ]

A.19data element: A unit of data described in a data element
    specification. There are two classes of data element, simple data
    elements and composite data elements   [ 19 ]

A.20data element directory: A listing of identified, named and
    specified simple data elements (simple data element directory) or
    composite data elements (composite data element directory)   [ 20
    ]

A.21data element separator: A service character used to separate non
    repeating stand-alone data elements and/or composite data elements
    in a segment   [ 21 ]

A.22data element specification: The specification of a composite data
    element in a composite data element directory (composite data
    element specification), or of a simple data element in a simple
    data element directory (simple data element specification)   [ 22
    ]

A.23data element value: A specific instance of a simple data element,
    represented as specified in a simple data element specification
    and, if the simple data element is coded, in a code list   [ 23 ]

A.24data value representation: The types of characters allowed (e.g.
    alphabetic, numeric) and conditions of length relating to the data
    element values of a simple data element   [ 24 ]

A.25decimal mark: The character that separates the digits forming the
    integral part of a number from those forming the fractional part
    (ISO 6093)   [ 25 ]

A.26default service characters: The set of characters used as service
    characters in circumstances where a different set is not defined
    in the service string advice   [ 26 ]

A.27dependency identifier: An identifier used in a dependency note to
    specify the type of dependency between the entities listed in the
    dependency note   [ 27 ]

A.28dependency note: A note used: i. in a message specification to
    express relationships between segment groups or between segments;
    ii. in a segment specification to express relationships between
    data elements; iii. in a composite specification to express
    relationships between component data elements   [ 28 ]

A.29EDI: electronic data interchange   [ 29 ]

A.30electronic data interchange: The electronic transfer from computer
    to computer of commercial or administrative transactions using an
    agreed standard to structure the transaction or message data    [
    30 ]

A.31encoding: The representation of a character as a bit combination
    [ 31 ]

A.32exponent mark: A control character used to indicate that the
    character(s) that follow it are to be interpreted as an exponent.
    E or e is the exponent mark   [ 32 ]

A.33graphic character: A character, other than a control character,
    that has a visual representation and is normally produced by
    writing, printing or displaying (ISO 2382-4)   [ 33 ]

A.34group: A group of messages or objects of one or more message types
    and/or objects, headed by a group header and ending with a group
    trailer   [ 34 ]

A.35group header: The service segment heading and identifying a group
    [ 35 ]

A.36group trailer: The service segment ending a group   [ 36 ]

A.37identifier: A character or group of characters used to identify or
    name an item of data and possibly to indicate certain properties
    of that data (ISO 2382-4)   [ 37 ]

A.38ideogram: In a natural language, a graphic character that
    represents an object or a concept and associated sound elements.
    Example; A Chinese ideogram or a Japanese Kanji (ISO 2382-4)   [
    38 ]

A.39interactive EDI: electronic data interchange between pairs of co-
    operating processes, in a timely manner   [ 39 ]

A.40interchange: A sequence of messages, of the same or of different
    types, starting with the interchange header (or with the service
    string advice if used), and ending with the interchange trailer [
    40 ]

A.41interchange header: The service segment starting and uniquely
    identifying an interchange   [ 41 ]

A.42interchange trailer: The service segment ending an interchange   [
    42 ]

A.43mandatory: A type of status, used in a message specification,
    segment specification, or composite data element specification, to
    specify that a segment group, segment, composite data element,
    stand-alone data element or component data element shall be used
    at least one time   [ 43 ]

A.44message: An identified, named and structured set of functionally
    related segments, covering the requirements for a specific type of
    transaction (e.g. invoice), as described in a message
    specification; a message starts with a message header and ends
    with a message trailer.  In transfer, a message is a specific
    ordered set of segments in conformance with a message
    specification          [ 44 ]

A.45message body: The set of segments constituting a message,
    excluding the message header segment and the message trailer
    segment   [ 45 ]

A.46message directory: A listing of identified and named messages each
    with its message specification   [ 46 ]

A.47message header: The service segment starting and uniquely
    identifying a message   [ 47 ]

A.48message specification:  The description of a message in a message
    directory, including the specification of the position, status and
    maximum number of occurrences of the segments and segment groups
    constituting the message   [ 48 ]

A.49message trailer: The service segment ending a message   [ 49 ]

A.50message type: Code identifying a type of message    [ 50 ]

A.51numeric character set: A character set that contains digits and
    may contain control characters and special characters but not
    letters (ISO 2382-4)   [ 51 ]

A.52object: A set of functionally related information, not using the
    usual message structure in segments. [ 52 ]

A.53object header: The service segment starting and uniquely
    identifying an object   [ 53 ]

A.54object trailer: The service segment ending an object   [ 54 ]

A.55package: The set of information constituting an object. A package
    starts with an object header and ends with an object trailer.   [
    55 ]

A.56parent-child relationship: A relationship between two entities,
    one ("child") being contained within and directly subordinated to
    the other ("parent")   [ 56 ]

A.57position identifier: An identifier used in a dependency note to
    identify an entity (segment group, segment, or data element) by
    its position in the parent entity   [ 57 ]

A.58qualifier: A simple data element whose data element value,
    extracted from a code list, gives specific meaning to the function
    of another data element or a segment   [ 58 ]

A.59release character: A character indicating that the character
    immediately following it shall be passed to the application as
    received   [ 59 ]

A.60repeating data element: A composite data element or stand-alone
    data element having a maximum occurrence of greater than one in
    the segment specification   [ 60 ]

A.61repetition separator: A service character used to separate
    adjacent occurrences of a repeating data element   [ 61 ]

A.62segment: An identified, named and structured set of functionally
    related composite data elements and/or stand-alone data elements,
    as described in a segment specification; a segment starts with the
    segment tag and ends with the segment terminator.  In transfer, a
    segment is a specific ordered set of one or more composite data
    element(s) and/or stand-alone data element(s) in conformance with
    a segment specification   [ 62 ]

A.63segment directory: A listing of identified and named segments with
    their segment specification       [ 63 ]

A.64segment group: An identified hierarchical set of segments and/or
    segment groups within a message   [ 64 ]

A.65segment specification: The description of a segment in a segment
    directory, including the specification of the position, status and
    maximum number of occurrences of the data elements constituting
    the segment   [ 65 ]

A.66segment tag: A simple data element uniquely identifying a segment,
    by reference to a segment directory   [ 66 ]

A.67segment terminator: A service character indicating the end of a
    segment   [ 67 ]

A.68service character: A character reserved for syntactical use; the
    service characters are the component data element separator, the
    data element separator, the release character, the repetition
    separator and the segment terminator   [ 68 ]

A.69service composite data element: A composite data element used in
    service segments. A service composite data element specification
    contains only service simple data elements   [ 69 ]

A.70service data element: A service simple data element or a service
    composite data element   [ 70 ]

A.71service message: A message used to exchange service information
    relating to the use of EDIFACT syntax rules or security. A service
    message specification contains only service segments   [ 71 ]

A.72service segment: A segment used i. in service messages; ii. to
    control the transfer of data. A service segment specification
    contains only service composite data elements and/or service
    simple data elements   [ 72 ]

A.73service simple data element: A simple data element used only in
    service segments and/or service composite data elements   [ 73 ]

A.74service string advice: An optional character string used at the
    beginning of an interchange to specify the service characters used
    in the interchange   [ 74 ]

A.75simple data element: A data element containing a single data
    element value. There are two uses of a simple data element: within
    a composite data element (component data element); and within a
    segment outside a composite data element (stand-alone data
    element)   [ 75 ]

A.76simple data element directory: A listing of identified and named
    simple data elements with their simple data element specification
    [ 76 ]

A.77simple data element specification: The set of attributes
    characterising a simple data element in a simple data element
    directory   [ 77 ]

A.78special character: A graphic character that is not a letter,
    digit, or blank character, and usually not an ideogram ( ISO 2382-
    4)   [ 78 ]

A.79stand-alone data element: A simple data element used within a
    segment without being in a composite data element   [ 79 ]

A.80status: An attribute of a segment, a composite data element or a
    simple data element identifying the rules for the presence or
    absence of the segment/data element in the usage of a message. The
    types of status are conditional and mandatory   [ 80 ]

A.81string: a sequence of elements of the same nature, such as
    characters, considered as a whole        ( ISO 2382-4)   [ 81 ]

A.82transfer: The communication of information from one partner to
    another   [ 82 ]

A.83trigger segment: The segment starting a segment group   [ 83 ]

                                  
                               Annex B
                             (normative)
                                  
                      UNA service string advice
                                  

The service string advice shall begin with the upper case characters
UNA immediately followed by six characters in the order shown below.
The space character shall not be used in positions 010, 020, 040, 050
or 060.  The same character shall not be used in more than one position
of the UNA.


  POS  REP  S     Name                     Remarks

  010  an1  M     COMPONENT DATA  ELEMENT
                  SEPARATOR

  020  an1  M     DATA ELEMENT SEPARATOR

                                           030  an1  M    DECIMAL MARK
                                           The character transferred in
                                           this position shall be
                                           ignored by the recipient.
                                           Retained to maintain upward
                                           compatibility with earlier
                                           versions of the syntax.

  040  an1  M     RELEASE CHARACTER

  050  an1  M     REPETITION SEPARATOR

  060  an1  M     SEGMENT TERMINATOR


Legend:

POS     The 3 numeric sequential number of the character in the service
string

REP                          The representation of the service string
character
        an1 = 1 alphanumeric character

S       The status of the service string character
        M    =  Mandatory

Name    Name of the service string advice character

Remarks Additional remarks
                                  
                               Annex C
                            (informative)
                                  
      Order of segments and groups of segments within a message
                                  

C.1                 General

Segments used in a message appear in the sequence (top to bottom)
specified in the message segment table.

In the message segment table, segments are indicated by their tags.
The requirement for their inclusion in the message i.e. their status,
is indicated by the letter M for mandatory or C for conditional.  The
number of times a segment may occur in each instance is indicated
directly thereafter.  This may be followed by any associated dependency
note identifier(s).

In the message segment table, segment groups are indicated by their
segment group number.  The requirement for their inclusion in the
message i.e. their status, is indicated by the letter M for mandatory
or C for conditional.  The number of times a segment group may occur in
each instance is indicated directly thereafter.  This may be followed
by any associated dependency note identifier(s).


C.2                 Segment groups

Two or more segments can be grouped, as shown in figure 1.  The trigger
segment of each segment group appears in the message segment table
immediately following the segment group identification (i.e. segment
group 1, 2 etc.)

Dependent segments within the segment group follow in sequence, with
the last segment in the group identified by the boundary lines
specifying the extent of the segment group.

A segment group can contain another dependent segment group or groups
(e.g. segment group 2 contains a dependent segment group 3 in the
figure), and, as can be seen in the figure, a segment can terminate two
(or more) segment groups, as indicated by the segment group boundary
lines (segment LLL in the figure.)

In the figure, segment group 2 is the parent of segment group 3, and
segment group 3 is the parent of segment group 4.

C.2.1     Figure 1


-----------------------------------------------------------------------

POS    TAG    Name                                   S   R  Notes

0010   Uxx    Message header                         M   1
0020   AAA    Segment AAA name                       M   1
0030   BBB    Segment BBB name                       C   9
0040   CCC    Segment CCC name                       C   9

0050   ---------- Segment group 1 ------------------ C   999  -------+
0060   DDD    Segment DDD name                       M   1           |
0070   EEE    Segment EEE name                       C   9           |
0080   FFF    Segment FFF name                       C   9           |
0090   GGG    Segment GGG name                       C   1    -------+

0100   ---------- Segment group 2 ------------------ C   9    -------+
0110   HHH    Segment HHH name                       M   1           |
                                                                     |
0120   ---------- Segment group 3 ------------------ C   9    ------++
0130   III    Segment III name                       M   1          ||
0140   JJJ    Segment JJJ name                       C   9          ||
                                                                    ||
0150   ---------- Segment group 4 ------------------ C   9    -----+||
0160   KKK    Segment KKK name                       M   1         |||
0170   LLL    Segment LLL name                       C   9    -----+++
  .
  .
  .
  .
nnnn   Uxx    Message trailer                        M   1

-----------------------------------------------------------------------

              Figure 1 - Example message segment table


Legend

POS        The sequential position number of the segments & segment
       groups in the message
           (in steps of 10 to permit later amendment to message
       structures)

TAG        The tag for segments in the message

Name       Name of the segments in the message

S          Status (of segments or segment groups) i.e. M = Mandatory,
       C = Conditional

R          The maximum number of occurrences of segments or segment
       groups

Notes      The dependency note identifier(s)


C.2.2               Figure 1 Notes
   
1. An example of the processing/sequencing order of the segments
   (using the segment tags only) is as follows (with segment group 1
   appearing twice, the other groups once, and with repeating segments
   shown as appearing once only):
   
   Uxx,AAA,BBB,CCC,DDD,EEE,FFF,GGG,DDD,EEE,FFF,GGG,HHH,III,JJJ,KKK,LLL
   ,...Uxx
   
2. In the segment table and in the segment string shown above, the
   first "Uxx  Message Header" would be "UNH" for batch EDI, and "UIH"
   for interactive EDI;  the second "Uxx  Message trailer" would be
   "UNT" for batch EDI and "UIT" for interactive EDI.