                              UN/EDIFACT

                UNITED NATIONS STANDARD MESSAGE (UNSM)

           Syntax and service report message for batch EDI




























                                            Message Type : CONTRL
                                            Version      : 4
                                            Release      : V4R1
                                            Contr. Agency: UN

                                            Revision     : 1
                                            Date         : 2001-11-01






SOURCE: Joint Syntax Working Group (JSWG)



                               CONTENTS

           Syntax and service report message for batch EDI

0.   INTRODUCTION

1.   SCOPE

     1.1   Functional definition

     1.2   Field of application

     1.3   Principles

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








----------------------------------------------------------------------
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 is a new part which has been added to ISO 9735.
       
       It provides the capability for the automatic preparation of a
       message in response to a received interchange, group, message
       or package, to:
       
       *  acknowledge a correct syntactical structure; or
       *  to reject an incorrect syntactical structure.
       
       In the case of rejection, the message lists any syntactical
       errors or unsupported functions encountered.
       
       In addition to the above, the message may be used to indicate
       only the receipt of an interchange.
       
       It is based upon a similar service message developed and
       published by UN/ECE for use with earlier versions of ISO 9735.

1.     SCOPE

       This part of ISO 9735 defines the syntax and service report
       message for batch EDI, CONTRL.

1.1    Functional Definition

       CONTRL is a message syntactically acknowledging or rejecting,
       with error indication, a received interchange, group, message,
       or package.
       
       A CONTRL message shall be used to:
       
       a)  acknowledge or reject a received interchange, group,
       message, or package and list any syntactical errors or
       unsupported functionality contained therein, or
       
       b)  indicate only the receipt of an interchange.

1.2    Field of Application

       This specification of CONTRL shall be used for version 4 of the
       EDIFACT syntax (ISO 9735), and for response to interchanges
       created using Parts 1, 2, 5, 6, 7, 8 and/or 9 of ISO
       9735/Version 4 only.

