《全国高速公路电子不停车收费联网系统参与方间接口设计.doc》由会员分享，可在线阅读，更多相关《全国高速公路电子不停车收费联网系统参与方间接口设计.doc（89页珍藏版）》请在三一文库上搜索。
1、附件1全国高速公路电子不停车收费联网参与方间接口设计2014年5月目录一.概述11.1范围11.2参考资料1二.术语和定义、符号、缩略语12.1术语和定义12.1.1交易处理12.1.2参与方22.1.3清分方22.1.4本地清分方22.1.5国家级清分方22.1.6发行方22.1.7公路收费方22.1.8清分22.1.9清分日32.1.10清分目标日32.1.11结算32.1.12结算日32.1.13清算32.1.14收款方32.1.15付款方32.1.16消息42.2缩略语42.3XML符号及说明定义4三.体系结构53.1基本结构53.2角色转换6四.传输规则74.1传输方式74.2基本结
2、构74.2.1数据存储形式74.2.2数据结构定义84.2.3数据类型84.3消息头94.4消息体124.5消息文件的命名规则124.6传输控制134.6.1通用确认消息结构134.6.2通用重发请求消息结构154.6.3名单数据的版本控制164.7名单数据的有效期204.8参与方ID204.9卡ID及卡类型21五.交易处理215.1应用范围215.2确认消息结构225.2.1应用范围225.2.2消息头225.3原始交易消息225.3.1应用范围225.3.2消息头235.3.3消息内容245.3.4处理流程305.4记帐处理消息315.4.1应用范围315.4.2消息头315.4.3消息内
3、容325.4.4处理流程345.5争议交易处理消息355.5.1应用范围355.5.2消息头365.5.3消息内容375.5.4处理流程395.6异常交易退费消息405.6.1应用范围405.6.2消息头405.6.3消息内容415.6.4处理流程435.7交易处理过程435.8清分消息455.8.1应用范围455.8.2消息头465.8.3消息内容465.8.4处理流程505.9结算消息545.9.1应用范围545.9.2消息头555.9.3消息内容565.9.4处理流程585.10交易数据逻辑检查595.10.1与交易相关消息间的关系595.10.2检查原始交易和记帐处理615.10.3检
4、查清分结果615.10.4检查结算结果61六.用户状态及用户信息处理616.1用户状态名单消息626.1.1发送消息结构626.1.2确认消息结构656.1.3消息处理流程666.2请求重发状态名单消息666.2.1发送消息结构666.2.2确认消息结构676.3用户信息列表消息686.3.1发送消息结构686.3.2确认消息结构726.3.3消息处理流程726.3.4发行代理列表736.4请求重发用户信息列表消息736.4.1发送消息结构736.4.2确认消息结构74七.基础信息维护747.1服务类型消息747.1.1发送消息结构747.1.2确认消息结构777.2请求重发服务类型消息777
5、.2.1发送消息结构777.2.2确认消息结构777.3参与方信息消息787.3.1发送消息结构787.3.2确认消息结构827.3.3处理规则837.4请求重发参与方信息消息847.4.1发送消息结构847.4.2确认消息结构847.5消息处理流程84八.消息总结848.1消息列表858.2消息确认对应关系8685一. 概述1.1 范围本协议规定了收费公路联网结算管理中心（部中心）系统及各省（区、市）内电子收费系统中各参与方（如公路收费方、清分方和发行方）之间的数据传输接口及处理流程。部中心和各省（区、市）清分结算系统之间的数据交换需按本协议执行；各省（市）内参与方间的数据交换可以本协议为参
6、考自行设计。1.2 参考资料下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。 GB/T 206102006/ISO/TS 14904 ：2002 道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范高速公路区域联网不停车收费示范工程暂行技术要求中华人民共和国金融行业JR/T 0025-2005 中国金融集成电路（IC）卡规范中华人民共和国交通部收费公路联网收费技术要求2007
7、年10月版二. 术语和定义、符号、缩略语2.1 术语和定义2.1.1 交易处理 交易处理是公路收费交易从公路收费方到清分方，再到发行方的整个传输、记帐、争议处理、清分统计、结算划帐等各个过程的总和。 2.1.2 参与方参与到整个电子收费运营的单位或实体。2.1.3 清分方清分方又称清分服务方，负责在本系统多个发行方及公路收费方之间交换数据，包括交易信息及各种状态信息等。同时，协调各方完成电子收费业务，包括争议处理、清分及结算等。2.1.4 本地清分方本地清分方又称为本省（市）清分方，是负责该清分方所属省（市）内的交易进行清分的参与方。本地清分方直接与本省（市）内的发行方和公路收费方相连。2.1
8、.5 国家级清分方在全国负责对跨省（市）交易进行清分的参与方。国家级清分方仅直接与区域内各省（市）的清分方相连，不与各地的发行方和公路收费方直接相连。2.1.6 发行方发行方是负责将公路收费方提供的各种服务销售给用户的实体。2.1.7 公路收费方又称服务方,是直接为终端用户提供服务，并且通过服务获得商业收益的实体。具体到公路电子收费业务，服务方是向用户提供高速道路通行并收费通行费的实体。2.1.8 清分清分是清分方统计各参与方应收/付款金额并与相关参与方核对数据的操作，每日进行一次。即使清分当日无交易，也应按规则生成清分信息。国家级清分方负责对全国发生的跨省（市）交易进行清分，称为一级清分；本
9、地清分方负责对在本省（市）内产生的交易进行清分，称为二级清分。2.1.9 清分日 清分日是清分方执行清分业务的日期。2.1.10 清分目标日清分目标日是公路收费方希望交易规属的清分日期。清分方仅对清分目标日早于清分日的交易进行清分。2.1.11 结算结算是清分方按一定周期，根据每日清分结果统计各方应收/付款金额并发布划帐指令的操作。国家级清分方负责对全国发生的跨省（市）交易进行结算，称为一级结算；本地清分方负责对在本省（市）内产生的交易进行结算，称为二级结算。一级结算和二级结算的周期可以不同。2.1.12 结算日清分方执行结算业务的日期。2.1.13 清算清分与结算的统称。2.1.14 收款方
10、接收服务费的参与方，可以是清分方和公路收费方。由于收款方可能发生存在异常交易退费，所以在极端情况下收款金额可以为负数，表示净支付。2.1.15 付款方支付服务费的参与方，可以是清分方和发行方。由于收款方可能发生存在异常交易退费，向付款方返还部分服务费，所以在极端情况下付款金额可以为负数，表示付款方净收入。2.1.16 消息在电子收费系统中，在各参与方之间需经计算机系统收、发处理的各种数据信息的总称。2.2 缩略语本标准所用缩略语如下表。缩略语英文全称含义XMLeXtensible Markup Language一种简单的数据存储语言，使用一系列简单的标记描述数据。IDIdentity身份标识号
11、码，也叫帐号，是一个编码，具有唯一性。2.3 XML符号及说明定义本文中定义XML结构的Schema通过如下图形表示：所有XML节点定义均以方框套节名称定义，如上图中的RootElement及Item1到Item8。根据连接线可知各个节点的关系：Item1到Item8均为RootElement的子节点。如果一个节点必须出现且仅能出现一次，则其方框为实线，没有任何下标，如Item1到Item5。如果一个节点可以被省略，即其出现次数可以为0，则其方框为虚线，如Item6和Item7。Item6的虚框下无下标，说明Item6最多可以出现一次；Item7的虚框下有下标，指明其出现次数的上限（上图中定义
12、为无穷大）。Item8的下标说明其出现次数必须在4次到8次之间，否则不能通过XML合法性验证。两个图形说明子节点的出现规则。前者表示子节点按结构图从上到下的顺序出现。例如，RootElement的子节点必须按Item1、Item2、Item3的顺序出现，否则无法通过合法性验证。后者表示子节点的出现是选择关系。例如，Item3、Item4、Item5均为RootElement的子节点，但在任意一个XML文件中，只能出现这三者之一，不能同时出现。在说明中通过RootElement.Item1、RootElement.Item2的形式表示上下级节点之间的关系。三. 体系结构3.1 基本结构本体系结构
13、根据道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范制定。联网电子收费体系结构为树型，在同一水平的两个参与方之间没有直接联系：l 省（市）清分方可以与本省（市）内的多个公路收费方和发行方相连。l 省（市）清分方通过区域清分方与其他省（市）清分方相连。l 本省（市）公路收费方与发行方通过本省（市）清分方相连。l 本省（市）公路收费方与发行方通过省（市）清分及区域清分方与其他省市的公路收费方与发行方相连。对于各省（市）的发行方和公路收费方而言，区域清分方和省（市）清分方组合在一起，成为系统清分结算的清分方，如下图：3.2 角色转换公路收费方是产生消息交易的参与方；发行方是从用户
14、帐户中按交易划拨服务费的参与方。由于省（市）清分方即向区域清分方提交其他地区用户在本省（市）产生的跨区交易，又为本省（市）用户在其他省（市）的跨区交易支付服务费，所以对区域清分方而言，各省（市）清分方即是公路收费方，又是发行方。因此，在后面对消息的说明中，除特别描述外，均以下图所示的简单结构阐述各消息的处理规则：四. 传输规则4.1 传输方式所有数据均通过中间件以文件方式传送。每个文件作为一个消息发送到接收方。接收方必须发送一个确认消息向发送方回应其接收消息的状态。4.2 基本结构4.2.1 数据存储形式所有传输的数据均采用XML存储，使用UTF-8编码，基本结构如下：所有消息，包括用于确认信
15、息的消息均使用以上基本结构。消息包含消息头Header和消息体Body。所有消息的消息头结构相同，仅使用的具体数值根据其不同应用有所区别。不同应用的消息体内部结构不同。Message节点作为整个消息文件的根节点，不得带有任何属性，如命名空间及SchemaLocation等，即消息必需为：.若未明确说明，所有整数类型的值均采用十进制，所有表示金额的节点均采用十进制并精确到分，如果123.45表示一百二十三元四角五分。所有数据结构以Schema形式定义。所有XML数据必需能够通过对应Schema的合法性验证。4.2.2 数据结构定义所有传输中的消息，均通过Schema定义文件结构。所有根据Sche
16、ma生成的XML文件，必需是合法的。Schema文件仅定义文件结构，不负责对数据的逻辑合法性进行验证。Schema定义中使用的标签名称（tag）与数据库定义使用的字段名没有必然关系。数据库定义时可以采用不同的名称表示Schema定义的内容。4.2.3 数据类型Schema中用于定义XML结构的部分数据类型说明见下表：XML数据类型说明示例Short2字节整数，以10进制表示Int4字节整数，以10进制表示Long8字节整数，以10进制表示Date日期YYYY-MM-DD，如2008-01-25DateTime时间，采用24小时表示法，以字符“T”作为日期与时间的分隔符，精确到秒 YYYY-MM
17、-DDTHH:mm:ss，如2008-01-25T15:33:46HexBinary在后文定义中简略为Hex(n)，以16进制数字对的方式表示一串字节数组的内容，高位在前，低位在后。n为16进制数的位数，不足规定长度的，左补0。由于两位16进制数表示1个字节，所以，n必为偶数。如保存1字节内容为Hex(2)，保存4字节内容为Hex(8)001a345f表示0x001a345f。若使用01a345f则在验证XML文件合法性时会产生错误，因为16进制数字串的长度是7，不是偶数长度。Decimal以10进制表示的浮点数如1340.56等String字符串，为表示长度，在后文定义时使用String(n
18、)进行表示。n为字符串最终存储的最大字节数。超过定义长度的部分将不被接收方处理。若省略n，表示不规定字符串长度。在消息定义中的BCD码通过HexBinary表示。本文中有关金额的单位，若未特别说明，均以“元”为单位。4.3 消息头消息头是所有消息均包含的第一个节点，表示消息的身份及用途，数据类型及意义如下：名称数据类型取值及说明VersionInt版本号，以10进制表示。从高到低前4位表示主版本号，中间3位表示次版本号，最后3位是修改号。如：1000000表示版本1.0.0MessageClassInt说明消息传输的机制MessageTypeInt说明消息的应用类型SenderIdHex(16
19、)发送方Id，在整个系统中唯一ReceiverIdHex(16)接收方Id，在整个系统中唯一MessageIdLong消息序号，从1开始递增，每次加1。消息序号由发送方维护。SenderId，ReceiverId及MessageId的组合，是一条消息在整个系统内的唯一身份标识。在一个消息从最初的发送方到最终接收方的传输过程中，Version、MessageClass和MessageType均不会改变。转发消息的参与方仅替换SenderId，ReceiverId及MessageId。例如，某公路收费方Id为1，其所在省（市）清分方Id为2，区域清分方Id为3，另一省（市）清分方Id为4，另一省（
20、市）的发行方Id为5，则公路收费方的交易消息包在逐级转发的过程中SenderId，ReceiverId和MessageId变化如下：传输阶段SenderIdReceiverId公路收费方到本省（市）清分方12本省（市）清分方到区域清分方23区域清分方到另一省（市）清分方34另一省（市）清分方到该省（市）发行方45在整个过程中，MessageId各个发送方自行控制。MessageClass以4字节整型表示。名称值说明请求Request1接收方需返回处理结果，可能包含大量数据请求应答Request Response2建议Advice3接收方需指明是否接受发送方的建议，返回信息简单建议应答Advic
21、e Response4通知Notification5接收方仅需指明接收是否正确通知应答Notification Response6MessageClass两两一组，每组中第一个值说明传输机制，该值加1即为第二个值，是对第一个值的确认操作。以上定义参考道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范制定。以C#定义为：public enum MessageClassRequest = 1,RequestResponse,Advice,AdviceResponse,Notification,NotificationResponseMessageType以4字节整型表示。名称值服
22、务列表Servcie List1价目表Fare Products List2用户信息Customer Details3分账规则Apportionment Rules4对账总金额Reconciliation Totals5授权Authorization6交易Transaction7报告已发送Report Sent8密钥管理Key Management9状态名单Status List10设备状态Equipment Status11例外事件Event Exception12接受付费方式Payment Method Acceptance13参与方信息Operator List14区域联网保留15200
23、00本地自定义20001以上以上定义参与道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范制定。以C#定义为：public enum MessageClassServiceList = 1,FareProductsList,CustomerDetails,ApportionmentRules,ReconciliationTotals,Authorization,Transaction,ReportSent,KeyManagement,StatusList,EquipmentStatus,EventException,PaymentMethodAcceptance,Operat
24、orList,LocalCustomized = 200014.4 消息体消息体包含一个可选属性ContentType和多个内容对象。消息头中的MessageClass说明消息传输、应答的方式；MessageType说明消息内容所属应用分类；ContentType说明在MessageType确定的应用中的具体分类。并不是所有消息体均有ContentType属性。如果某MessageType下仅传递一种信息，则该类消息的消息体忽略ContentType属性。4.5 消息文件的命名规则接收方为校验文件在传输过程中的完整性，约定收发双方以MD5算法对文件进行校验。发送方生成文件后，将文件转换成2进制
25、流用于MD5计算。计算所得结果为16字节2进制数据。命名规则为：SendereId +“_”+ ReceiverId +“_”+ MessageId +“_”+ MD5+文件扩展名。名称文件名中字符串长度取值或说明SenderId1616进制数，不足左补0ReceiverId1616进制数，不足左补0MessageId不定10进制数MD53216进制数，不足左补0扩展名3不使用压缩的原始数据文件，文件扩展名为“XML”,压缩后的扩展名为“ZIP”压缩算法为LZ77算法。每一个压缩文件仅包含一个原始数据文件。压缩文件与原始数据文件除扩展名不同外，文件名部分完全相同。4.6 传输控制发送方与接收方
26、的数据传输采用一问一答方式。发送方在规定时间内未接收到接收方的应答需通过自动重发、手动重发及文件导入/导出功能将数据传送到接收方。重发消息、导出消息的MessageId保持不变。接收方向发送方发送的确认消息不再等待对方回应，因此也不必重发。超时时间以分钟为单位，范围为1至60，默认值为10分钟。默认自动发送次数为3次（即自动重发2次）。若经过自动重发后仍未得到接收方的回应，则应报警由人工处理。以上默认值均应可通过参数配置进行调整。4.6.1 通用确认消息结构4.6.1.1 应用范围接收方收到发送方的消息后，必需给予发送方回应。不同的MessageClass，MessageType所使用的返回消
27、息结构不尽相同。但如果消息结构不正确（例如MessageClass值未定义）等无法通过校验的情况发生时，接收方需通知发送方消息异常。此时需使用通用确认消息结构。另外，对某些消息的回应相对简单，也使用通用确认消息结构发送。各消息的详细回应说明请参与相关章节。4.6.1.2 消息头名称数据类型取值或说明MessageClassInt若所接收消息的MessageClass有效，使用与其对应的Response值；否则使用所接收消息的MessageClass值MessageTypeInt使用所接收消息的MessageType4.6.1.3 消息内容Body的ContentType属性是可选的，在消息头M
28、essageClass和MessageType的基础上进一步指出响应的是哪一类消息，与所回应的消息的ContentType保持一致。Body各个子节点说明如下：名称数据类型取值或说明MessageIdLong当前消息所确认的消息IdProcessTimeDateTime处理时间ResultShort执行结果：1：消息已正常接收（用于Advice Response时含已接受建议）2：消息头错误，如MessageClass或MessageType不符合定义，SenderId不存在等3：验证未通过，即XML Schema验证未通过、签名谁未通过或MD5错误4：消息格式正确但内容错误，包括数量不符，内
29、容重复等5：消息重复6：消息正常接收，但不接受建议（仅用于Advice Response）7：消息版本错误820000：区域联网保留20001以上：本地自定义DescriptionString(100)对返回结果的说明。例如对于结果4，在说明应指出具体的错误原因。4.6.2 通用重发请求消息结构4.6.2.1 应用范围应用于数据接收方向数据发送方请求重发某些数据。4.6.2.2 消息头名称数据类型取值或说明MessageClassInt1，RequestMessageTypeInt请求重发的数据类型对应的MessageType4.6.2.3 消息内容通用重发请求消息中没有更多的数据，其Body
30、为空。4.6.3 名单数据的版本控制4.6.3.1 应用范围用户状态名单及基础信息等所有经常变动的数据。4.6.3.2 名单形式名单数据会随着系统运行不断更新。所有名单类数据的更新方式分为整体更新和增量更新两类。整体更新是数据包包含系统当前所有名单记录，接收方通过删除原有名单，直接使用接收到的新名单即可达到名单同步的目的。增量更新是发送方只告知接收方发生数据内容改变的记录，接收方根据增量内容修改其现有名单从而达到数据同步。4.6.3.3 名单顺序整体下发是静态的。使用该方式可以保证发送方与接收方名单数据的同步，但每当名单发生变化时都使用整体形式下发会降低系统效率，因为大部分名单数据在两次下发之
31、间是没有变化的。增量下发是动态的，相对整体下发数据量少，适合及时通知接收方名单的改变。通过以上两种方式可以有效地同步发送方与接收方的名单数据，但这种方式对发送顺序与接收顺序要求十分严格。如果接收顺序与发送顺序不同，会使数据更新异常。大多数中间件均不能保证消息的发送顺序与接收顺序相同，所以在名单数据中，以版本号表示发送的先后顺序。版本号从1开始，每次加1，增量名单和整体名单使用同一递增序列。生成名单数据的参与方负责版本号。4.6.3.4 主动发送的版本处理4.6.3.4.1 处理规则发送方保证版本号逐一递增。接收方校验版本号，并根据版本号及名单形式执行相应处理。设接收方已处理的版本号为OldVe
32、r，刚刚接收的名单版本号为NewVer，处理规则如下：1) 若NewVer OldVer则可直接处理接收到的名单，清除在第3步中临时保存的版本小于等于NewVer的名单，完成后更新OldVer的值，即设置OldVer = NewVer。3) 如果新接收的名单是增量名单，则只有NewVer = OldVer + 1时方可立即处理，并更新OldVer的值后结束处理。否则临时保存该名单直到合适的名单（NewVer = OldVer + 1的增量名单或NewVer OldVer的整体名单）到达。等待时间可设定。若等待一段时间后仍没有合适的名单，则向发送方请求重发名单（如果以前已经发送过整体名单请求重发
33、消息且没有收到回复则不发送）；之后收到的名单分别按第2或3步处理。4.6.3.4.2 示例以下是名单处理示例流程图：上图中未包含退出等待状态，说明见下文示例。“处理名单”包括的操作有：l 根据名单更新本地数据库；l 删除临时保存的版本号小于NewVer的名单；l 如果仍有临时保存的名单中存在，版本连续且与NewVer相临，则循环处理这些名单；l 更新OldVer值为最大已处理名单的版本号。处理完成后临时保存的只有版本号大于OldVer + 1的名单。等待状态中可以继续接收消息并处理。举例：当前已处理的状态名单版本为3，之后收到的版本顺序为：6（增量）,7（增量），4（增量）,9（增量），8（整
34、体）,10（回复请求重发的整体名单），5（增量）。处理过程为：l 收到版本为6的名单：临时保存，进入等待状态（假设等待时间结束为收到版本为9的名单之后）。l 收到版本为7的名单：临时保存，保持原等待状态。l 收到版本为4的名单：处理此名单，更新OldVer为4，因为临时保存的名单显示仍缺版本为5的名单，所以不改变等待状态。等待时钟重新计时（假设等待时间结束仍为收到版本为9的名单之后）。l 收到版本为9的名单：临时保存，保持原等待状态。l 等待结束，说明通讯可能发生问题，为及时得到最新的名单，发送名单请求重发消息给发送方。l 收到版本为8的整体名单：处理此名单，更新OldVer为8，删除临时保存
35、的版本为6和7的名单，不对这两个名单进行处理。l 处理临时保存的版本为9的名单，更新OldVer为9，退出等待状态。l 收到版本为10的回复名单：处理此名单，更新OldVer为10。l 收到版本为5的名单：忽略。4.6.3.5 响应请求重发的版本处理名单接收方可以向名单发送方请求发送当前完整的名单信息。名单的发送方有两类，一类是名单的产生方，即产生用户状态名单的发行方；另一类是名单的转发方，即清分方。这两类参与方在接收到请求重发名单后，处理规则相同：l 被请求方接收到重发请求后，根据本地数据产生整体名单，并使用正在使用最新的版本号作为名单的版本号。l 接收方已处理的版本号为OldVer，刚刚接
36、收的重发请求回应名单版本号为NewVer，处理规则如下：l 若NewVer OldVer，说明当前使用的名单比接收到的名单版本更新，所以直接忽略接收到的名单。否则，因为重发请求回应是整体名单，所以直接处理接收到的名单并更新OldVer，删除所有临时保存的名单。4.7 名单数据的有效期名单数据根据生效期应能保存多个版本。4.8 参与方ID在消息交换中使用的发送方ID、接收方ID，以及消息中包含的公路收费方ID、发行方ID及清分方ID均可以8字节整数存储，在整个系统内唯一。在XML中，参与方ID表现为16位长的16进制字符串，数据类型为HexBinary，不足16位左侧补0。实际定义中，参与方ID
37、为16位BCD码。前4字节省内自定义，对于跨省数据接口前4字节为99999999。第5个字节标识区域中心或省级参与方ID，统一使用省级行政区划代码的压缩BCD码表示，如：11 北京，12 天津，13 河北。对于区域清分，使用约定代码，如京津冀区域联网电子收费清分中心的代码是01。第6个字节为参与方类型：01为发行方，02为清分方，03为公路收费方，04为收费代理方。第7、8字节为机构序号，从1开始。在XML中，参与方ID表现为16位长的16进制字符串，数据类型为HexBinary，不足16位左侧补0。相应XML报文值十六进制显示值见下表： 参与方代码说明区域京津冀清分中心9999 9999 0
38、1 02 0001清分方北京首发路网9999 9999 11 03 0001公路收费方华北高速9999 9999 11 03 0002机场高速9999 9999 11 03 0003京通快速9999 9999 11 03 0004快通公司9999 9999 11 01 0001发行方北京清分中心9999 9999 1102 0001清分方天津天津路网9999 9999 12 03 0001公路收费方天津发行9999 9999 12 01 0001发行方天津清分9999 9999 12 02 0001清分方河北河北路网9999 9999 13 03 0001公路收费方河北发行9999 9999
39、13 01 0001发行方河北清分9999 9999 13 02 0001清分方4.9 卡ID及卡类型卡ID在本系统中的唯一性表示为：网络编码 + 卡发行号。网络编码为4位BCD码，IC卡发行号为16位BCD码，电子标签发行号为12位BCD码。在XML文件中，均以HexBinary表示。不足位数左侧补0。五. 交易处理5.1 应用范围交易处理是公路收费交易从公路收费方到清分方（含本地清分方及区域清分方），再到发行方的整个传输、记帐、争议处理、清分统计、结算统计等各个过程的总和。本节说明在整个处理过程中使用的消息结构及处理流程。所有交易消息的接收方均需通过通用确认消息通知发送方消息接收结果。该确
40、认消息仅表示接收方是否正确收到交易消息包，不表示这些交易是否被正确记帐。除清分与结算外，其它数据在区域清分方及省（市）清分方之间仅为转发关系。因此，为简化描述，后文中若未明确说明，均以体系结构中的简单结构对交易处理过程进行说明。5.2 确认消息结构5.2.1 应用范围接收方与发送方之间对交易消息、清分消息等消息的应答均使用通用确认消息结构。确认消息返回正确时仅表示正确接收，并不包含详细的处理结果。若接收异常，通过确认消息中的Result和Description，可得到错误信息。5.2.2 消息头名称数据类型取值或说明MessageClassInt6，Notification ResponseM
41、essageTypeInt5，Reconciliation Totals7，Transaction当确认交易记录、争议处理结果和异常交易退费时，MessageType为7；确认记帐、清分、结算消息时，MessageType为5。具体确认的是那一个子类的消息，由Body的ContentType说明。5.3 原始交易消息5.3.1 应用范围由公路收费方经清分方发送给发行方的原始交易数据。消息发送方向如图：上图以公路收费方A发送交易信息为例说明原始交易消息在系统内的传输方向。黄底色的节点是消息的产生方。5.3.2 消息头名称数据类型取值或说明MessageClassInt5，Notification
42、MessageTypeInt7，Transaction5.3.3 消息内容交易信息中，Body的各个子节点说明如下：名称数据类型取值及说明ContentTypeInt1ClearTargetDateDate清分目标日ServiceProviderIdHex(16)公路收费方Id，表示消息包中的交易是由哪个公路收费方产生的IssuerIdHex(16)发行方Id，表示产生交易记录的电子介质所属的发行方MessageIdLong公路收费方生成的交易消息包IdCountInt本消息包含的交易记录数量，大于1，小于1万AmountDecimal交易总金额，大于等于0Transaction多条交易信息公
43、路收费方按照电子介质所属的发行方，将原始交易分组打包，发送给清分方。清分方按交易包中指明的发行方将交易提交给对应对发行方（含经区域清分方转发）处理。在同一个交易包中，不能包含属于不同发行方发行的IC卡所产生的交易。同时，同一个交易包中，仅能包含同一清分目标日的交易数据。在整个传输过程中，消息包的MessageId会发变化。为保证发行方能正确对应公路收费方的原始交易包，公路收费方在生成原始交易消息时应将该消息的MessageId值保存在Body的子节点MessageId中。即公路收费方生成的原始交易消息中，Header的子节点MessageId与Body的子节点MessageId的值相同。在其它
44、传输阶段，这两个值可能不同。在整个传输过程中Body节点的MessageId保持不变。交易包中包含原始交易记录。交易记录的格式如下：交易记录的属性说明如下：名称数据类型取值及说明TransIdInt是由公路收费方产生的该包内顺序Id，从1开始递增。在公路收费方、清分方、发行方三方的交易通讯过程中均采用此Id表示包内唯一的交易记录。通过MessageId与TransId，可以在系统中唯一确定一条交易。TimeDateTime交易的发生时间，需参加TAC计算FeeDecimal交易的发生金额，以元为单位，大于等于0Service服务信息ICCardIC卡信息Validation与校验相关的信息OBU参加交易的电子标