UNITED
NATIONS STANDARD MESSAGE (UNSM)
Syntax
and service report message
Message
Type : CONTRL
Version :
D
Release :
3
Contr.
Agency: UN
Revision :
1
Date :
97-03-17
SOURCE: Syntax Development Group (SDG)
CONTENTS
Syntax
and service report message
0. INTRODUCTION
1. SCOPE
1.1 Functional
definition
1.2 Field of
application
1.3 Principles
1.3.1
Relations between CONTRL and the subject interchange
1.3.2
Action codes usage
1.3.3
Reporting of syntactical errors
1.3.4
Errors in data elements that are copied from the
Subject
interchange to the CONTRL message
1.3.5
Redundant reporting of action
1.3.6
Re-transmission
1.3.7
Acknowledgement or rejection of CONTRL messages
1.3.8
Support of the CONTRL message type
2. REFERENCES
3. TERMS AND DEFINITIONS
3.1 Standard terms and
definitions
3.2 Message terms and
definitions
4. MESSAGE DEFINITION
4.1 Data segment
clarification
4.2 Data segment index
(alphabetical sequence)
4.3 Message structure
4.3.1
Segment table
5. DIRECTORIES
5.1 Introduction
5.2 Segments
5.2.1
Index of segments by tag
5.2.2
Index of segments by name
5.2.3
Segment specifications
5.3 Composite Data
Elements
5.3.1
Index of composite data elements by tag
5.3.2
Index of composite data elements by name
5.3.3
Composite data element specifications
5.4 Data Elements
5.4.1
Index of data elements by tag
5.4.2
Index of data elements by name
5.4.3
Data element specifications
5.5 Code Lists
Annex A Examples of use of action codes in
CONTRL
Annex B Use of error codes
Annex C Use of code values in data element
0013 Service segment
tag,
coded
Annex D Conditions for presence of conditional
segments/data
data
elements
----------------------------------------------------------------------
For general information on UN standard message types see UN Trade Data
Interchange Directory, UNTDID, Part 4, Section 2.6, UN/ECE UNSM
General Introduction
----------------------------------------------------------------------
0. INTRODUCTION
This specification provides
the definition of the Syntax and
service report message
(CONTRL) to be used in Electronic Data
Interchange (EDI) between
trading partners involved in
administration, commerce and
transport.
1. SCOPE
1.1 Functional Definition
CONTRL is a message
syntactically acknowledging or rejecting,
with error indication, a
received interchange, functional group
or message.
A CONTRL message can be
used to:
a) acknowledge
or reject a received interchange, functional
group
or message and list any errors contained therein, or
b) indicate only
the receipt of an interchange.
1.2 Field of Application
The Syntax and service
report message may be used for both
national and international
applications. It is based on
universal practice related to
administration, commerce and
transport, and is not
dependent on the type of business or
industry.
This specification of
CONTRL can be used for version 1, 2, or 3
of the EDIFACT syntax (ISO
9735).
1.3 Principles
This specification of
CONTRL can be used for version 1, 2, or 3
of the EDIFACT syntax (ISO
9735).
The sender (A) of an
EDIFACT interchange can in segment UNB
request a response from the
recipient (B) that the interchange
has been received, is
syntactically correct, that the service
segments are semantically
correct and that the recipient
supports those functions
requested in the service segments.
Alternatively, the request can
be specified in an Interchange
Agreement (IA) between the
interchanging partners.
The interchange sent from A
to B is called the subject
interchange.
The response is sent from
the recipient (B) of the subject
interchange to the sender of
the subject interchange (A) as one
or two CONTRL messages.
A CONTRL message indicates
- the action taken by
the recipient as the result of a
syntactical
check of the subject interchange, or
alternatively
- only receipt of the
interchange.
In the first case, the
action (acknowledgement or rejection,
see section 3) indicates the
result of a syntactical check of
the complete received
interchange. The action may be indicated
for the complete interchange,
or it may be indicated for
individual parts of it. Thus,
some messages or functional
groups may be acknowledged and
others may be rejected. The
CONTRL message must indicate
the action for all parts of the
subject interchange.
In the second case, only
receipt of the subject interchange is
indicated, see clause 3.
During a syntactical check,
the interchange, or part of it, is
checked for compliance with:
- the EDIFACT syntax
rules (ISO 9735),including rules for use
of service
segments,
- the syntactical
aspects in specifications for the message
type(s)
received, and
- any additional
agreements between partners regarding use of
the syntax
rules. Such agreements shall be conformant with
ISO 9735.
CONTRL shall not be used to
report errors, or the action taken,
at the application level, i.e.
reports related to the semantic
information contained in user
segments. Thus, acknowledgement
indicated by means of CONTRL
does not imply that the business
content of a message has been
accepted or can be complied
with.
A recipient may choose to
acknowledge an interchange, or part
of it, even if it contains
syntactical errors. These errors may
also be reported. The
definition of a non-fatal error is
determined by the recipient.
The recipient may for example,
choose to acknowledge a data
element exceeding the specified
maximum length.
CONTRL messages may be
generated by the recipient of the
subject interchange or by a
third party acting on behalf of the
recipient. In this
case, the UNB of the interchange containing
the CONTRL messages will
contain the same sender and receiver
identifications as the subject
interchange, only reversed.
Alternatively, one CONTRL
message rejecting the complete
interchange may be generated
by a third party, for example a
network service, to indicate
non-delivery. In this case, the
UNB of the CONTRL message will
contain a sender identification
of the third party.
Partners may agree that a
CONTRL message rejecting an erroneous
subject interchange, or part
of it, shall always be sent even
if acknowledgement has not
been requested in the subject
interchange UNB segment.
A CONTRL message shall only
be generated if the originator of
the subject interchange
supports the receipt of the CONTRL
message. Support for receipt
of CONTRL messages is indicated
either by the acknowledgement
request in the subject
interchange UNB segment or in
an IA.
A CONTRL message shall
never be sent in a functional group.
Note: A CONTRL message
rejecting the subject interchange may
be
sent if the actual recipient is different from the one
identified
in the subject interchange UNB segment. The
CONTRL
message shall be sent to the originator of the
subject
interchange, unless there is an agreement with a
third
party to send it to the third party. The CONTRL
message
shall not be sent unless the originator of the
subject
interchange is known to accept CONTRL messages
from
the originator of the CONTRL message. In some cases
it
may be necessary to generate the CONTRL manually, or
notify
the subject interchange originator by other means
than
CONTRL. Notification by other means than CONTRL
would
be necessary, for example, if the subject
interchange
contained only CONTRL messages (see 1.3.7).
1.3.1 Relations between CONTRL and the subject interchange
A maximum of two CONTRL
messages may be sent in response to a
received
interchange. The first, which is optional, indicates
only the receipt of the
subject interchange. The second reports
the action taken after the
syntax check of the subject
interchange. The action code
in the UCI segment will indicate
if the message is of the first
or second type, see 5.5.
If a request for
acknowledgement is indicated in the subject
interchange UNB, then the
second type of CONTRL message must be
sent to report the results of
a syntax check of the subject
interchange. The optionality
of the first message implies that,
if any CONTRL message is sent
at all, the second type of CONTRL
message must always be sent,
while the first type is sent at
the discretion of the subject
interchange receiver. The first
type may only be sent if
agreed in an IA. The UCI segment in
CONTRL messages of the first
type shall not be used to report
any errors, i.e. only a
message of the second type shall be
sent when there is a need to
report errors by means of the UCI
segment.
A CONTRL message can only
report the action taken for one
subject interchange,
i.e. it may not refer to several subject
interchanges, or to parts of
several subject interchanges.
The structure of CONTRL is
based on five segments (UCI, UCF,
UCM, UCS and UCD), each
containing a reference to a part of the
subject interchange. The parts
of the subject interchange are:
- the UNA, UNB and UNZ
segments, referenced in the UCI segment
- the UNG and UNE
segments, referenced in the UCF segment
- a complete message,
referenced in the UCM segment
- a segment in a
message, referenced in the UCS segment
- a simple, composite or
component data element, referenced in
the UCD
segment.
These parts of the subject
interchange are called
referenced-levels.
Each of the five mentioned
segments in CONTRL contains a data
element indicating the action
taken for the referenced part,
and optionally data elements
used for error reporting. Each of
the five segments is called a
reporting-level.
Segment groups 1 and 3
shall not be used in a CONTRL message
acknowledging only the receipt
of an interchange. If the
subject interchange contains
functional groups, only segment
group 3 is used in the CONTRL
message. If functional groups are
not used, only segment group 1
is used in the CONTRL message.
When there is a need to
send a UCM-group (segment group 1 or
4), no more than one UCM-group
shall be sent per received
message.
All reporting-levels shall
be in the same order as their
corresponding
referenced-levels in the subject interchange.
1.3.2 Action codes usage
The referenced-levels of
the subject interchange that may be
acknowledged or rejected are
those referenced by the UCI, UCF
and UCM segments, i.e.
- the UNA, UNB and UNZ
segments
- the UNG and UNE
segments
- a complete message.
The CONTRL message also
provides the means to acknowledge or
reject a complete interchange
or a complete functional group,
without referencing messages
or functional groups contained in
it.
The action (acknowledgement
or rejection) is indicated by a
code in the UCI, UCF and UCM
segments, see code list 0083. This
code may indicate the action
for the corresponding
referenced-level, and in some
cases also for its lower levels
(in the interchange hierarchy,
cf. Figure 1 in ISO 9735).
A referenced-level in the
subject interchange is said to be
explicitly reported if the
CONTRL message contains a
corresponding segment that
references that level. Explicit
reporting of a lower
referenced-level requires that all
referenced-levels above are
acknowledged.
A referenced-level is said
to be implicitly reported if the
action taken for the level is
reported by a UCI or UCF segment
referencing a higher level in
the subject interchange. Thus,
for example, a functional
group and all messages within it are
implicitly rejected if the
action code in the UCI segment
indicate rejection of the
complete subject interchange. Also, a
message is implicitly
acknowledged when the action code in UCI
or UCF indicates
acknowledgement of messages at the next lower
level, and no UCM rejecting
the message is present.
Action codes 4 and 7 are
only used in CONTRL messages reporting
the action after complete
check of the interchange. Action code
8 is only used in CONTRL
messages indicating the receipt of an
interchange.
1.3.3 Reporting of syntactical errors
Errors can be reported at
all reporting-levels of CONTRL by
means of data elements in the
segment constituting the
reporting-level. These data
elements identify the error's
position in the subject
interchange and indicate its nature.
The UCI, UCF and UCM
segments can only report one error. If
more than one error is
detected at a level referenced by one of
these segments, the receiver
of the subject interchange is free
to choose which error to
report. Several CONTRL messages shall
not be sent in order to report
several errors.
Errors may be reported even
if the referenced-level (including
erroneous parts) is
acknowledged. Users should be aware that
some syntactical errors could
change the semantics of data, and
that the receiver of the
subject interchange is responsible for
any consequences when data
with syntactic errors are
acknowledged.
It is recommended that
errors are identified as precisely as
possible. If a precise error
code can be defined, a more
general (and imprecise) error
code shall not be used.
Similarly, the position of the
error shall be identified as
precisely as possible by using
the lowest possible
reporting-level.
No "copying" of
error codes from a lower to a higher
reporting-level shall
occur. It would otherwise, for example,
be possible to report a data
element error by an error code in
UCD, and repeat the same error
code in UCM. In this case, the
error code identifying the
error shall only appear in UCD. The
same rule applies at all
reporting-levels.
Identification of an
error's exact position and nature on
receipt of the CONTRL message
will often require access to the
subject interchange in the
format it was transferred.
1.3.4 Errors in data elements that are copied from the
subject
interchange to the CONTRL
message
The CONTRL message contains
several mandatory data elements
that are copied from the
subject interchange. If the data
element in the subject
interchange is missing or is
syntactically invalid, a
syntactically valid CONTRL message can
not be generated. The error
must then be reported by other
means than CONTRL, unless all
parties processing the CONTRL
message has agreed in an IA
that copying of erroneous data
elements into the CONTRL
message is permitted. The omission of
mandatory data elements may
also be permitted by an IA.
1.3.5 Redundant reporting of action
If action code 7 is used in
UCI, it is not an error if UCM or
UCF segments are sent
acknowledging a message or functional
group. Similarly, redundant
UCM segments may acknowledge
messages in a functional group
when the code is used in UCF.
1.3.6 Re-transmission
The conditions which
determine the requirements to re-send an
interchange, functional group
or a message must be agreed
between the interchanging
partners outside the scope of
CONTRL.
1.3.7 Acknowledgement or rejection of CONTRL messages
No CONTRL, or other message
types in UN/EDIFACT, shall be sent
in response to a received
CONTRL message. Errors in received
CONTRL messages must be
reported by other means than CONTRL.
If one or more CONTRL
messages are contained in an interchange
being responded to, the CONTRL
messages generated as a response
to that received interchange
shall be generated as if no CONTRL
messages were contained in the
received interchange.
CONTRL messages shall not
be sent in response to received
interchanges that contain only
CONTRL messages.
If CONTRL messages are
mixed with other message types in an
interchange, an implicit
acknowledgement or rejection received
for parts of that interchange
does not apply to the CONTRL
messages.
1.3.8 Support of the CONTRL message type
Requirements for support
for submission and receipt of the
CONTRL message type should be
agreed between partners.
All parties requesting
acknowledgement by means of the
Acknowledgement request data
element in UNB must support
receipt of the CONTRL message
type.
All parties supporting
receipt of the CONTRL message type shall
be able to understand all
information at all reporting-levels
in CONTRL, and be able to
identify the parts of the subject
interchange that are
acknowledged or rejected. The party shall
be able to receive CONTRL
messages where implicit reporting is
used.
All parties supporting
submission of the CONTRL message type
shall be able to check all
parts of the interchange and
generate all the
reporting-levels of CONTRL. Support for a
reporting-level implies that
errors are reported at the
reporting-level corresponding
to the referenced-level where
the error occurred.
Support for generation of
segment group 3 in CONTRL is not
required if an IA prohibits
the use of functional groups. A
party supporting receipt of
CONTRL must support reception of
segment group 3 if he submits
interchanges with functional
groups.
2. REFERENCES
See UNTDID, Part 4, Chapter
2.6 UN/ECE UNSM - General
Introduction, Section 1.
3. TERMS AND DEFINITIONS
3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter
2.6 UN/ECE UNSM - General
Introduction, Section 2.
3.2 Message terms and definitions
Acknowledgement
Acknowledgement
implies that the recipient of the subject
interchange
- has
received the acknowledged part of the interchange,
and
- has
checked that there are no fatal syntactic errors in
the
acknowledged part that prevents further processing of
it,
and
- has
checked that all acknowledged (parts of) service
segments
are semantically correct (if no errors are
reported),
and
- will
comply with the actions requested in the
acknowledged
(parts of the) service segments, and
- has
accepted liability for notifying the sender by
other
means than sending a CONTRL message if
-
any syntactic or semantic errors as described above,
are
later detected in the relevant part, or
-
the part can not be processed for some other reason
after
the part has been acknowledged in a submitted
CONTRL
message,
- has
taken reasonable precautions in order to ensure
that
such errors are detected and that the sender is
notified.
Indication of interchange
receipt
Indication
of interchange receipt implies that the recipient
of the
subject interchange
- has
received the interchange, and
-
acknowledges the parts of the interchange that have
been
checked in order to assure that the data elements
copied
into the reporting UCI segment are syntactically
correct,
and
- has
accepted liability for notifying the sender of
acknowledgement
or rejection of the other parts of the
interchange,
and
- has
taken reasonable precautions in order to ensure that
the
sender is so notified.
Rejection
Rejection
implies that the recipient of the subject
interchange
- can
not acknowledge the interchange, or relevant part
of
it, for reasons indicated in the CONTRL message, and
- will
not take any further action on business
information
contained in the rejected part of the
interchange.
To report
To indicate
the action (acknowledgement or rejection) taken
for an
subject interchange or part of it.
Reporting-level
A
reporting-level is a segment in CONTRL in which reporting
of a
corresponding referenced-level takes place. The
reporting-levels
are UCI, UCF, UCM, UCS and UCD.
Referenced-level
The
structure of CONTRL is based on five segments (UCI, UCF,
UCM, UCS and
UCD) that contain a reference to a part of the
subject
interchange. The parts of the subject interchange
are:
- the
UNA, UNB and UNZ segments, referenced in the UCI
segment
- the
UNG and UNE segments, referenced in the UCF segment
- a
complete message, referenced in the UCM segment
- a
segment in a message, referenced in the UCS segment
- a
simple, composite or component data element,
referenced
in the UCD segment
These
parts of the subject interchange are called
referenced-levels.
Subject interchange
The
interchange that a CONTRL message is returned in
response to.
4. MESSAGE DEFINITION
4.1 Data Segment Clarification
This section should be read
in conjunction with the Segment
Table which indicate
mandatory, conditional and repeating
requirements.
The corresponding
information for data elements in the segments
is given in 5.2.
0010 UNH, Message header
A service segment starting and
uniquely identifying a message.
The message type code for
Syntax and service report message is
CONTRL.
Note: Syntax and service
report messages conforming to this
document must contain the
following data in segment UNH,
composite S009:
Data
element 0065 CONTRL
0052
D
0054
3
0051
UN
0020 UCI, Interchange response
A segment identifying the
interchange being responded to (the
subject interchange). It also
indicates interchange receipt,
acknowledgement or rejection
(action taken) of the UNA, UNB and
UNZ segments, and identifies
any error related to these
segments.
Depending on the action code,
it may also indicate the action
taken on the functional groups
and messages within that
interchange.
The subject interchange is
identified by copying its
Interchange sender,
Interchange recipient, and Interchange
control reference data
elements into the identical data
elements in this segment. An
erroneous or missing UNA, UNB or
UNZ segment may be identified.
If no segment is identified, the
error relates the complete
interchange, unless the error code
identifies some other
position.
0030 Segment group 1: UCM-SG2
A group of segments sent in
response to a message in the
subject interchange identified
in the UCI segment. This segment
group is only used if the
subject interchange does not contain
functional groups.
0040 UCM, Message response
A segment
identifying a message in the subject interchange,
indicating
that message's acknowledgement or rejection
(action
taken), and identifying any error related to the UNH
and UNT
segments.
The message
is identified by copying its Message identifier
and Message
reference number data elements into the
identical
data elements in this segment. An erroneous or
missing UNH
or UNT segment may be identified. If no segment
is
identified and segment group 2 is not present, the error
relates to
the complete message, unless the error code
identifies
some other position.
0050 Segment group
2: UCS-UCD
A group of
segments sent in response to a segment containing
one or more
errors, and which was part of the message
identified
by the UCM segment in segment group 1.
0060 UCS,
Segment error indication
A
segment identifying a segment in the message,
indicating
that this segment contains an error, and
identifying
any error related to the complete segment.
0070 UCD, Data
element error indication
A
segment identifying an erroneous simple, composite or
component
data element in the segment identified by the
UCS
segment in segment group 2, and identifying the
nature
of the error.
0080 Segment group 3: UCF-SG4
A group of segments sent in
response to a functional group in
the subject interchange
identified in the UCI segment. This
segment group is only used if
the subject interchange contains
functional groups.
0090 UCF, Functional group
response
A segment
identifying a functional group in the subject
interchange.
It also indicates acknowledgement or rejection
(action
taken) of the UNG and UNE segments, and identifies
any error
related to these segments. Depending on the action
code, it may
also indicate the action taken on the messages
within that
functional group.
The
functional group is identified by copying its
Application
sender's identification, Application recipient's
identification,
and Functional group reference number data
elements
into the identical data elements in this segment.
An erroneous
or missing UNG or UNE segment may be
identified.
If no segment is identified, the error relates
the complete
functional group, unless the error code
identifies
some other position.
0100 Segment group 4: UCM-SG5
A group of
segments sent in response to a message in the
functional
group identified in segment group 3.
0110 UCM,
Message response
A
segment identifying a message in the subject
interchange,
indicating that message's acknowledgement or
rejection
(action taken), and identifying any error
related
to the UNH and UNT segments.
The
message is identified by copying its Message
identifier
and Message reference number data elements
into
the identical data elements in this segment. An
erroneous
or missing UNH or UNT segment may be
identified.
If no segment is identified and segment group
5
is not present, the error relates to the complete
message,
unless the error code identifies some other
position.
0120 Segment
group 5: UCS-UCD
A
group of segments sent in response to a segment
containing
one or more errors, and which was part of the
message
identified by the UCM segment in segment group
4.
0130 UCS,
Segment error indication
A
segment identifying a segment in the message,
indicating
that this segment contains an error, and
identifying
any error related to the complete
segment.
0140 UCD,
Data element error indication
A
segment identifying an erroneous simple, composite
or
component data element in the segment identified by
the
UCS segment in segment group 5, and identifying
the
nature of the error.
0150 UNT, Message trailer
A service segment ending a
message, giving the total number of
segments in the message and
the control reference number of the
message.
4.2 Data segment index (Alphabetical sequence
by tag)
UCD Data
element error indication
UCF
Functional group response
UCI
Interchange response
UCM Message
response
UCS Segment
error indication
UNH Message
header
UNT Message
trailer
4.3 Message structure
4.3.1 Segment table
Pos Tag
Name S R
0010 UNH Message
header M 1
0020 UCI Interchange
response M 1
0030
Segment group
1
C 999999+
0040 UCM Message
response M 1 |
|
0050
Segment group
2
C 999+|
0060 UCS Segment error
indication M 1 ||
0070 UCD Data element error
indication C 99++
0080
Segment group
3
C 999999+
0090 UCF Functional group
response M 1 |
|
0100
Segment group
4
C 999999+|
0110 UCM Message
response M 1 ||
||
0120
Segment group
5
C 999+||
0130 UCS Segment error
indication M 1 |||
0140 UCD Data element error
indication C 99+++
0150 UNT Message
trailer M 1
5. DIRECTORIES
5.1 Introduction
This specification of
CONTRL makes use of segments, composite
data elements, data elements
and codes that are specific to
CONTRL. They are specified in
the following subsections. These
segments, composite data
elements, data elements and codes are
not available for use in user
messages.
In addition, the CONTRL
message makes use of segments,
composite data elements, data
elements and codes specified in
ISO 9735. The specifications
used shall be those in the version
of ISO 9735 which is used for
the interchange containing the
CONTRL message. The
specifications contained in ISO 9735,
version 2 and 3 are reproduced
in the following subsections.
Differences between version 1
and 2 are also indicated.
Code lists for data
elements specified in ISO 9735 can be found
in the UN Trade Data
Interchange Directory, UNTDID.
5.2 Segments
5.2.1 Index of segments by tag
Tag Name
UCD Data element error indication
UCF Functional group response
UCI Interchange response
UCM Message response
UCS Segment error indication
UNH Message header
UNT Message trailer
5.2.2 Index of segments by name
Tag Name
UCD Data element error indication
UCF Functional group response
UCI Interchange response
UNH Message header
UCM Message response
UNT Message trailer
UCS Segment error indication
5.2.3 Segment specifications
UCD DATA ELEMENT
ERROR INDICATION
Function: To identify an
erroneous simple, composite or
component
data element, and to identify the nature of
the
error.
010 0085 SYNTAX ERROR,
CODED M an..3
020 S011 DATA ELEMENT
IDENTIFICATION M
0098 Erroneous data
element position in segment M n..3
0104 Erroneous
component data element position C n..3
UCF FUNCTIONAL
GROUP RESPONSE
Function: To identify a
functional group in the subject
interchange
and to indicate acknowledgement or
rejection
(action taken) of the UNG and UNE segments,
and
to identify any error related to these segments.
Depending
on the action code, it may also indicate the
action
taken on the messages within that functional
group.
010 0048 FUNCTIONAL GROUP REFERENCE
NUMBER M an..14
020 S006 APPLICATION SENDER'S
IDENTIFICATION M
0040 Sender
identification M an..35
0007 Sender
identification
qualifier C an..4
030 S007 APPLICATION RECIPIENT'S
IDENTIFICATION M
0044 Recipient's
identification M an..35
0007 Recipient's
identification
qualifier C an..4
040 0083 ACTION,
CODED M an..3
050 0085 SYNTAX ERROR,
CODED C an..3
060 0013 SERVICE SEGMENT TAG,
CODED C a3
070 S011 DATA ELEMENT
IDENTIFICATION C
0098 Erroneous data
element position in segment M n..3
0104 Erroneous
component data element position C n..3
UCI INTERCHANGE
RESPONSE
Function: To identify the subject
interchange, to indicate
interchange
receipt, to indicate acknowledgement or
rejection
(action taken) of the UNA, UNB and UNZ
segments,
and to identify any error related to these
segments.
Depending on the action code, it may also
indicate
the action taken on the functional groups and
messages
within that interchange.
010 0020 INTERCHANGE CONTROL
REFERENCE M an..14
020 S002 INTERCHANGE
SENDER M
0004 Sender
identification M an..35
0007 Identification
code
qualifier C an..4
0008 Address for
reverse
routing C an..14
030 S003 INTERCHANGE
RECIPIENT M
0010 Recipient
identification M an..35
0007 Identification
code
qualifier C an..4
0014 Routing
address C an..14
040 0083 ACTION,
CODED M an..3
050 0085 SYNTAX ERROR,
CODED C an..3
060 0013 SERVICE SEGMENT TAG,
CODED C a3
070 S011 DATA ELEMENT
IDENTIFICATION C
0098 Erroneous data
element position in segment M n..3
0104 Erroneous
component data element position C n..3
UCM MESSAGE
RESPONSE
Function: To identify a message
in the subject interchange, and
to
indicate that message's acknowledgement or
rejection
(action taken), and to identify any error
related
to the UNH and UNT segments.
010 0062 MESSAGE REFERENCE
NUMBER M an..14
020 S009 MESSAGE
IDENTIFIER M
0065 Message
type M an..6
0052 Message
version
number M an..3
0054 Message
release
number M an..3
0051 Controlling
agency M an..2
0057 Association
assigned
code C an..6
030 0083 ACTION,
CODED M an..3
040 0085 SYNTAX ERROR,
CODED C an..3
050 0013 SERVICE SEGMENT TAG,
CODED C a3
060 S011 DATA ELEMENT
IDENTIFICATION C
0098 Erroneous data
element position in segment M n..3
0104 Erroneous
component data element position C n..3
UCS SEGMENT
ERROR INDICATION
Function: To identify either a
segment containing an error or a
missing
segment, and to identify any error related to
the
complete segment.
010 0096 SEGMENT POSITION IN
MESSAGE M n..6
020 0085 SYNTAX ERROR,
CODED C an..3
UNH MESSAGE
HEADER
Function: To head, identify and
specify a message.
Note:
S009 as specified in version 1 of ISO 9735 is
described
in 5.3.3.
010 0062 MESSAGE REFERENCE
NUMBER M an..14
020 S009 MESSAGE
IDENTIFIER M
0065 Message
type M an..6
0052 Message
version
number M an..3
0054 Message
release
number M an..3
0051 Controlling
agency M an..2
0057 Association
assigned
code C an..6
030 0068 COMMON ACCESS
REFERENCE C an..35
040 S010 STATUS OF THE
TRANSFER C
0070 Sequence of
transfers M n..2
0073 First and last
transfer C a1
UNT MESSAGE
TRAILER
Function: To end and check the
completeness of a message.
010 0074 NUMBER OF SEGMENTS IN THE
MESSAGE M n..6
020 0062 MESSAGE REFERENCE
NUMBER M an..14
5.3 Composite Data Elements
5.3.1 Index of composite data elements by tag
Tag Name
S002 Interchange sender
S003 Interchange recipient
S006 Application sender's identification
S007 Application recipient's identification
S009 Message identifier
S010 Status of the transfer
S011 Data element identification
5.3.2 Index of composite data elements by name
Tag Name
S007 Application recipient's
identification
S006 Application sender's identification
S011 Data element identification
S003 Interchange recipient
S002 Interchange sender
S009 Message identifier
S010 Status of the transfer
5.3.3 Composite data element specifications
S002 INTERCHANGE
SENDER
Desc: Identification of the
sender of the interchange.
010 0004 Sender
identification M an..35
020 0007 Identification code
qualifier C an..4
030 0008 Address for reverse
routing C an..14
S003 INTERCHANGE
RECIPIENT
Desc: Identification of the
recipient of the interchange.
010 0010 Recipient
identification M an..35
020 0007 Identification code
qualifier C an..4
030 0014 Routing
address C an..14
S006 APPLICATION
SENDER'S IDENTIFICATION
Desc: Identification of the
sender's division, department etc.
from
which a group of messages is sent.
010 0040 Sender
identification M an..35
020 0007 Sender identification
qualifier C an..4
S007 APPLICATION
RECIPIENT'S IDENTIFICATION
Desc: Identification of the
recipient's division, department
etc.
for which a group of messages is intended.
010 0044 Recipient's
identification M an..35
020 0007 Recipient's identification
qualifier C an..4
S009 MESSAGE
IDENTIFIER
Desc: Identification of the type,
version etc. of the message
being
interchanged.
010 0065 Message
type M an..6
020 0052 Message version
number M an..3
030 0054 Message release
number M an..3
040 0051 Controlling
agency M an..2
050 0057 Association assigned
code C an..6
Note: The content of S009 was
specified as follows in version
1
of ISO 9735:
010 0065 Message
type M an..6
020 0052 Message version
number M n..3
030 0054 Message release
number C n..3
040 0051 Controlling
agency C an..2
050 0057 Association assigned
code C an..6
S010 STATUS OF THE
TRANSFER
Desc: Statement that the message
is one in a sequence of
transfers
relating to the same topic.
010 0070 Sequence of
transfers M n..2
020 0073 First and last
transfer C a1
S011 DATA ELEMENT
IDENTIFICATION
Desc: Identification of the
position for an erroneous data
element.
This can be the position of a simple or composite
data
element in the definition of a segment or a component
data
element in the definition a composite data element.
010 0098 Erroneous data element
position in segment M n..3
020 0104 Erroneous component data
element position C n..3
5.4 Data Elements
5.4.1 Index of data elements by tag
Tag Name
0004 Sender identification
* 0007 Identification code qualifier
0008 Address for reverse routing
0010 Recipient identification
0013 Service segment tag, coded
0014 Routing address
0020 Interchange control reference
0040 Sender identification
0044 Recipient's identification
0048 Functional group reference number
0051 Controlling agency
0052 Message version number
0054 Message release number
0057 Association assigned code
0062 Message reference number
0065 Message type
0068 Common access reference
0070 Sequence of transfers
0073 First and last transfer
0074 Number of segments in the message
0083 Action, coded
0085 Syntax error, coded
0096 Segment position in message
0098 Erroneous data element position in
segment
0104 Erroneous component data element
position
* This data element was named in three different ways in
versions 1, 2 and 3 of ISO 9735.
5.4.2 Index of data elements by name
Tag Name
0083 Action, coded
0008 Address for reverse routing
0057 Association assigned code
0068 Common access reference
0051 Controlling agency
0104 Erroneous component data element
position
0098 Erroneous data element position in
segment
0073 First and last transfer
0048 Functional group reference number
* 0007 Identification code qualifier
0020 Interchange control reference
0062 Message reference number
0065 Message type
0054 Message release number
0052 Message version number
0074 Number of segments in the message
0010 Recipient identification
0044 Recipient's identification
0014 Routing address
0096 Segment position in message
0004 Sender identification
0040 Sender identification
0070 Sequence of transfers
0013 Service segment tag, coded
0085 Syntax error, coded
* This data element was named in three different ways in
versions 1, 2 and 3 of ISO 9735.
5.4.3 Data element specifications
0004 Sender identification
Desc: Name or coded representation of the sender of
a data
interchange.
Repr: an..35
0007 Identification code qualifier
Desc: Qualifier referring to the source of codes
for the
identifiers of
interchanging partners.
Repr: an..4
0008 Address for reverse routing
Desc: Address specified by the sender of an
interchange to be
included by the
recipient in the response interchanges to
facilitate
internal routing.
Repr: an..14
0010 Recipient identification
Desc: Name or coded representation of the recipient
of a data
interchange.
Repr: an..35
0013 Service segment tag, coded
Desc: Code identifying a service segment.
Repr: a3
0014 Routing address
Desc: Address specified by the recipient of an
interchange to
be included by the
sender and used by the recipient for
routing of
received interchanges inside his
organization.
Repr: an..14
0020 Interchange control reference
Desc: Unique reference assigned by the sender to an
interchange.
Repr: an..14
0040 Sender identification
Desc: Name or code identifying the originating
division,
department etc.
within the sender's organization.
Repr: an..35
0044 Recipient's identification
Desc: Name or code identifying the division,
department etc.
within the
recipient's organization for which the group
of messages is
intended.
Repr: an..35
0048 Functional group reference number
Desc: Reference number for the functional group
assigned by and
unique within the
sender's division, department etc.
Repr: an..14
0051 Controlling agency
Desc: Code identifying the agency controlling the
specification,
maintenance and
publication of the message type.
Repr: an..2
0052 Message version number
Desc: Version number of a message type.
Repr: an..3
Note: The representation of 0052 was specified as
n..3 in version 1
of ISO 9735.
0054 Message release number
Desc: Release number within the current message
type version number
(0052).
Repr: an..3
Note: The representation of 0054 was specified as
n..3 in version 1
of ISO 9735.
0057 Association assigned code
Desc: Code, assigned by the association responsible
for the design
and maintenance of
the message type concerned, which further
identifies the
message.
Repr: an..6
0062 Message reference number
Desc: Unique message reference assigned by the
sender.
Repr: an..14
0065 Message type
Desc: Code identifying a type of message and
assigned by its
controlling
agency.
Repr: an..6
0068 Common access reference
Desc: Reference serving as a key to relate all
subsequent transfers
of data to the
same business case or file.
Repr: an..35
0070 Sequence of transfers
Desc: Number assigned by the sender indicating that
the message is
an addition or
change of a previously sent message relating
to the same topic.
Repr: n..2
0073 First and last transfer
Desc: Indication used for the first and last
message in a sequence
of the same type
of message relating to the same topic.
Repr: a1
0074 Number of segments in the message
Desc: Control count of number of segments in a
message.
Repr: n..6
0083 Action, coded
Desc: A code indicating acknowledgement, or
rejection (the action
taken) of a
subject interchange, or part of the subject
interchange.
Repr: an..3
0085 Syntax error, coded
| Desc: A code indicating the syntax error detected.
Repr: an..3
0096 Segment position in message
Desc: The numerical count position of a specific
segment that is
within the actual
received message. The numbering starts
with, and
includes, the UNH segment as segment number 1. To
identify a segment
that contains an error, this is the
numerical count
position of that segment. To report that a
segment is
missing, this is the numerical count position of
the last segment
that was processed before the position where
the missing
segment was expected to be. A missing segment
group is denoted
by identifying the first segment in the
group as missing.
Repr: n..6
0098 Erroneous data element position in
segment
Desc: The numerical count position of the simple or
composite data
element in error.
The segment code and each following simple
or composite data
element defined in the segment description
shall cause the
count to be incremented. The segment tag has
position number 1.
Repr: n..3
0104 Erroneous component data element
position
Desc: The numerical count position of the component
data element in
error. Each
component data element position defined in the
composite data
element description shall cause the count to
be
incremented. The count starts at 1.
Repr: n..3
5.5 Code Lists
0013 Service segment tag, coded
Desc: Code identifying a service segment.
Repr: a3
UNA Service string advice
UNB Interchange header segment
UNE Functional group trailer
segment
UNG Functional group header
segment
UNH Message header segment
UNT Message trailer segment
UNZ Interchange trailer segment
0083 Action, coded
Desc: A code indicating acknowledgement, or rejection
(the action
taken) of a subject
interchange, or part of the subject
interchange.
Repr: an..3
4 This level and all
lower levels rejected
The
corresponding referenced-level and all its lower
referenced-levels
are rejected. One or more errors are
reported
at this reporting-level or a lower
reporting-level.
7 This level
acknowledged, next lower level acknowledged if
not
explicitly rejected
The
corresponding referenced-level is acknowledged. All
messages
or functional groups at the next lower
referenced-level
are acknowledged except those explicitly
reported
as rejected at the next lower reporting-level in
this
CONTRL message.
8 Interchange received
Indication
of interchange receipt, see clause 3.
0085 Syntax error, coded
Desc: A code indicating the syntax error detected.
Repr: an..3
2 Syntax version or
level not supported
Notification
that the syntax version and/or level is not
supported
by the recipient.
7 Interchange recipient
not actual recipient
Notification
that the Interchange recipient (S003) is
different
from the actual recipient.
12 Invalid value
Notification
that the value of a simple data element,
composite
data element or component data element does not
conform
to the relevant specifications for the value.
13 Missing
Notification
that a mandatory (or otherwise required)
service
or user segment, data element, composite data
element
or component data element is missing
14 Value not supported in this
position
Notification
that the recipient does not support use of
the
specific value of an identified simple data element,
composite
data element or component data element in the
position
where it is used. The value may be valid
according
to the relevant specifications and may be
supported
if it is used in another position.
15 Not supported in this
position
Notification
that the recipient does not support use of
the
segment type, simple data element type, composite
data
element type or component data element type in the
specific
in the identified position.
16 Too many constituents
Notification
that the identified segment contained to
many
data elements or that the identified composite data
element
contained too many component data elements.
17 No agreement
No
agreement exists that allows receipt of an
interchange,
functional group or message with the value
of
the identified simple data element, composite data
element
or component data element.
18 Unspecified error
Notification
that an error has been identified, but the
nature
of the error is not reported.
19 Invalid decimal notation
Notification
that the character indicated as decimal
notation
in UNA is invalid, or the decimal notation used
in
a data element is not consistent with the one
indicated
in UNA.
20 Character invalid as
service character
Notification
that a character advised in UNA is invalid
as
service character.
21 Invalid character(s)
Notification
that one or more character(s) used in the
interchange
is not a valid character as defined by the
syntax
level indicated in UNB. The invalid character is
part
of the referenced-level, or followed immediately
after
the identified part of the interchange.
22 Invalid service
character(s)
Notification
that the service character(s) used in the
interchange
is not a valid service character as advised
in
UNA or not one of the service characters in the syntax
level
indicated in UNB or defined in an interchange
agreement.
If the code is used in UCS or UCD, the invalid
character
followed immediately after the identified part
of
the interchange.
23 Unknown Interchange sender
Notification
that the Interchange sender (S002) is
unknown.
24 Too old
Notification
that the received interchange or functional
group
is older than a limit specified in an IA or
determined
by the recipient.
25 Test indicator not
supported
Notification
that a test processing could not be
performed
for the identified interchange, functional
group
or message.
26 Duplicate detected
Notification
that a possible duplication of a previously
received
interchange, functional group or message has
been
detected. The earlier transmission may have been
rejected.
27 Security function not
supported
Notification
that a security function related to the
referenced-level
or data element is not supported.
28 References do not match
Notification
that the control reference in UNB/UNG/UNH
does
not match the one in UNZ/UNE/UNT.
29 Control count does not
match number of instances received
Notification
that the number of functional
groups/messages/segments
does not match the number given
in
UNZ/UNE/UNT.
30 Functional groups and
messages mixed
Notification
that individual messages and functional
groups
have been mixed at the same level in the
interchange.
31 More than one message type
in group
Notification
that different message types are contained
in
a functional group.
32 Lower level empty
Notification
that the interchange did not contain any
messages
or functional groups, or a functional group did
not
contain any messages.
33 Invalid occurrence outside
message or functional group
Notification
that an invalid segment or data element
occurred
in the interchange, between messages or between
functional
groups. Rejection is reported at the level
above.
34 Nesting indicator not
allowed
Notification
that explicit nesting has been used in a
message
where it shall not be used.
35 Too many segment
repetitions
Notification
that a segment was repeated too many times.
36 Too many segment group
repetitions
Notification
that a segment group is repeated to many
times.
37 Invalid type of
character(s)
Notification
that one or more numeric characters were
used
in an alphabetic (component) data element or that
one
or more alphabetic characters were used in a numeric
(component)
data element.
38 Missing digit in front of
decimal sign
Notification
that a decimal sign is not preceded by one
or
more digits.
39 Data element too long
Notification
that the length of the data element received
exceeded
the maximum length specified in the data element
description.
40 Data element too short
Notification
that the length of the data element received
is
shorter than the minimum length specified in the data
element
description.
41 Permanent communication
network error
Notification
that a permanent error was reported by the
communication
network used for transfer of the
interchange.
Re-transmission of an identical interchange
with
the same parameters at network level will not
succeed.
42 Temporary communication
network error
Notification
that a temporary error was reported by the
communication
network used for transfer of the
interchange.
Re-transmissions of an identical interchange
may
succeed.
43 Unknown interchange
recipient
Notification
that the interchange recipient is not known
by
a network provider.
ANNEX
A
Examples
of use of action codes in CONTRL
(This annex is an integral
part of the message definition.)
The tables below describe several example cases. The following is
described for each case:
- the action taken,
- the error that occurred, if any
- the action codes used in the UCI, UCF and UCM segments.
Each example focuses on a part of the subject interchange, or the
whole interchange. It is assumed that the other parts of the
interchange are correct, if not otherwise stated.
The first table gives examples where functional groups are used, the
second gives examples where they are not used.
Legend:
-
= Segment not used (unless redundant reporting
occurs)
4, 7, 8 = Action code used in
the segment indicated in
the
column header
+-----------------------------+----------------------+--+--+--+
| | |
U| U| U|
| Examples where functional | Type of error
and | C| C| C|
| groups are
used |
comments | I|
F| M|
| | | | | |
+--+--------------------------+----------------------+--+--|--+
| 1| Message rejected, one or | Error in user data. | 7| 7|
4|
| | more other messages
in | | | | |
| | the functional group are
| | | | |
| |
acknowledged. | | | | |
|--+--------------------------+----------------------+--+--+--|
| 2| Message acknowledged. | Error in
other | 7| 7| -|
| | |
message(s) in the | | | |
| | |
group. | | | |
|--+--------------------------+----------------------+--+--+--|
| 3| All messages in the | Some error
in the | 7| 7| 4|
| | group are rejected. |
messages. | | | |
|--+--------------------------+----------------------+--+--+--|
| 4| The whole group is | Error
at group level.| 7| 4| -|
| |
rejected. | | | | |
|--+--------------------------+----------------------+--+--+--|
| 5| The whole group is | No
errors in group. | 7| -| -|
| |
acknowledged. |
Other group in error.| | | |
|--+--------------------------+----------------------+--+--+--|
| 6| The whole interchange is | Error at interchange | 4| -| -|
| |
rejected. |
level. | | | |
|--+--------------------------+----------------------+--+--+--|
| 7| The whole interchange is | No errors
in | 7| -| -|
| |
acknowledged. |
interchange. | | | |
|--+--------------------------+----------------------+--+--+--|
| 8| Indication of interchange| No errors in checked | 8| -| -|
| | receipt, see clause 3. |
parts. | | | |
| | No messages or groups
are| | | | |
| | reported in this
CONTRL | | | | |
| |
message. | | | | |
+--+--------------------------+----------------------+--+--+--+
+--+--------------------------+----------------------+--+--+--+
| | |
U| U| U|
| Examples where functional | Type of error
and | C| C| C|
| groups are not
used |
comments | I|
F| M|
| | | | | |
|--+--------------------------+----------------------+--+--+--|
| 9| Message rejected, one or | Error in user data. | 7| -|
4|
| | more other messages
in | | | | |
| | the interchange
are | | | | |
| |
acknowledged. | | | | |
|--+--------------------------+----------------------+--+--+--|
|10| Message acknowledged, | Error in the
other | 7| -| -|
| | other messages in the |
message(s). | | | |
| | interchange are
rejected.| | | | |
|--+--------------------------+----------------------+--+--+--|
|11| All messages in the | Some error
in the | 7| -| 4|
| | interchange are rejected.|
messages. | | | |
|--+--------------------------+----------------------+--+--+--|
|12| Message acknowledged, | Error in zero
or | 7| -| 7|
| | other messages in the | more other
messages. | | | |
| | interchange
are | | | | |
| | acknowledged or
rejected.| | | | |
| | Redundant reporting
of | | | | |
| | the
message. | | | | |
|--+--------------------------+----------------------+--+--+--|
|13| Indication of interchange| No errors in checked | 8| -| -|
| | receipt, see clause 3. |
parts. | | | |
| | No messages are reported
| | | | |
| | in this CONTRL
message. | | | | |
|--+--------------------------+----------------------+--+--+--|
|14| The whole interchange is | Error at interchange | 4| -| -|
| |
rejected. |
level. | | | |
|--+--------------------------+----------------------+--+--+--|
|15| The whole interchange is | No errors
in | 7| -| -|
| |
acknowledged. |
interchange. | | | |
+--+--------------------------+----------------------+--+--+--+
ANNEX
B
Use
of error codes
(This annex is an integral part of the
message definition.)
The table below describes at which reporting-level an error code may
be used.
Legend:
x = may be used
- = shall not be used
+----+----------------------------------+---+---+---+---+---+
| | |
U | U | U | U | U |
| No | Code
name |
C | C | C | C | C |
| | |
I | F | M | S | D |
|----+----------------------------------+---+---+---+---+---|
| 2 | Syntax version or level
not | x | - | - | - | - |
| |
supported | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 7 | Interchange recipient not actual | x | - |
- | - | - |
| |
recipient | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 12 | Invalid
value |
x | x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 13 |
Missing |
x | x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 14 | Value not supported in
this | x | x | x | x | x |
| |
position | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 15 | Not supported in this position | x |
x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 16 | Too many
constituents | x |
x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 17 | No
agreement |
x | x | x | - | - |
|----+----------------------------------+---+---+---+---+---|
| 18 | Unspecified
error |
x | x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 19 | Invalid decimal
notation | x | - | - | - | x |
|----+----------------------------------+---+---+---+---+---|
| 20 | Character invalid as
service | x | - | - | - | - |
| |
character | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 21 | Invalid
character(s) |
x | x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 22 | Invalid service
character(s) | x | x | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 23 | Unknown Interchange
sender | x | - | - | - | - |
|----+----------------------------------+---+---+---+---+---|
| 24 | Too
old |
x | x | - | - | - |
|----+----------------------------------+---+---+---+---+---|
| 25 | Test indicator not
supported | x | x | x | - | - |
|----+----------------------------------+---+---+---+---+---|
| 26 | Duplicate
detected |
x | x | x | - | - |
|----+----------------------------------+---+---+---+---+---|
| 27 | Security function not supported | x | x |
x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 28 | References do not
match | x | x | x | - | - |
|----+----------------------------------+---+---+---+---+---|
| 29 | Control count does not
match | x | x | x | - | - |
| | number of instances
received | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 30 | Functional groups and messages | x |
x | x | - | - |
| |
mixed | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 31 | More than one message type
in | - | x | x | - | - |
| |
group | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 32 | Lower level
empty |
x | x | - | - | - |
|----+----------------------------------+---+---+---+---+---|
| 33 | Invalid occurrence
outside | x | x | - | - | - |
| | message or functional
group | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 34 | Nesting indicator not
allowed | - | - | x | x | x |
|----+----------------------------------+---+---+---+---+---|
| 35 | Too many segment
repetitions | - | - | - | x | - |
|----+----------------------------------+---+---+---+---+---|
| 36 | Too many segment
group | - | - | - | x | -
|
| |
repetitions | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 37 | Invalid type of
character(s) | x | x | x | - | x |
|----+----------------------------------+---+---+---+---+---|
| 38 | Missing digit in front of decimal| - | - | - | - | x
|
| |
sign | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 39 | Data element too
long | x | x | x |
- | x |
|----+----------------------------------+---+---+---+---+---|
| 40 | Data element too
short | x | x | x | - | x
|
|----+----------------------------------+---+---+---+---+---|
| 41 | Permanent communication network | x | - |
- | - | - |
| |
error | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 42 | Temporary communication network | x | - |
- | - | - |
| |
error | | | | | |
|----+----------------------------------+---+---+---+---+---|
| 43 | Unknown interchange
recipient | x | - | - | - | |
+----+----------------------------------+---+---+---+---+---+
ANNEX
C
Use of code values in data element 0013 Service segment
tag, coded
(This annex is an integral part of the
message definition.)
The code values that may be used in data element 0013 depends on the
segment where 0013 is used, as follows:
+---------+-------------------------------+
| Segment | Allowed
code values in 0013 |
|---------+-------------------------------|
| UCI | UNA,
UNB and UNZ |
|---------+-------------------------------|
| UCF | UNG
and
UNE |
|---------+-------------------------------|
| UCM | UNH
and
UNT |
+---------+-------------------------------+
ANNEX
D
Conditions for
presence of conditional segments/data
elements
(This annex is an integral part of the
message definition.)
When an error is reported, data element 0085 shall be present in the
segment in CONTRL that references the position of the error.
If data element 0013 or S011 is present in a segment, data element
0085 shall be present.
When an error is reported, data elements 0013 and S011 shall be
present in the segment in CONTRL referencing the position of the
error, unless the error position is identified by the associated data
element 0085.
Data element 0013 shall be present if composite S011 is present in a
segment.
Data element 0104 shall only be present if an error in a component
data element is reported.
Those simple, composite or component elements that may be copied into
CONTRL from the subject interchange shall be present if they were
present in the subject interchange.