0. INTRODUCTION
1. SCOPE
   1. Functional definition
   2. Field of application
   3. Principles
2. REFERENCES
3. TERMS AND DEFINITIONS
   1. Standard terms and definitions
   2. Message terms and definitions
4. MESSAGE DEFINITION
   1. Data segment clarification
   2. Data segment index (alphabetical sequence)
   3. Message structure
      1. Segment table

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.

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

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:

1. acknowledge or reject a received interchange, group, message, or package and list any syntactical errors or unsupported functionality contained therein, or
2. indicate only the receipt of an interchange.

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.

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.

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.

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.

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.

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.

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.

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.

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.

See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General Introduction, Section 1.

See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General Introduction, Section 2.

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.

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:

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: 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 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.