Return to Stylus Studio EDIFACT home page. Return to Stylus Studio EDIFACT 30000 Messages page. Syntax and service report message
0. INTRODUCTIONThis 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. SCOPE1.1. Functional DefinitionCONTRL is a message syntactically acknowledging or rejecting, with error indication, a received interchange, functional group or message. A CONTRL message can be used to:
1.2. Field of ApplicationThe 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. PrinciplesThis 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
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:
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 interchangeA 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:
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 usageThe 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 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 errorsErrors 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 messageThe 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 actionIf 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-transmissionThe 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 messagesNo 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 typeRequirements 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. REFERENCESSee UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General Introduction, Section 1. 3. TERMS AND DEFINITIONS3.1. Standard terms and definitionsSee UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General Introduction, Section 2. 3.2. Message terms and definitionsAcknowledgement Acknowledgement implies that the recipient of the subject interchange
Indication of interchange receipt Indication of interchange receipt implies that the recipient of the subject interchange
Rejection Rejection implies that the recipient of the subject 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:
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 DEFINITION4.1. Data Segment ClarificationThis section should be read in conjunction with the Branching Diagram and Segment Table which indicate mandatory, conditional and repeating requirements. 0010 UNH, Message headerA 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:
0020 UCI, Interchange responseA 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-SG2A 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 responseA 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-UCDA 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 indicationA 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 indicationA 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-SG4A 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 responseA 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-SG5A group of segments sent in response to a message in the functional group identified in segment group 3. 0110 UCM, Message responseA 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-UCDA 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 indicationA 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 indicationA 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 trailerA service segment ending a message, giving the total number of segments in the message and the control reference number. 4.2. Data segment index (Alphabetical sequence by tag)
4.3. Message structure4.3.1. Segment table
Return to Stylus Studio EDIFACT 30000 Messages page. |
Site Map | Privacy Policy | Terms of Use | Trademarks |