This standard specifies a common interface for bank card-generated messages related to financial transactions to be exchanged between dedicated systems. It specifies the message structure, format and content, data and data values. GB/T 15150-1994 Bank card exchange message specification for generating messages Financial transaction content GB/T15150-1994 Standard download decompression password: www.bzxz.net

National Standard of the People's Republic of China
Bank card originated messages
Exchange message specifications
Content for financial transactions
Bank card originated messagesInterchange message specifications-Content for financial transactions GB/T 15150-94
IS0 858319B7
This standard is equivalent to the international standard IS0 8583-1987≤Bank originated messages-Exchange message specifications-Content for financial transactions. 0 Introduction
The business of the financial industry includes the exchange of electronic information related to financial transactions. The agreement of application specifications is usually limited to the dedicated level. This standard promotes the design of an interface specification that ensures that messages can be exchanged between systems using different application specifications. Each application specification can remain at the dedicated level. Under the general constraint that messages can be converted into an interface format that can be exchanged internationally, the designers of each application can enjoy complete flexibility.
This standard uses a concept called "bit table", in which each data element is assigned a position mark in the control field or bit table. In a specific message, the existence of a data element is marked with "1" at the specified position, and the absence of the data element is marked with "0". The message format adopted by each system depends on the business relationship between the contracting parties of each system. The data format specified in this standard can ensure that the systems that comply with this standard are always compatible. Subject content and scope of application
This standard specifies a common interface for messages related to financial transactions generated by a bank card to be exchanged between dedicated systems. It specifies the message structure, format and content, data elements and data element values. The data elements and terminology used in this standard are from the international standard IS07580. Only the data elements listed in Table 1 are compatible with ISO7580.
Table 1 Number of data elements that are incompatible between this standard and ISO7580
Attached data—15
Additional response data
Netting amount
Clearing amount
Transaction amount
Credit amount
Cancellation of credit amount
Debit amount
Dissipation of debit amount
State Administration of Technical Supervision 1 994-07-30 approved 1SO7580
ans· .132
ans - - 14
? ·12
ans 999
Ans - - 25
Implementation on 1995-01-01
GB/T 15150—94
In addition, the transmission date and transmission time are combined into the transmission date and time: the requester identification code is defined as the sending institution identification code, and the issuer identification code is taken from the primary account number or the extended primary account number; the message key is identified by the file confidentiality code. 2 Reference standards
GB2659Code for names of countries and regions in the worldGB12406
Code for indicating currency and funds
ISO4909
ISO7580
ISO7810
ISO 7811
Bank card
Identification card
Identification card
Identification card
Data content of the third track of the magnetic stripe
Cards that generate messages - financial transaction content
Physical characteristics
Recording technology
Part 1: Embossing
Part 2: Magnetic stripe
Part 3: Location of embossed characters on ID-1 cardsPart 4: Location of read-only tracks
Part 5: Location of read-write tracks
ISO 7812 Identification Cards
ISO7813 Identification Cards
3 Definitions
First and Second Tracks
Third Track
Issuer Identifier Numbering System and Registration Procedures Financial Transaction Cards
The following definitions apply to this standard.
3.1 Acquirer
A financial institution (or its agent) that obtains transaction data from the acceptor and introduces the data into the exchange system. 3.2 Notification
A message that notifies the relevant party of an action that has taken place, without requiring approval. 3.3 Authorization
An approval or guarantee from the issuer to the agent (and/or the acceptor). 3.4 Card Acceptor
An institution that receives the card and transmits the transaction data to the agent. 3.5 Cardholder
A customer who wishes to conduct transactions with the acceptor and is associated with a primary account number. 3.6 Cardholder Account Transfer Cardholder accounts transfer Fund transfer between two accounts of the cardholder in the same "financial institution. 3.7 Card issuer
Institution (or its agent) that issues identification cards to cardholders. 3.8 Credit transaction credit1ransaction The cardholder's request to credit the funds in his account. At the same time, it provides the agent (and/or the cardee) with the details of the funds to be paid to the card issuer.
3.9 Debit transaction debit transaction The cardholder's approval of the debit of his account. At the same time, it provides the agent (and/or the cardee) with the right to request funds from the card issuer. 3.10 Interactive message The message sent when a transaction occurs and requires a response. 3.11 Intermediate network facility specifies various message processing entities between the agent and the card issuer. 3.12 Message mesage
GB/T 15150-94
A collection of data elements used to exchange information between institutions (or their agents). Does not set or identify any communication (header or footer, protocol character code) or confidentiality related content.
3. 13 Non-interactive message A message sent after a transaction occurs, and does not require a response. The message can be transmitted using online communication or offline message transmission (for example, magnetic tape).
3.14 Point of service (POS) The location where the transaction occurs.
3.15 Praressing fee
The fee related to processing or transmitting the message does not involve the charge for the use of cardholder services or equipment (for example, ATM). 3.16 Request
A message that generates a series of interactive messages.
3-17 Reversal
A message that notifies the original message sender that the transaction cannot be processed as instructed, that is, a message that cannot be sent, cannot be processed, or is canceled by the recipient. 3.18 Reversal creditReversal of a credit caused by a previous debit. 3.19 Reversal debitReversal of a debit caused by a previous credit. 3.20 Reversal transferReversal of a debit or credit caused by a previous transfer. 3.21 Routing
The direction of the message flow between the agent and the issuer, either directly or through an intermediary network facility, which can act as an agent for the sender. Routing should be in the message flow.
3.22 Settlement
The transfer of funds for one or more transactions completed previously for the final accounting. 3.23 Settlement institutionA financial institution (or its agent) that assumes the responsibility of paying the agent, the issuer or the intermediary network facility for the recognized financial transaction. 3.24 Transaction transaction
A collection of related messages used to accomplish (if possible) the intent of the originator of the original message, usually ending with a debit or credit transaction. Subsequent amendments or revocations may be considered a separate set of transactions. 3-25 Transaction fee transaction fee
A fee charged for a transaction (e.g., a fee charged by an agent). 4 Message structure
Each message identified in this standard is organized in the following order: a message type identifier (see 4.1), one or two bit tables (see 4.2), and a sequence of data elements in the order described in the bit tables (see 4.3). Chapter 5 gives each message and its relationship to other messages.
4.1 Message Type Identifier
The message type identifier is a 4-bit numeric field that describes the category and function of each message. All messages should start with a message type identifier.
4.1.1 Structure of message type identifier
The first and second digits identify the message category: 00××
01××
03××
05××
06××
07××
09× X-79X ×
80× X×-89× X
90XX-99XX
GB/T 15150—94
Reserved for ISO use
Authorization message
Financial transaction message
File update message
Removal message
Account reconciliation control message
Management message
Reserved for ISO Use
Network Management Messages
Reserved for ISO Use
Reserved for National Use
Reserved for Civil Use
When the 1st and 2nd digits are between 01 and 08, the 3rd and 4th digits indicate the message function and transmission mode. The values ​​of the 3rd and 4th digits are assigned as follows:
4.1.2 Message Duplication
Interactive Processing Transactions
Non-interactive Processing Transactions
Reserved for ISO Use
Reserved for National Use
Reserved for Civil Use
When a message is identified as a duplicate message in 4.1.3, the duplicate message is identical to its original message except for the message type identifier. 4.1.3 Message Type Identifier Description
4.1.3.1 Authorization Message
Authorization Request
Authorization Request Repeat
Outgoing: Sent by the agent to the card issuer
Type: Interactive
Purpose: Requesting approval, authorization or guarantee for processing a transaction. Cannot be used for applications that allow transactions such as bills or statements to be issued from the cardholder's account.
Requires a 0110 Authorization Request Response to be sent back.
Authorization Complete Confirmation
Authorization Complete Confirmation Repeat
Routing: Sent by the agent to the card issuer
Type: Interleaved
Purpose: Can be sent after receiving a 0110 Authorization Request Response, indicating that the authorization behavior specified in 0110 has been completed. In response to 0102 Authorization Complete Confirmation, a 0112 Authorization Complete Response can be sent back. In response to α103 Authorization Complete Confirmation Repeat, a 0112 Authorization Complete Response must be sent back.
Authorization Request Response
Routing: sent by the issuer to the agent
Type: interactive
GB/T 15150—94
Purpose: sent in response to 01(0 Authorization Request or 0101 Authorization Request Repeat, and carries the response to the request 0112
Authorization Completion Response
Routing: sent by the issuer to the agent
Type: interactive
Purpose, can be sent to indicate receipt of 0102 Authorization Completion Confirmation, must be sent to indicate receipt of 0103 Authorization Completion Confirmation Repeat. 0120
Authorization Notification
Authorization Notification Repeat
Routing: sent by the agent to the issuer||t t||Type: Non-interactive
Purpose: Notification for authorization on behalf of the card issuer. It cannot be used for transactions such as allowing billing or meter transfer from the cardholder's account. In response to 0120 Authorization Notification, 0130 Authorization Notification Response can be sent back. In response to 0121 Authorization Notification Repeat, 0130 Authorization Notification Response must be sent back.
Authorization Notification Complete Confirmation
Authorization Notification Complete Confirmation Repeat
Routing: Sent by the agent to the card issuer
Type; Non-interactive
Purpose: After receiving 0130 Authorization Notification Response Can be sent, indicating that the authorization action specified in 0130 has been completed successfully, partially successfully or unsuccessfully.
To repeat 0122 Authorization Notification Complete or Confirmation, 0132 Authorization Notification Complete Response can be sent back. To reply 0123 Authorization Notification Complete Confirmation Repeat, 0132 Authorization Notification Complete Response must be sent back. 0130
Authorization Notification Response
Route: From the issuer to the agent
Type: Non-interactive
Purpose: To indicate that the authorization notification 0120 has been received and can be sent, to reply 0121 Authorization Notification Complete Confirmation Repeat. 0132
Authorization Notification Completion Response
Route: Sent by the card issuer to the agent
Type: Non-interactive
Purpose: To indicate that the 0122 Authorization Notification Completion Confirmation has been received and can be sent, and to indicate that the 0123 Authorization Notification Completion Confirmation has been received and must be sent repeatedly.
4.1.3.2 Financial Transaction Message
Financial Transaction Request
Financial Transaction Request Repeat
Route: Sent by the agent to the card issuer
Type: Interactive
CB/T 15150—94
Purpose Requests approval of a transaction, which, if approved, is used immediately to issue a bill or statement to the cardholder's account. Requires a 0210 Financial Transaction Request Response to be sent back. 0202
Financial Transaction Completion Confirmation
Financial Transaction Completion Confirmation Repeat
Routing: From Agent to Issuer
Type: Interactive
Purpose: MAY be sent after receiving a 0210 Financial Transaction Request Response, indicating that the transaction was completed successfully, partially successfully, or unsuccessfully. In reply to 0202 Financial Transaction Completion Confirmation, 0212 Financial Transaction Completion Response can be sent at the same time. In order to repeat (203 Financial Transaction Completion Confirmation, 0212 Financial Transaction Completion Response must be sent back. 0210
Financial Transaction Request Response
Route: Sent by the issuer to the agent
Type: Interleaved
Purpose: Must be sent in response to 0200 Financial Transaction Request or 0201 Financial Transaction Request Repetition, and carry the response to the request. The approval response will be sent between the agent and the issuer. Causes an update of clearing or reconciliation control between them. 0212
Financial transaction completion response
Routing: From the originating card party to the agent party
Type; interactive
Purpose: It can be sent to indicate receipt of 0202 financial transaction completion confirmation, and must be sent to indicate receipt of 0203 financial transaction completion confirmation repeat.
Financial transaction notification
Financial transaction notification repeat
Routing: From the agent party to the card issuer
Type: non-interactive|| tt||Purpose: Notification of previously completed financial transaction messages, used to issue bills or statements from the cardholder's account. To reply to 0220 financial transaction notification, send back 0230 financial transaction notification response. To reply to 0221 financial transaction notification, send 0230 financial transaction notification response again. 0222
Financial transaction notification completion confirmation
Financial transaction notification completion confirmation repeat
Route: sent by the agent to the card issuer
Type non-transactional
Purpose: received 0230 Financial Transaction Request Response can be sent after the response, indicating that the transaction is completed in a completely successful, partially successful or unsuccessful manner. In response to 0222 Financial Transaction Notification Completion Approval, 0232 Financial Transaction Notification Completion Response must be sent back. In response to 0223 Financial Transaction Notification Completion Confirmation Repeat, 0232 Financial Transaction Notification Completion Response must be sent back. 0230
Financial Transaction Notification Response
Route: From the issuer to the agent
Type Non-interchange
..comGB/T 15150—94
Purpose: To indicate that the 0220 financial transaction notification has been received and can be sent, to indicate that the 0221 financial transaction notification has been received and must be sent repeatedly. 0232
Financial transaction notification completion response
Route: Sent by the issuer to the agent
Type; Non-interactive
Purpose: To indicate that the 0222 financial transaction notification has been received and can be sent, to indicate that the 0223 financial transaction notification has been received and must be sent repeatedly.
4.1. 3. 3 File Update Message
Agent File Update Request
Route: Sent by the agent to the issuer
Type:Interactive
Purpose: Including instructions to add, modify, delete or replace a file or record. Requires a return response to the 0310 agent file update request. 0302
Issuer file update request
Route: Sent from the issuer to the agent
Type; Interactive
Purpose: Including instructions to add, modify, delete or replace a file or record. Requires a return response to the 0312 issuer file update request. 0310
Agent file update request response
Route: Sent from the issuer to the agent
Type: Interactive
Purpose: Must be sent in response to the 0300 agent file update request to indicate the result of the message. 0312
Card Issuer File Update Request ResponseWww.bzxZ.net
Route: Sent by the agent to the card issuer
Type: Interactive
Purpose: Must be sent in response to 0302 Card Issuer File Update Request to indicate the result of the message. 0320
Agent Document Update Notification
Route: Sent by the agent to the card issuer
Type: Invariant
Purpose: Including instructions to add, modify, delete or replace a file or record. 0330 Agent File Update Notification Response can be sent back. 0322
Card Issuer File Update Notice
Route: sent by the card issuer to the agent
Type: non-interactive
Purpose: it includes instructions to add, modify, delete or replace a file or record, and can return 0332 Card Issuer File Update Notice Response.0330
Agent File Update Notice Response
Route: sent by the card issuer to the agent
Type non-interactive
GB/T 15150—94
Purpose: can be sent in response to 0320 Agent File Update Notice to indicate the result of the message. 0332
Card Issuer File Update Notice Response
Route: sent by the agent to the card issuer
Type non-interactive
Purpose: can be sent in response to 0322 Card Issuer File Update Notice to indicate the result of the message. 4.1.3.4 Cancel Message
Agent Cancel Request
Agent Cancel Request Repeat
Route: Sent by agent to card issuer or intermediate network facility Type: Interactive
Purpose: Cancel (partially or completely) the original authorization or transaction. Must return 0410 Agent Cancel Request Response. 0402
Issuer Cancel Request
Issuer Cancel Request Repeat
Route: Sent by card issuer to agent
Type: Interactive
Purpose: Cancel (partially or completely) the original authorization or transaction. Must return 0412 Issuer Cancel Request Response. 0410
Agent Cancel Request Response
Route: Sent from the issuer to the agent
Type: Interactive
Purpose: In response to 0400 Agent Cancel Request or 0401 Agent Cancel Request, it must be sent repeatedly to indicate the processing status of the message. 0412
Issuer Cancel Request Response
Route: Sent from the agent to the issuer
Type: Interactive
Purpose: In response to 0402 Issuer Cancel Request or 0403 Issuer Cancel Request, it must be sent repeatedly to indicate the processing status of the message. 0420
Agent Cancel Notice
Agent Cancel Notice Duplicate
Route: Sent from agent to card issuer
Type: Non-interactive
Purpose: Cancel (partially or completely) the original authorization or transaction. To reply to 0420 Agent Cancel Notice, you can send 0430 Agent Cancel Notice Response. To reply to 0421 Agent Cancel Notice Duplicate, you must send 0430 Agent Cancel Notice Response. 0422
Issuer Cancel Notice
Issuer Cancel Notice Duplicate
Route: Sent from card issuer to agent
Type: Non-interactive
CB/T15150-94
Purpose: Cancel (partially or completely) the original authorization or transaction. In response to 0422 Issuer Cancel Notice, 0432 Issuer Cancel Notice Response can be sent back. In response to 0423 Issuer Cancel Notice Repeat, 0432 Issuer Cancel Notice Response must be sent back. 0430
Agent Cancel Notice Response
Routing: sent by issuer to agent
Type: non-interactive
Purpose: can be sent in response to 0420 Agent Cancel Notice. must be sent in response to 0421 Agent Cancel Notice Repeat to indicate the processing status of the message.
Issuer Cancel Notice Response
Routing: sent by issuer to agent
Type. non-interactive
Purpose: can be sent in response to 0422 Issuer Cancel Notice. must be sent in response to 0423 Issuer Cancel Notice Repeat to indicate the processing status of the message.
4.1.3.5 Reconciliation Control Message
Agent Reconciliation Request
Agent Reconciliation Request Repeated
Route: Sent by agent to issuer
Type, interactive
Purpose: Request to confirm the agent total (number of transactions and amount) since the last 0500 agent reconciliation request, so as to achieve settlement between the two parties. 0510 agent reconciliation request response must be sent indirectly. 0502
Issuer Reconciliation Request
Issuer Reconciliation Request Repeated
Route: Sent by issuer to agent
Type: interactive
Purpose: Request to confirm the issuer total (number of transactions and amount) since the last D502 issuer reconciliation request, so as to achieve settlement between the two parties. 0512 issuer reconciliation request response must be sent back. 0510
Agent Reconciliation Request Response
Route: Sent from the issuer to the agent
Type: Interleaved
Purpose: Must be sent in response to 0500 Agent Reconciliation Request or 0501 Agent Reconciliation Request to indicate the processing status or response of the message.
Issuer Reconciliation Request Response
Route: Sent from the agent to the issuer
Type: Interleaved
Purpose: Must be sent in response to 0502 Issuer Reconciliation Request or 503 Issuer Reconciliation Request to indicate the processing status or response of the message.
Agent reconciliation notification
Agent reconciliation notification is repeated
Route: sent by the agent to the issuer
Type: non-interactive
GB/T 15150—94
Purpose: Notification of the total (number of transactions and amount) since the last 0520 agent reconciliation notification, in order to achieve settlement between the two parties. To reply to 0520 agent reconciliation notification, 0530 agent reconciliation notification response can be sent back. To reply to 0521 agent reconciliation notification duplicate, 0530 agent reconciliation notification response must be sent back. 0522
Issuer reconciliation notification
Issuer reconciliation notification duplicate
Output: Sent by the issuer to the agent
Type: Non-interactive
Purpose: Notification of the total (number of transactions and amount) since the last 0522 issuer reconciliation notification, in order to achieve settlement between the two parties. To repeat 0522 issuer reconciliation notification, 0532 issuer reconciliation notification can be sent indirectly. To reply to 0523 issuer reconciliation notification duplicate, 0532 issuer reconciliation notification must be sent back. Reconciliation notification response. 0530
Agent reconciliation notification response
Routing: From the card issuer to the agent
Type; Non-interactive
Purpose: In response to 0520 agent reconciliation notification, it can be sent; in response to 0521 agent reconciliation notification, it must be sent repeatedly to indicate the processing status or response of the message.
Card issuer reconciliation notification response
Routing: From the agent to the issuing party, type; Non-interactive
Purpose: In response to 0522 card issuer reconciliation notification, it can be sent; in response to 0523 card issuer reconciliation notification, it must be sent repeatedly to indicate the processing status or response of the message.
4. 1. 3.6 Management Message
Management Request
Management Request Reply
Routing: Sent between any two communicating parties (agent, card issuer or intermediate network facility) Type: Interactive
Purpose: Request confirmation of data in a format not specified by this standard. Request to send back 0610 Management Request Response
Management Request Response
Routing: Sent by the receiver of the relevant management request message to the sender. Type: Interactive
Purpose: Must be sent in response to 0600 Management Request or 0601 Management Request Reply to indicate the processing status of the message. 0620
Management Notification
Management Notification Reply
GB/T 15150—94
Routing: Sent between any two communicating parties (agent, card issuer or intermediate network facility) Type: Non-interactive
Purpose: Transmit data in a format not specified by this standard. In response to 0620 management notification, 0630 management notification response can be sent back, and in response to 0621 management notification repetition, 0630 management notification response must be sent back in advance.
Management pass response
Route: sent by the receiver of the relevant management notification message to the sender Type: non-interactive
Purpose: can be sent in response to 0620 management notification, and must be sent in response to 0621 management notification repetition to indicate the processing status of the message. 4.1.3.7 Network management message
Core 800
Network management request
Network management request repetition
Route: sent between any communicating parties (agent office, card issuer or intermediate network facility) Type interactive
Purpose: control the switching network by providing or describing the system status or system security. Requires to send back 0810 network management request response. 0810
Network Management Request Response
Routing: Sent by the receiver of the relevant network management message to the sender Type: Interactive
Purpose: Must be sent in response to 0800 Network Management Request or 0801 Network Management Request Repeat to indicate the processing status of the message. 0820
Network Management Notification
Network Management Notification Repeat
Routing: Sent between any two communicating parties (agent, issuer or inter-network facility) Type: Non-Secure
Purpose: Control the switching network by providing or describing the system status or system security. In response to 0820 Network Management Notification, 0830 Network Management Notification Response can be sent back, and in response to 0821 Network Management Notification Repeat, 0830 Network Management Notification Response must be sent back. 0830
Network Management Notification Response
Use: Sent by the receiver of the relevant network management notification information to the sender Type: Non-interchangeable
Purpose: Can be sent in response to 0820 network management notification, and must be sent in response to 0821 network management notification to indicate the processing status of the message.
4.2 Bit table
The second part of the message consists of one or two bit tables, which are composed of 64 bits, with the left starting position being "01\. Each bit uses "1\" or "0\" to indicate the presence or absence of the data element related to the specific bit in the message. The first bit in the bit table has a value of "1", indicating that there is an auxiliary bit table immediately following it, see Figure 1. Basic bit table
Bit table: -
Extended bit table
GB/T15150—94
(64) (65)
Data element
Data element
The basic bit table (1-64 bits) always exists. The most commonly used data elements are sorted according to these bit positions, and the less commonly used data elements are sorted according to the auxiliary bit table (65-128 bits). If the auxiliary bit table exists, the value of 01 in the basic bit table is taken as "1" to indicate (extended bit table). Table 2 gives: a. The data element assigned to each bit! b. The data element length and attribute specifications, listed in 4.3; c. The mandatory or conditional existence specifications of each message type identifier. \M\ indicates that the mandatory existence condition of this sub-item in the message is expressed in the form of "nn". For details, see Table 3. If the conditions given in Table 3 are met, this field The data element should not exist: otherwise, its presence in the message is determined by the agreement of both parties. The content in Table 2 allows the use of any data element in all messages. The message may include those additional mandatory and/or conditional data elements.
43 Data elements
The third part of the message and its data content consists of a series of data elements. Table 2 specifies the existence of these data elements according to the message type identifier.
The message is reorganized using the bit table as a close reference to the existing data elements. Some data elements have a fixed length, while others have a variable length. The actual length of any specified variable length data element is determined by its fixed length prefix. The message structure does not exclude the use of additional data elements in the message in the manner required for domestic exchange or civilian use. Table 4 The data elements listed in the table will be used in the message defined in Table 2. The first column is the name of the data element.
The first column is the description of the data element.
The third column includes the data element representation and the term index that can further describe the data element. The fourth column includes the bitmap indicator (P-basic, S-extended) and its position in the bitmap to identify the data element. The abbreviations used in the special column are as follows: a
=alphabetic character
=number
=special character2 Bit table
The second part of the message consists of one or two bit tables, which are composed of 64 bits, starting from the left position "01". Each bit is represented by "1" or "0" to indicate the presence or absence of the data element related to the specific bit in the message. The first bit in the bit table has a value of "1", indicating that there is an auxiliary bit table following it, see Figure 1. Basic bit table
Signal bit table:-
Extended bit table
GB/T15150—94
(64) (65)
Data element
Data element
The basic bit table (1-64 bits) always exists. The most commonly used data elements are sorted according to these bit positions, and the less commonly used data elements are sorted according to the auxiliary bit table (65-128 bits). If the auxiliary bit table exists, the value of 01 in the basic bit table is taken as "1" to indicate (extended bit table). Table 2 gives: a. The data element assigned to each bit! b. The data element length and attribute specifications, listed in 4.3; c. The mandatory or conditional existence specifications of each message type identifier. \M\ indicates that the mandatory existence condition of this sub-item in the message is expressed in the form of "nn". For details, see Table 3. If the conditions given in Table 3 are met, this field The data element should not exist: otherwise, its presence in the message is determined by the agreement of both parties. The content in Table 2 allows the use of any data element in all messages. The message may include those additional mandatory and/or conditional data elements.
43 Data elements
The third part of the message and its data content consists of a series of data elements. Table 2 specifies the existence of these data elements according to the message type identifier.
The message is reorganized using the bit table as a close reference to the existing data elements. Some data elements have a fixed length, while others have a variable length. The actual length of any specified variable length data element is determined by its fixed length prefix. The message structure does not exclude the use of additional data elements in the message in the manner required for domestic exchange or civilian use. Table 4 The data elements listed in the table will be used in the message defined in Table 2. The first column is the name of the data element.
The first column is the description of the data element.
The third column includes the data element representation and the term index that can further describe the data element. The fourth column includes the bitmap indicator (P-basic, S-extended) and its position in the bitmap to identify the data element. The abbreviations used in the special column are as follows: a
=alphabetic character
=number
=special character2 Bit table
The second part of the message consists of one or two bit tables, which are composed of 64 bits, starting from the left position "01". Each bit is represented by "1" or "0" to indicate the presence or absence of the data element related to the specific bit in the message. The first bit in the bit table has a value of "1", indicating that there is an auxiliary bit table following it, see Figure 1. Basic bit table
Signal bit table:-
Extended bit table
GB/T15150—94
(64) (65)
Data element
Data element
The basic bit table (1-64 bits) always exists. The most commonly used data elements are sorted according to these bit positions, and the less commonly used data elements are sorted according to the auxiliary bit table (65-128 bits). If the auxiliary bit table exists, the value of 01 in the basic bit table is taken as "1" to indicate (extended bit table). Table 2 gives: a. The data element assigned to each bit! b. The data element length and attribute specifications, listed in 4.3; c. The mandatory or conditional existence specifications of each message type identifier. \M\ indicates that the mandatory existence condition of this sub-item in the message is expressed in the form of "nn". For details, see Table 3. If the conditions given in Table 3 are met, this field The data element should not exist: otherwise, its presence in the message is determined by the agreement of both parties. The content in Table 2 allows the use of any data element in all messages. The message may include those additional mandatory and/or conditional data elements.
43 Data elements
The third part of the message and its data content consists of a series of data elements. Table 2 specifies the existence of these data elements according to the message type identifier.
The message is reorganized using the bit table as a close reference to the existing data elements. Some data elements have a fixed length, while others have a variable length. The actual length of any specified variable length data element is determined by its fixed length prefix. The message structure does not exclude the use of additional data elements in the message in the manner required for domestic exchange or civilian use. Table 4 The data elements listed in the table will be used in the message defined in Table 2. The first column is the name of the data element.
The first column is the description of the data element.
The third column includes the data element representation and the term index that can further describe the data element. The fourth column includes the bitmap indicator (P-basic, S-extended) and its position in the bitmap to identify the data element. The abbreviations used in the special column are as follows: a
=alphabetic character
=number
=special character
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.