 | |
 |
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
Part 1:
|
|
* 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.
|