ISO/TC 154-UN/CEFACT
Joint Syntax Working Group (JSWG)
http://www.gefeg.com/jswg
The International Organization
for Standardization
The United Nations Economic
Commission for Europe

  

Syntax and service report message (CONTRL)

  
                                 UN/EDIFACT

                    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

   ————————————————————————————&