CHAPTER 2.2 - Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules
Table of Contents
FOREWORD
INTRODUCTION1. SCOPE
2. NORMATIVE REFERENCES3. DEFINITIONS
4. SYNTAX LEVELS5. CHARACTER SETS
5.1 Level A Character Set5.2 Level B Character Set
6.1 Interchange Structure
6.2 Order of Segments and Groups of Segments within a Message6.3 Segment Structure
6.4 Data Element Structure7.1 Exclusion of Segments
7.2 Exclusion of Data Elements by Omission7.3 Exclusion of Data Elements by Truncation
7.4 Exclusion of Component Data Elements by Omission7.5 Exclusion of Component Data Elements by Truncation
8.1 Repetition of Segments
8.1.1 Explicit Indication of Repetition8.1.2 Implicit Indication of Repetition
8.2 Repetition of Data Elements
9.1 Explicit Indication of Nesting
9.2 Implicit Indication of Nesting10.1 Decimal Sign
10.2 Triad Separator10.3 Sign
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 |
Mandatory |
|
Component data element separator |
Conditional Conditional component data element (s) |
|
Data element separator |
Mandatory |
| 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.
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
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.