GB/T 14805.4-2000 Application-level syntax rules for electronic data interchange for administration, commerce and transport (Syntax version number: 4) Part 4: Batch electronic data interchange syntax and service report message (message type CONTRL)
Some standard content:
ICS35.240.60
National Standard of the People's Republic of China
GB/T 14805.4—2000
idtIS09735-4：1998
Application level syntax rules for electronic data interchange for administration, commerce and transport (EDIFACT) (Syntax version number: 4) - Part 4: Syntax and service report message for batch electronic data interchange (message type CONTRL) EDI (Messagetype—ContrL)
Released on October 17, 2000
Implemented on August 1, 2001
State Administration of Quality and Technical Supervision
GB/T14805.4—2000
iKANiKAca-wwW.bzxz.Net
This standard is equivalent to ISO9735-4:1998 "Application-level syntax rules for electronic data interchange for administration, commerce and transport (Syntax version number: 4) Part 4: Batch electronic data interchange syntax and service report messages (message type is CONTRL)". The GB/T14805 series of standards, under the general title of "Application-level syntax rules for electronic data interchange in administration, commerce and transport (Syntax version number: 4)", currently includes the following 9 parts: Part 1: Common syntax rules and syntax service directory Part 2: Syntax rules specific to batch electronic data interchange Part 3: Syntax rules specific to interactive electronic data interchange Part 4: Syntax and service report message for batch electronic data interchange (message type is CONTRL) Part 5: Security rules for batch electronic data interchange (authenticity, integrity and non-repudiation of origin) Part 6: Security authentication and confirmation message (message type is AUTACK) Part 7: Security rules for batch electronic data interchange (confidentiality) Part 8: Related data in electronic data interchange Part 9: Key and certificate management message (message type is KEYMAN) New parts may be added in the future.
GB/T14805 series standards correspond to the fourth edition of ISO9735. Although ISO9735:1998 replaces the earlier editions, according to the relevant provisions of ISO9735:1998, users can still use the earlier editions. In view of this, GB/T14805-1993, which was formulated in 1993 in accordance with the 1988, 1990 and 1992 editions of ISO9735, can also continue to be used for a period of time in the future. Therefore, the release and implementation of this series of standards does not replace GB/T14805-1993. Appendix A of this standard is the appendix of the standard.
This standard is formulated by my country for the first time.
This standard is proposed by the China Standards Research Center. This standard is under the jurisdiction of the National Technical Committee for Electronic Business Standardization. This standard is jointly drafted by the China Standards Research Center, the Information Center of the General Administration of Customs, and the Water Transport Science Research Institute of the Ministry of Communications. The main drafters of this standard are: Deng Jie, Cheng Nufan, Li Ying, Hu Hanjing, Wei Hong, He Yu, Huang Deyu. I
GB/T14805.4—2000
ISOForeword
ISO (International Organization for Standardization) is a worldwide alliance of national standards bodies (ISO national member groups). The formulation of international standards is generally completed through ISO technical committees. Each member group interested in a project for which a technical committee has been established has the right to express its opinions to the technical committee. Any official and unofficial international organization that has a liaison relationship with ISO can directly participate in the formulation of international standards. ISO and IEC (International Electrotechnical Commission) work closely in all areas of electrotechnical standards. The draft international standard formally adopted by the technical committee must be voted on by the member groups, and at least 75% of the member groups must vote in favor to be published as an international standard.
This International Standard was prepared by the United Nations Economic Commission for Europe (UN/ECE) Department of Trade (as part of UN/EDIFACT) and was formally adopted by ISO/TC154 (Technical Committee on Documents and Data Elements for Administration, Commerce and Industry) through the "fast-track voting procedure". Since this standard replaces earlier versions and uses "4" in the mandatory data element 0002 (Syntax version number) of the exchange header (UNB) segment to identify this version, exchanges that continue to use the syntax rules of earlier releases should use the following syntax version numbers to distinguish them from each other. ISO9735:1988 - Syntax version number: 1
ISO9735:1988 (1990 ISO 9735:1988 (revised and reprinted edition in 1990) and its amendment No. 1 of 1992 - Syntax version number: 3 ISO 9735 consists of the following parts under the general title "Application level syntax rules for electronic data interchange for administration, commerce and transport (Syntax version number: 4)": ISO 9735-1 Common syntax rules and syntax service directory ISO 9735-2 Syntax rules specific to batch electronic data interchange ISO 9735-3 Syntax rules specific to interactive electronic data interchange ISO 9735-4 Batch electronic data interchange syntax and service report messages (message type is CON TRL) ISO9735-5 Security rules for batch electronic data interchange (authenticity, integrity and non-repudiation of origin) ISO9735-6 Security authentication and confirmation message (message type AUTACK) ISO9735-7 Security rules for batch electronic data interchange (confidentiality) ISO9735-8 Related data in electronic data interchange ISO9735-9 Key and certificate management message (message type KEYMAN) New parts may be added in the future.
Appendix A is an appendix to the standard.
ISO Introduction
This standard provides the function of automatically making CONTRL messages, which are used to respond to received exchanges, groups, messages or packages to: - confirm the correct syntax structure, or
- reject the incorrect syntax structure.
In the case of rejection, this message lists the syntax errors or unsupported functions. In addition, this message can also be used to indicate the receipt of the interchange. This standard is based on a similar service message developed and published by UN/ECE in conjunction with an earlier version of ISO 9735.
1 Scope
National Standard of the People's Republic of China
Application level syntax rules for electronic data interchange for administration, commerce and transport (EDIFACT) (Syntax version number: 4) Part 4: Syntax and service report message for batch EDIFACT) (Message type CONTRL) Electronic data interchange for administration, commerce and transport (EDIFACT)-Application level syntax rules (Syntax version number: 4)
Part 4: Syntax and service report message for batch EDIFACT)
(Message type CONTRL) This standard defines the syntax and service report message for batch electronic data interchange (CONTRL). 2 Conformance
KAoMiKAca-
GB/T14805.4—2000
idt ISO 9735-4:1998
Conformance to a standard means supporting all its requirements, including all options. If not all options are supported, any conformance statement shall contain a description identifying those options that are declared to be conformant. Data exchanged are in conformance if their structure and representation conform to the grammatical rules specified in this standard. Devices supporting this standard are in conformance when they are able to create and/or interpret data whose structure and representation conform to this standard.
Conformance with this standard shall include conformance with GB/T14805.1 and GB/T14805.2. When clauses defined in related standards are identified in this standard, these clauses shall constitute an integral part of the consistency determination conditions. 3. Referenced standards
The clauses contained in the following standards constitute the clauses of this standard through reference in this standard. When this standard is published, the versions shown are valid. All standards will be revised, and the parties using this standard should explore the possibility of using the latest versions of the following standards. GB/T14805.1—1999 Application-level grammar rules for electronic data interchange for administration, commerce and transport (grammar version number: 4) Part 1: Common grammar rules and grammar service directory (idtISO9735-1:1998) GB/T14805.2—1999
9 Application-level grammar rules for electronic data interchange for administration, commerce and transport (grammar version number: 4) Part 2: Grammar rules specific to batch electronic data interchange (idtISO9735-2:1998) 4 Message terms and definitions
The definitions adopted in this standard are shown in Appendix A of GB/T14805.1. In addition, this standard also gives the following terms that are only applicable to CONTRL messages. (When a word or phrase in this chapter appears in bold, it means that the word or phrase has been defined in this chapter or Appendix A of GB/T14805.1).
Approved by the State Administration of Quality and Technical Supervision on October 17, 2000, and implemented on August 1, 2001
Acknowledgement
refers to the receiver of the primary exchange:
GB/T14805.4—2000
Has received the reference layer of the acknowledged primary exchange, has found that there are no fatal syntax errors in the acknowledged reference layer that would prevent further processing, has found that all acknowledged service segments (or parts thereof) (in the absence of reported errors) are semantically correct, and is about to take the action requested in the acknowledged service segment (or its reference layer), and has the responsibility to notify the sender by other means other than sending a CONTRL message in the following circumstances: the above-mentioned syntax or semantic errors are subsequently detected in the relevant parts, or a part cannot be processed for other reasons after it has been acknowledged in the submitted CONTRL message,
Has taken reasonable precautions to ensure that such errors can be detected and notified to the sender. Indication of interchange receipt refers to the receiver of the primary exchange:
- the primary exchange has been received,
certain parts of the primary exchange have been checked to ensure that the data elements copied into the UCI segment are syntactically correct. It is responsible for notifying the sender of the confirmation or rejection of other parts of the primary exchange, and has taken reasonable precautions to ensure that the sender can receive the notification. Rejection
refers to the receiver of the primary exchange:
the primary exchange or its relevant part cannot be confirmed for the reason specified in the CONTRL message. No further action is taken on the service information contained in the rejected part of the primary exchange. Report (To) report
indicates the action taken on the primary exchange or some part of it (confirmation or rejection) Reporting-level
refers to the segment in the CONTRL message used to report the corresponding reference level. The reporting level is the UCI, UCF, UCM, UCS and UCD segments. Referenced-level
The structure of the CONTRL message is based on the five segments UCI, UCFUCM, UCS and UCD, each of which corresponds to a part of the main exchange. These parts of the main exchange are: UNA, UNB and UNZ segments and the security segment used to protect the main exchange, corresponding to the UCI segment. -UNG and UNE segments and the security segment used to protect the group correspond to the UCF segment. The complete message or packet and the security segment used to protect the message or packet correspond to the UCM segment. The segment in the message body corresponds to the UCS segment.
Independent data elements, composite data elements or component data elements correspond to the UCD segment. These parts of the main exchange are called referenced layers. Main exchange
Subjectinterchange
Refers to the exchange responded by the CONTRL message.
GB/T14805.4—2000
5 Rules for the Use of Batch Electronic Data Interchange Syntax and Service Report Messages 5.1 Functional Definition
-H KAONi KAca-
The CONTRL message is a message that syntactically confirms or rejects a received interchange, group, message or package with an error indication.
The CONTRL message is used to:
a) confirm or reject a received interchange, group, message or package and list any syntax errors or unsupported functions contained therein, or b) simply indicate that an interchange has been received.
5.2 Areas of Application
The CONTRL message is used to comply with the fourth edition of the EDIFACT Syntax Rules (GB/T14805) and is used to respond to interchanges established in accordance with Parts 1, 2, 5, 6, 7, 8 and/or 9 of that edition. 5.3 Principles
The supported CONTRL message types and functions shall be agreed between the parties and support for CONTRL messages shall be indicated by a confirmation request in the UNB segment or in the exchange protocol. The sender (A) of an EDIFACT exchange may request in the UNB segment from the receiver (B) a response that the exchange has been received and is syntactically correct, that the semantics of the service segment are correct, and that the receiver supports the functions requested in the service segment. Alternatively, the request may be specified in the exchange protocol agreed upon between the exchange partners. The exchange from A to B is called the primary exchange.
The response is sent from the receiver (B) of the primary exchange to the sender (A) of the primary exchange in the form of one or two CONTRL messages. The CONTRL message has the following functions:
--indicates the action taken by the receiver based on the result of the syntax check of the primary exchange, or simply gives an indication of the exchange's receipt.
In the first case, the action (confirmation or rejection) indicates the result of the syntax check of the entire exchange received. Actions can be directed to the entire exchange or to a portion of it, so some messages, packets or groups can be confirmed and others can be rejected. The CONTRL message should indicate the action taken on each part of the main exchange. In the second case, only an indication of exchange reception is provided. When performing a syntax check on an exchange or a portion of an exchange, the following rules should be followed: - EDIFACT syntax rules (GB/T14805) (including service segment usage rules); - Syntax rules for the type of message received. The CONTRL message is not suitable for reporting application layer errors or actions taken against them, that is, the report does not involve semantic information in the user segment. Therefore, the confirmation indicated by the CONTRL message does not mean that the business content of the message or packet has been accepted or approved. Even if the exchange or a portion of it contains syntax errors, the receiver can choose to confirm it and report these errors. Whether these errors are non-fatal errors should be determined by the receiver. For example, the receiver can confirm data elements that exceed the specified maximum length as appropriate. An exchange containing a CONTRL message generated by the receiver of a primary exchange shall contain the same sender and receiver identification as the primary exchange in its UNB segment, except that the sender of the primary exchange becomes the receiver of this exchange, and the receiver of the primary exchange becomes the sender of this exchange. The parties may agree that a CONTRL message may be sent to reject an erroneous primary exchange or part of it even if no confirmation is requested in the UNB segment of the primary exchange.
In addition, CONTRL messages cannot be sent in groups. 5.3.1 Relationship between CONTRL messages and primary exchanges Up to two CONTRL messages may be sent to respond to a received exchange. The first message is optional and gives an indication of exchange reception. The second message reports the action taken after a syntax check of the primary exchange. The action code in the UCI segment shall indicate whether the message is of type one or type two.
GB/T14805.4—2000
If a confirmation request is made in the UNB segment of the primary exchange, a second type CONTRL message should be sent to report the results of the syntax check on the primary exchange (unless the primary exchange only contains CONTRL messages). The first type message is optional, which means that if a CONTRL message is to be sent eventually, a second type CONTRL message should usually be sent (unless the primary exchange only contains CONTRL messages). The UCI segment of the first type CONTRL message is not used to report errors, that is, when errors need to be reported via the UCI segment, only a second type CONTRL message should be sent.
The CONTRL message only reports actions taken on one primary exchange, that is, it does not involve multiple primary exchanges or some parts of them. Segment Group 1 and Segment Group 3 should not be used in CONTRL messages providing exchange reception indication. If the primary exchange contains groups (composed of messages and/or packets), only segment group 3 of the CONTRL message is used. If the primary exchange does not contain groups, only segment group 1 of the CONTRL message is used.
When a UCM segment group (segment group 1 or segment group 4) is required to be sent, at most one UCM segment group shall be sent for each received message or packet.
The order of all reported layers shall be the same as the order of their corresponding reference layers in the main exchange. 5.3.2 Use of action codes
Reference layers corresponding to UCI, UCF and UCM segments in the main exchange may be acknowledged or rejected. The CONTRL message also provides a means to acknowledge or reject the entire exchange or group without citing the messages, packets or groups within it. The action (acknowledge or reject) shall be indicated by the action code in the UCI, UCF and UCM segments. The code may indicate the action taken on the corresponding reference layer or, in some cases, on a lower reference layer. If the CONTRL message contains a segment corresponding to a reference layer in the main exchange, then that reference layer is said to be explicitly reported. If a lower reference layer is to be explicitly reported, all reference layers above that reference layer shall be acknowledged. A reference layer is said to be implicitly reported if the action taken on it is reported by the UCI or UCF segment corresponding to a higher reference layer in the main exchange. For example, if the action code in the UCI segment indicates rejection of the entire main exchange, the group and all messages or packets therein are implicitly rejected. In addition, when the action code in the UCI or UCF segment indicates the acknowledgement of messages or packets at the next lower layer and no UCM segment is present to reject them, these messages or packets are implicitly acknowledged. In the CONTRL message, action codes 4 or 7 are used only to report the action taken after a full check of the main exchange. Action code 8 is used only to indicate receipt of the exchange. These codes are defined in data element 0083 (action, code type). 5.3.3 Syntax Error Reporting
The reporting layer of the CONTRL message reports errors through the data elements in it. These data elements identify the location of the error in the main exchange and indicate the nature of the error.
Only one error may be reported per reporting layer (i.e., UCI, UCFUCM, UCS, and UCD segments). If more than one error is detected at the reference layer corresponding to a reporting layer, the receiver of the primary exchange is free to choose which error to report. Multiple CONTRL messages may not be sent to report multiple errors, and each reporting layer corresponding to a reference layer may appear at most once. Errors may be reported even if the reference layer containing the error is acknowledged. The user should also be aware that some syntax errors may change the semantics of the data, and the receiver of the primary exchange is responsible for the consequences of acknowledging semantically incorrect data. It is recommended to identify errors as precisely as possible. If precise error codes are defined, generic (and imprecise) error codes should no longer be used. Likewise, the location of the error should be identified as precisely as possible using the lowest reporting layer possible. Error codes from lower reporting layers may not be "copied" to higher reporting layers. Otherwise, it may happen that a data element error is reported with an error code in the UCD segment, and the same error code is repeated in the UCM segment. In this case, the error code identifying the error may only appear in the UCD segment. This rule applies to all reporting layers. The receiver of a CONTRL message will normally need to access the primary exchange in its transmission format to identify the precise location and nature of the error.
5.3.4 Errors in data elements copied from the primary exchange to the CONTRL message The CONTRL message contains a number of mandatory data elements which are copied from the primary exchange. If a data element in the primary exchange is missing or syntactically invalid, a syntactically valid CONTRL message cannot be generated and such errors should not be reported in a CONTRL message but by other means unless all parties processing the CONTRL message have agreed in the exchange protocol that the copying of erroneous data elements into the CONTRL message is permitted. 5.3.5 Redundant reporting of actions
If action code 7 is used in the UCI segment, it is also permitted to send a UCM or UCF segment to confirm the message, packet or group. Similarly, when action code 7 is used in the UCF segment, redundant UCM segments may be used to acknowledge messages or packets within a group. 5.3.6 Retransmission
The conditions under which an exchange, group, message, or packet needs to be retransmitted shall be agreed upon in advance by the parties to the exchange and are outside the scope of the CONTRL message.
5.3.7 Confirmation or Rejection of CONTRL Messages
A second type of CONTRL message (confirmation or rejection) shall not be sent in response to an exchange containing only CONTRL messages. Errors in CONTRL messages shall be reported by other means. If the exchange being responded to contains one or more CONTRL messages, the CONTRL message used in response shall be generated as if the exchange had been received without a CONTRL message. If an exchange contains both a CONTRL message and messages of other types, implicit confirmation or rejection of parts of the exchange shall not apply to the CONTRL message.
5.4 Message Definitions
5.4.1 Data Segment Description
This section should be read with reference to the table of segments marked with mandatory, conditional, and repetition counts. Information about the data elements in the following segments is given in 1.5 of Annex C of GB/T 14805.1. 0010 UNH Message Header
Begins and uniquely identifies the service segment of the message. The message type code for the syntax and service report message for batch electronic data interchange is CONTRL.
Note: Syntax and service report messages conforming to this standard must contain the following data in S009 of the UNH segment: Data Element 0065 CONTRL
0051 UN
0020 UCI Exchange Reply
Identifies the exchange being replied to, indicates receipt of the exchange and the confirmation or rejection of the UNA, UNB, and UNZ segments, and identifies errors associated with those segments. When the USA, USC, USD, USH, USR, UST, or USU segments are present at the switch level, this segment may identify errors associated with those segments. In addition, this segment may indicate the action taken on the group, message, or packet by an action code. The primary switch shall be identified by copying its switch sender, switch receiver, and switch control reference into the same data element in this segment. This segment may also identify the UNA, UNB, UNZ, USA, USC, USD, USH, USR, UST, or USU segments that are in error or missing. If no segments are identified, the error is associated with the entire switch. 0030 Segment Group 1: UCM-SG2
Reply to the message or packet in the primary switch identified by the UCI segment. This segment group may be used only when the primary switch does not contain a group. 0040
UCM Message/Packet Reply
Identifies a message or packet in the primary switch, indicates the acknowledgement or rejection of the message or packet, and identifies errors associated with the UNH, UNT, UNO, and UNP segments. When the security segments USA, USC, USD, USH, USR, UST or USU appear at the message or packet level, this segment may also identify errors associated with these segments. The message shall be identified by copying its message identifier and message reference number into the same data element in this segment. This segment may also identify the erroneous or missing UNH, UNT, USA, USC, USD, USH, USR, UST or USU segments. If no segment is identified, the error is associated with the entire message. 5
GB/T14805.4—2000
The identification of a packet shall be accomplished by copying its reference identifier and packet reference number into the same data element in this segment. This segment may also identify the UNO, UNP, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If no segment is identified, the error is related to the entire packet. Segment Group 2: UCS-UCD
Answer the segment in error in the message identified by the UCM segment in Segment Group 1. UCS, Segment Error Indication
Identifies a segment in the message, indicates that the segment is in error, and identifies the error related to the entire segment. UCD, Data Element Error Indication
Identifies an individual data element, a composite data element, or a component data element in error in the segment identified by the UCS segment in Segment Group 2, and indicates the nature of the error.
0080 Segment Group 3: UCF-SG4
Answer the group in the primary exchange identified by the UCI segment. This segment group shall be used only when the primary exchange contains a group. 0090
UCF Group Acknowledge
Identifies the group in the primary exchange, indicates the acknowledgement or rejection of the UNG and UNE segments, and identifies errors associated with those segments. This segment may also identify errors associated with the security segments USA, USC, USD, USH, USR, UST, or USU when they are present at the group level. In addition, this segment may indicate the action taken on the message or packet in the group by an action code. The group shall be identified by copying its application sender identification, application receiver identification, and group reference number into the same data element in this segment. This segment may also identify the UNG, UNE, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If no segment is identified, the error is associated with the entire group. Segment Group 4: UCM-SG5
Acknowledges the message or packet in the group identified by Segment Group 3. UCM Message/Packet Acknowledgement
Identifies a message or packet in a primary exchange, indicates the acknowledgement or rejection of the message or packet, and identifies errors associated with the UNH, UNT, UNO, and UNP segments. This segment may also identify errors associated with the security segments USA, USC, USD, USH, USR, UST, or USU when they are present at the message or packet level. The message shall be identified by copying its message identifier and message reference number to the same data element in this segment. This segment may identify the UNH, UNT, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If no segment is identified, the error is associated with the entire message. The packet shall be identified by copying its reference identifier and packet reference number to the same data element in this segment. This segment may also identify the UNO, UNP, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If no segment is identified, the error is associated with the entire packet. Segment Group 5: UCS-UCD
Replies to the erroneous segment in the message identified by the UCM segment in Segment Group 4. UCS Segment Error Indication
Identifies the segment in the message, indicates that the segment is erroneous, and identifies the error associated with the entire segment. UCD Data Element Error Indication
Identifies the erroneous independent data element, composite data element, or component data element in the segment identified by the UCS segment in Segment Group 5, and indicates the nature of the error.
0150 Message End
Ends the message, gives the total number of segments in the message, and the control reference number of the message. 5.4.2 Data Segment Index (Arranged in alphabetical order by segment tag) UCD Data Element Error Indication
Group Acknowledge
Exchange Response
Message/Packet Acknowledge
Segment Error Indication
Message Header
Message Tail
5.4.3 Message Structure
5.4.3.1 Segment Table
Note:
UNH Message Header
Exchange Acknowledge
Segment Group 1
Message/Packet Acknowledge
Segment Group 2
Segment Error Indication
Data Element Error Indication
Segment group 3
Group response
Segment group 4
UCM message/packet response
-Segment group 5
Segment error indication
Data element error indication
Message tail
GB/T14805.4—2000
Number of repetitions
999999
999999
999999
1) D4 (0030, 0080) has one or none, that is, at most one segment group appears in segment groups 0030 and 0080. -KAoiKAca-
GB/T14805.4—2000
Appendix A
(Appendix to the standard)
Error code table
Table A1 describes the error codes and the reporting layers to which they apply. Table A1
Code Name
Unsupported Syntax Version or Syntax Level
Exchange Receiver is not the actual specified receiver 7
Invalid Value
Value not supported at this position
Not supported at this position
Too many components
No protocol
Undefined error
Character cannot be used as a service character
Invalid character
Invalid service character
Unknown Exchange Sender
Unsupported Test Indicator
Duplicate Check
Reference Mismatch
Control Count or Octet Count does not match the number actually received 29
Mixed use of group and message/packet
Low-layer space
Invalid occurrence outside message, packet or group 33
Too many repetitions
Too many repetitions of segment group
Invalid character type
KAONiKAca-
GB/T14805.4—2000
Table A1 (end)
Code name
Data element too long
Data element too short
The tail is a separator
Unsupported character set
Unsupported encapsulation function
=Unavailable
×=Available
Description:UCM-SG5
Acknowledges the message or packet in the group identified by Segment Group 3. UCM Message/Packet Acknowledge
Identifies the message or packet in the primary exchange, indicates the acknowledgement or rejection of the message or packet, and identifies errors associated with the UNH, UNT, UNO, and UNP segments. This segment may also identify errors associated with the security segments USA, USC, USD, USH, USR, UST, or USU when these segments are present at the message or packet level. The message shall be identified by copying its message identifier and message reference number to the same data element in this segment. This segment may identify the UNH, UNT, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If the segment is not identified, the error is associated with the entire message. The packet shall be identified by copying its reference identifier and packet reference number to the same data element in this segment. This segment may also identify an erroneous or missing UNO, UNP, USA, USC, USD, USH, USR, UST, or USU segment. If no segment is identified, the error is related to the entire packet. Segment Group 5: UCS-UCD
Responds to the erroneous segment in the message identified by the UCM segment in Segment Group 4. UCS Segment Error Indication
Identifies a segment in the message, indicates that the segment is erroneous, and identifies the error related to the entire segment. UCD Data Element Error Indication
Identifies an erroneous independent data element, composite data element, or component data element in the segment identified by the UCS segment in Segment Group 5, and indicates the nature of the error.
0150 End of Message
Ends the message, gives the total number of segments in the message, and the control reference number of the message. 5.4.2 Data Segment Index (Arranged in alphabetical order by segment tag) UCD Data Element Error Indication
Group Acknowledge
Exchange Response
Message/Packet Acknowledge
Segment Error Indication
Message Header
Message Tail
5.4.3 Message Structure
5.4.3.1 Segment Table
Note:
UNH Message Header
Exchange Acknowledge
Segment Group 1
Message/Packet Acknowledge
Segment Group 2
Segment Error Indication
Data Element Error Indication
Segment group 3
Group response
Segment group 4
UCM message/packet response
-Segment group 5
Segment error indication
Data element error indication
Message tail
GB/T14805.4—2000
Number of repetitions
999999
999999
999999
1) D4 (0030, 0080) has one or none, that is, at most one segment group appears in segment groups 0030 and 0080. -KAoiKAca-
GB/T14805.4—2000
Appendix A
(Appendix to the standard)
Error code table
Table A1 describes the error codes and the reporting layers to which they apply. Table A1
Code Name
Unsupported Syntax Version or Syntax Level
Exchange Receiver is not the actual specified receiver 7
Invalid Value
Value not supported at this position
Not supported at this position
Too many components
No protocol
Undefined error
Character cannot be used as a service character
Invalid character
Invalid service character
Unknown Exchange Sender
Unsupported Test Indicator
Duplicate Check
Reference Mismatch
Control Count or Octet Count does not match the number actually received 29
Mixed use of group and message/packet
Low-layer space
Invalid occurrence outside message, packet or group 33
Too many repetitions
Too many repetitions of segment group
Invalid character type
KAONiKAca-
GB/T14805.4—2000
Table A1 (end)
Code name
Data element too long
Data element too short
The tail is a separator
Unsupported character set
Unsupported encapsulation function
=Unavailable
×=Available
Description:UCM-SG5
Acknowledges the message or packet in the group identified by Segment Group 3. UCM Message/Packet Acknowledge
Identifies the message or packet in the primary exchange, indicates the acknowledgement or rejection of the message or packet, and identifies errors associated with the UNH, UNT, UNO, and UNP segments. This segment may also identify errors associated with the security segments USA, USC, USD, USH, USR, UST, or USU when these segments are present at the message or packet level. The message shall be identified by copying its message identifier and message reference number to the same data element in this segment. This segment may identify the UNH, UNT, USA, USC, USD, USH, USR, UST, or USU segment that is in error or missing. If the segment is not identified, the error is associated with the entire message. The packet shall be identified by copying its reference identifier and packet reference number to the same data element in this segment. This segment may also identify an erroneous or missing UNO, UNP, USA, USC, USD, USH, USR, UST, or USU segment. If no segment is identified, the error is related to the entire packet. Segment Group 5: UCS-UCD
Responds to the erroneous segment in the message identified by the UCM segment in Segment Group 4. UCS Segment Error Indication
Identifies a segment in the message, indicates that the segment is erroneous, and identifies the error related to the entire segment. UCD Data Element Error Indication
Identifies an erroneous independent data element, composite data element, or component data element in the segment identified by the UCS segment in Segment Group 5, and indicates the nature of the error.
0150 End of Message
Ends the message, gives the total number of segments in the message, and the control reference number of the message. 5.4.2 Data Segment Index (Arranged in alphabetical order by segment tag) UCD Data Element Error Indication
Group Acknowledge
Exchange Response
Message/Packet Acknowledge
Segment Error Indication
Message Header
Message Tail
5.4.3 Message Structure
5.4.3.1 Segment Table
Note:
UNH Message Header
Exchange Acknowledge
Segment Group 1
Message/Packet Acknowledge
Segment Group 2
Segment Error Indication
Data Element Error Indication
Segment group 3
Group response
Segment group 4
UCM message/packet response
-Segment group 5
Segment error indication
Data element error indication
Message tail
GB/T14805.4—2000
Number of repetitions
999999
999999
999999
1) D4 (0030, 0080) has one or none, that is, at most one segment group appears in segment groups 0030 and 0080. -KAoiKAca-
GB/T14805.4—2000
Appendix A
(Appendix to the standard)
Error code table
Table A1 describes the error codes and the reporting layers to which they apply. Table A1
Code Name
Unsupported Syntax Version or Syntax Level
Exchange Receiver is not the actual specified receiver 7
Invalid Value
Value not supported at this position
Not supported at this position
Too many components
No protocol
Undefined error
Character cannot be used as a service character
Invalid character
Invalid service character
Unknown Exchange Sender
Unsupported Test Indicator
Duplicate Check
Reference Mismatch
Control Count or Octet Count does not match the number actually received 29
Mixed use of group and message/packet
Low-layer space
Invalid occurrence outside message, packet or group 33
Too many repetitions
Too many repetitions of segment group
Invalid character type
KAONiKAca-
GB/T14805.4—2000
Table A1 (end)
Code name
Data element too long
Data element too short
The tail is a separator
Unsupported character set
Unsupported encapsulation function
=Unavailable
×=Available
Description:
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.