1.3    Principles

       Support for submission and receipt of the CONTRL message type
       shall be agreed between partners, as shall the functionalities
       to be supported. Support for receipt of CONTRL messages shall
       be indicated either by the acknowledgement request in the
       subject interchange UNB segment or in an interchange agreement.
       
       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 shall be 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 provides:
       -  indication of the action taken by the recipient as the
       result of a syntactical check of the subject interchange, or
       alternatively,
       -  only indication of interchange receipt.
       
       In the first case, the action (acknowledgement or rejection)
       indicates the result of a syntactical check of the complete
       received interchange.  An action may be indicated for the
       complete interchange, or it may be indicated for individual
       parts of it.  Thus, some messages, packages, or groups may be
       acknowledged and others may be rejected.  The CONTRL message
       shall indicate the action for all parts of the subject
       interchange.
       
       In the second case, there is indication of interchange receipt
       only.
       
       During a syntactical check, the interchange, or part of it,
       shall be checked for compliance with:
       -  the EDIFACT syntax rules (ISO 9735),including rules for use
       of service segments and
       -  the syntactical aspects in specifications for the message
       type(s) received.
       
       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 or package 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
       shall be determined by the recipient.  The recipient may for
       example, choose to acknowledge a data element exceeding the
       specified maximum length.
       
       An interchange containing a CONTRL message generated by the
       recipient of the subject interchange shall contain the same
       sender and receiver identifications in its UNB segment as was
       in the subject interchange, only reversed.
       
       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 never be sent
       in a group.
       
       1.3.1 Relationship 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,  provides
       indication of interchange receipt.  The second reports the
       action taken after the syntax check of the subject interchange.
        The action code in the UCI segment shall indicate if the
       message is of the first or second type.
       
       If a request for acknowledgement is indicated in the subject
       interchange UNB, then the second type of CONTRL message shall
       be sent to report the results of a syntax check of the subject
       interchange (unless the subject interchange contains only a
       CONTRL message or messages).  The optionality of the first
       message implies that, if any CONTRL message is sent at all, the
       second type of CONTRL message shall always be sent, (unless the
       subject interchange contains only a CONTRL message or
       messages).  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 shall only report the action taken for one
       subject interchange, i.e.  it shall not refer to several
       subject interchanges, or to parts of several subject
       interchanges.
       
       Segment groups 1 and 3 shall not be used in a CONTRL message
       which provides indication of interchange receipt.  If the
       subject interchange contains groups (of messages and/or
       packages), only segment group 3 shall be used in the CONTRL
       message.  If groups are not used in the subject interchange,
       only segment group 1 shall be 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 or per received package.
       
       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.
       
       The CONTRL message also provides the means to acknowledge or
       reject a complete interchange or a complete group, without
       referencing messages, packages, or groups contained in it.
       
       The action (acknowledgement or rejection) shall be indicated by
       the action code in the UCI, UCF and UCM.  This code may
       indicate the action for the corresponding referenced-level, and
       in some cases also for its lower levels.
       
       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 group and all messages or packages within it are
       implicitly rejected if the action code in the UCI segment
       indicate rejection of the complete subject interchange.  Also,
       a message or package is implicitly acknowledged when the action
       code in UCI or UCF indicates acknowledgement of messages and
       packages at the next lower level, and no UCM rejecting the
       message or package is present.
       
       Action codes 4 and 7 shall only be used in CONTRL messages
       reporting the action after complete check of the interchange. 
       Action code 8 shall only be used in CONTRL messages which
       provide indication of interchange receipt.  Codes are specified
       in element 0083 Action, coded.
       
       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.
       
       Each reporting-level (i.e. the UCI, UCF, UCM, UCS and UCD
       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 shall be free to choose
       which error to report.  Several CONTRL messages shall not be
       sent in order to report several errors, and no more than one
       reporting-level shall be present for each instance of a
       referenced-level.
       
       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 shall be
       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 is defined, a more general
       (and imprecise) error code should not be used.  Similarly, the
       position of the error should 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 shall be 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 shall then be reported by other
       means than CONTRL, unless all parties processing the CONTRL
       message have agreed in an IA that copying of erroneous data
       elements into the CONTRL message is permitted.
       
       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, package, or
       group.  Similarly, redundant UCM segments may acknowledge
       messages or packages in a group when the code is used in UCF.
       
       1.3.6 Re-transmission
       
       The conditions which determine the requirements to re-send an
       interchange, group, message, or package shall be agreed between
       the interchanging partners outside the scope of CONTRL.
       
       1.3.7 Acknowledgement or rejection of CONTRL messages
       
       No CONTRL message of the second type (acknowledgement or
       rejection) shall be sent in response to received interchanges
       containing only a CONTRL message, or messages.  Errors in
       received CONTRL messages shall 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.
       
       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.

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 referenced levels(s) of the subject
       interchange acknowledged, and
       -  has checked that there are no fatal syntactic errors in the
       acknowledged referenced-level 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
       (referenced-levels of the) service segments, and
       -  has accepted responsibility 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 subject interchange, and
       -  acknowledges the parts of the subject 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 responsibility for notifying the sender of
       acknowledgement or rejection of the other parts of the subject
       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
       -  cannot acknowledge the subject 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 subject interchange.
       
       (To) report
       
       To indicate the action (acknowledgement or rejection) taken for
       a 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 and any security segments used
       to secure the subject interchange referenced in the UCI segment
       -  the UNG and UNE segments and any security segments used to
       secure the group referenced in the UCF segment
       -  a complete message or a complete package and any security
       segments used to secure the message or package referenced in
       the UCM segment
       -  a segment in a message body, referenced in the UCS segment
       -  a stand-alone, 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 Branching
       Diagram and Segment Table which indicate mandatory, conditional
       and repeating requirements.

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 shall contain the following data in segment UNH,
       composite S009:
       
       Data element  0065 CONTRL
                     0052 4
                     0054 1
                     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.  It can also identify errors related to the USA, USC,
       USD, USH, USR, UST, or USU security segments when they appear
       at the interchange level.  Depending on the action code, it may
       also indicate the action taken on the groups, messages, and
       packages within that interchange.
       
       The subject interchange shall be 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,
       UNZ, USA, USC, USD, USH, USR, UST, or USU segment may be
       identified.  If no segment is identified, the error relates to
       the complete interchange.


0030   Segment group 1:  UCM-SG2
       A group of segments sent in response to a message or package in
       the subject interchange identified in the UCI segment.  This
       segment group shall only be used if the subject interchange
       does not contain groups.

0040      UCM, Message/package response
          A segment identifying a message or package in the subject
          interchange, indicating that message's or package's
          acknowledgement or rejection (action taken), and identifying
          any error related to the UNH, UNT, UNO, and UNP segments. 
          It can also identify errors related to the USA, USC, USD,
          USH, USR, UST, or USU security segments when they appear at
          the message or package level.
          
          A message shall be 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, UNT, USA, USC, USD, USH, USR, UST, or USU
          segment may be identified.  If no segment is identified, the
          error relates to the complete message.
          
          A package shall be identified by copying its Reference
          Identification and Package Reference Number data elements
          into the identical data elements in this segment.  An
          erroneous or missing UNO, UNP, USA, USC, USD, USH, USR, UST,
          or USU segment may be identified.  If no segment is
          identified, the error relates to the complete package.


0050      Segment group 2:  UCF-SG4
          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 stand-alone, 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 group in the subject
       interchange identified in the UCI segment.  This segment group
       shall only be used if the subject interchange contains groups.

0090      UCF, Group response
          A segment identifying a 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. It can also identify errors
          related to the USA, USC, USD, USH, USR, UST, or USU security
          segments when they appear at the group level. Depending on
          the action code, it may also indicate the action taken on
          the messages and packages within that group.
          
          The group shall be identified by copying its Application
          Sender's Identification, Application Recipient's
          identification, and Group Reference Number data elements
          into the identical data elements in this segment.  An
          erroneous or missing UNG, UNE, USA, USC, USD, USH, USR, UST,
          or USU segment may be identified.  If no segment is
          identified, the error relates to the complete group.


0100      Segment group 4:  UCM-SG5
          A group of segments sent in response to a message or package
          in the group identified in segment group 3.

0110         UCM, Message/package response
             A segment identifying a message or package in the subject
             interchange, indicating that message's or package's
             acknowledgement or rejection (action taken), and
             identifying any error related to the UNH, UNT, UNO, and
             UNP segments.  It can also identify errors related to the
             USA, USC, USD, USH, USR, UST, or USU security segments
             when they appear at the message or package level.
             
             A message shall be 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, UNT, USA, USC, USD, USH, USR,
             UST, or USU segment may be identified.  If no segment is
             identified, the error relates to the complete message.
             
             A package shall be identified by copying its Reference
             Identification and Package Reference Number data elements
             into the identical data elements in this segment.  An
             erroneous or missing UNO, UNP, USA, USC, USD, USH, USR,
             UST, or USU segment may be identified.  If no segment is
             identified, the error relates to the complete package.


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 stand-alone,
                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 and the control reference number of the message.

4.2    Data segment index (Alphabetical sequence by tag)

          UCD Data element error indication
          UCF Group response
          UCI Interchange response
          UCM Message/package 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             Notes

0010   UNH Message header                            M   1             
0020   UCI Interchange response                      M   1             

0030       ÄÄÄÄÄ Segment group 1  ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ C   999999ÄÄÄÄÄÄ¿ 1
0040   UCM Message/package 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ÄÄÄÄÄÄ¿ 1
0090   UCF Group response                            M   1           ³ 
                                                                     ³
0100       ÄÄÄÄÄ Segment group 4  ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ C   999999ÄÄÄÄÄ¿³ 
0110   UCM Message/package 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             


DEPENDENCY NOTES:

1.  D4(0030, 0080) One or none
