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 footnote
has now been deleted and the status of of the message release number
(0054) and controlling agency (0051) has been changed from conditional
to 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, the
rules on application level for the structuring of the user data and
of the associated service data in the interchange of messages in an
open environment. 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 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 issued
by ISO, ITU-T, CEN/CENELEC etc. may be followed for the communication
of messages based on this standard. Such specifications and protocols
are outside the scope of this standard.
Functional error indication/correction can be handled by special
service messages following the syntax rules in this International
Standard.
Normative annexes: Informative annex:
A. Terminology C. Order of segments and
groups of segments
within a message
B. 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 definitions
in annex A apply.
4. SYNTAX LEVELS
This International Standard specifies syntax levels A and B which
are identical in all respects except for the character sets used. As
requirements for additional syntactical features appear, further
levels may be added.
Unless interchange partners agree to use other or additional
characters, level A shall use only the character set specified in
clause 5.1, and level B only the character set specified in clause
5.2.
The conditional Service String Advice, UNA, (see Annex B) provides
the capability to specify the separator and other service characters
used 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
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.
-----------------------------------------
|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 |
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 Mandatory
Segment Code Mandatory component data
element
Component data element separator Conditional
Nesting and repeating indication Conditional component data
element(s)
Data element separator Mandatory
Simple or composite data elements 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
Composite Data Element specified in the relevant
with segments directory
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.
| 
