高速公路区域联网不停车收费示范工程暂行技术要求第20部分跨省（区、市）数据接口规范
2008年8月
GB/T ××××—××××
目次
1 范围 (2)
2 规范性引用文件 (2)
3 术语和定义、符号、缩略语 (2)
4 传输规则 (2)
5 交易处理 (13)
6 用户状态处理 (31)
7 基础信息维护 (36)
附录 A （规范性附录）消息总结 (44)
A.1 消息列表 (44)
A.2 消息确认对应关系 (45)
参考文献 (46)
1 范围
本标准规定了高速公路联网电子收费系统跨省（区、市）电子收费系统中清分方之间的数据传输接口及处理流程。
本标准适用于公路联网电子收费系统的设计、开发与应用，城市收费道路也可参考执行。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
GB/T 20610—2006/ISO/TS 14904 ：2002《道路运输与交通信息技术电子收费（EFC）参与方之间信息交互接口的规范》
3 术语和定义、符号、缩略语
3.1 术语和定义
《省（区、间）数据接口规范》中确立的术语和定义适用于本规范。
3.2 缩略语
本标准所用缩略语如下表。
缩略语
缩略语英文全称含义
XML eXtensible Markup Language 一种简单的数据存储语言，使用一系列简单的标记描述数据。
ID Identity 身份标识号码，也叫帐号，是一个编码，具有唯一性。
3.3 XML符号定义
本文中定义XML结构的Schema通过如下图形表示：
GB/T ××××—××××
所有XML节点定义均以方框套点节名称定义，如上图中的RootElement及Item1到Item8。根据连接线可知各个节点的关系：Item1到Item8均为RootElement的子节点。
如果一个节点必须出现且仅能出现一次，则其方框为实线，没有任何下标，如Item1到Item5。
如果一个节点可以被省略，即其出现次数可以为0，则其方框为虚线，如Item6和Item7。Item6的虚框下无下标，说明Item6最多可以出现一次；Item7的虚框下有下标，指明其出现次数的上限（上图中定义为无穷大）。
Item8的下标说明其出现次数必须在4次到8次之间，否则不能通过XML合法性验证。
数据类型
说明 示例 Int
4字节整数，以10进制表示 Long
8字节整数，以10进制表示 Date
日期 YYYY-MM-DD ，如2008-01-25 DateTime 时间，采用24小时表示法，以字符“T ”作为日
期与时间的分隔符，精确到秒
YYYY-MM-DDTHH:mm:ss ，如 2008-01-25T15:33:46 HexBinary 在后文定义中简略为Hex(n)，以16进制数字对
的方式表示一串字节数组的内容，高位在前，低
位在后。n 为长度，每两个16进制数表示1个字
节，所以，n 必定是偶数。不足规定长度的，左
补0。Schema 定义本身不规定Hex 的长度（只要
保证是偶数），长度控制由应用程序负责 001a345f 表示0x001a345f 。若使用01a345f 则在验证XML 文件合法性时会产生错误，因为数字串的长度是7，不是偶数长度。
Decimal 以10进制表示的浮点数 如1340.56等
String 字符串，为表示长度，在后文定义时使用String(n)进行表示。n 为字符串最终存储的最大字节数。超过定义长度的部分将不被接收方处理。若省略
n ，表示不规定字符串长度。
汉字字符串字节长度的计算应
以GB18030大字符集的编码为
依据，1个汉字用2个字节保存
4.3 消息头
消息头是所有消息均包含的第一个节点，表示消息的身份及用途，数据类型及意义如下：
名称 数据类型 取值及说明
Version Hex(8) 版本号，按照从高位到低位分解4字节的整数，每两个字节表
示一个序号：前两个字节表示主版本号，第三个字节表示次版
本号，最后一个字节表示修改编号。如00010102（16进制）
GB/T ××××—××××
名称数据类型取值及说明
表示版本1.1.2。
MessageClass Int 说明消息传输的机制
MessageType Int 说明消息的应用类型
SenderId Hex(16) 发送方Id，在整个系统中唯一
ReceiverId Hex(16) 接收方Id，在整个系统中唯一
MessageId Long 消息序号，8字节整数，从1开始，逐1递增
通过SenderId、ReceiverId及MessageId组合，可以在整个系统中唯一确定一条消息。MessageId由发送方产生。
MessageClass以4字节整型表示。
名称值说明
请求Request 1
请求应答Request Response 2
接收方需返回处理结果，可能包含大量数据
建议Advice 3 建议应答Advice Response 4 接收方需指明是否接受发送方的建议，返回信息简单
通知Notification 5
通知应答Notification Response 6
接收方仅需指明接收是否正确
以C#定义为：
public enum MessageClass
{
Request = 1,
RequestResponse,
Advice,
AdviceResponse,
Notification,
NotificationResponse
}
MessageType以4字节整型表示。
名称值服务列表Servcie List 1
价目表Fare Products List 2
用户信息Customer Details 3
名称值
分账规则Apportionment Rules 4
对账总金额Reconciliation Totals 5
授权Authorization 6
交易Transaction 7
报告已发送Report Sent 8
密钥管理Key Management 9
状态名单Status List 10
设备状态Equipment Status 11
例外事件Event Exception 12
接受付费方式Payment Method Acceptance 13
参与方信息Operator List 14
公务卡名单Privilege List 15
保留16
标签拆卸17
未定义的消息类型Undefined Message Type 18至65535
个性化消息类型大于65535的整数
以C#定义为：
public enum MessageClass
{
ServiceList = 1,
FareProductsList,
CustomerDetails,
ApportionmentRules,
ReconciliationTotals,
Authorization,
Transaction,
ReportSent,
KeyManagement,
StatusList,
EquipmentStatus,
EventException,
PaymentMethodAcceptance,
OperatorList,
GB/T ××××—××××
PrivilegeList,
Reserved,
TagAbuse,
Undefined
}
4.4 消息体
消息体包含一个属性ContentType和多个内容对象。
消息头中的MessageClass说明消息传输、应答的方式；MessageType说明消息内容所属应用分类；ContentType说明在MessageType确定的应用中的具体分类。
并不是所有消息体均有ContentType属性。如果某MessageType下仅传递一种信息，则该类消息的消息体可忽略ContentType属性。
4.5 消息文件的命名规则
接收方为校验文件在传输过程中的完整性，约定收发双方以标准MD5算法（RFC 1321 The MD5 Message-Digest Algorithm，MD5信息分类算法）对文件进行校验。发送方生成文件后，将文件转换成2进制流用于MD5计算。计算所得结果为16字节2进制数据（128位），并用MD5结果对文件命名。
命名规则为：
MessageId（消息包ID，10进制）+‘_’+ MD5验证结果（16进制，不足左补0）+ 文件扩展名。
未压缩的原始消息文件，文件扩展名为‘.XML’,压缩后的扩展名为‘.ZIP’。
每一个压缩文件仅包含一个原始数据文件。压缩文件与原始数据文件除扩展名不同外，文件名部分完全相同。
4.6 传输控制
发送方与接收方的数据传输采用一问一答方式。发送方在规定时间内未接收到接收方的应答需通过自动重发、手动重发及文件导入/导出功能将数据传送到接收方。重发消息、导出消息的MessageId保持不变。
发送方发送的两条消息之间不存在必然的逻辑关系。
4.6.1 通用确认消息结构
4.6.1.1 应用范围
接收方收到发送方的消息后，必需给予发送方回应。不同的MessageClass，MessageType 所使用的返回消息结构不尽相同。
接收方对于消息结构不正确（例如MessageClass值未定义）的消息，使用通用确认消息结构通知发送方消息异常。
各消息的详细回应说明请参与相关章节。
4.6.1.2 消息头
名称数据类型取值或说明
MessageClass Int 使用所接收消息的MessageClass
名称
数据
类型 取值或说明 MessageType
Int 若所接收消息的MessageType 有效，使用与其对应的Response 值；否则使用所接收消息的MessageType 值加1 SenderId
Hex(16) 当前参与方Id ReceiverId Hex(16) 准备接收确认消息的参与方Id
4.6.1.3 消息内容
Body 的ContentType 属性是可选的，在消息头MessageClass 和MessageType 的基础上进一步指出响应的是哪一类消息，与所回应的消息的ContentType 保持一致。Body 各个子节点说明如下： 名称
数据类型 取值或说明
MessageId
Long 确认的消息Id ProcessTime DateTime 处理时间
Result Short 执行结果：
1.
消息已正常接收（用于Advice Response 时含已接受建议） 2. 消息头错误，如MessageClass 或MessageType 不符合定
义，SenderId 不存在等
3.
消息格式不正确，即XML Schema 验证未通过 4.
消息格式正确但内容错误，包括数量不符，内容重复等 5.
消息重复 6.
消息正常接收，但不接受建议（仅用于Advice Response ） 7.
消息版本错误 8. 参与方ID 未定义：消息体内部包含的有关参与方信息的
ID 在系统中未定义
GB/T ××××—××××
名称数据类型取值或说明
9.不支持的业务：消息格式等均正确，但发送方不应将该消
息发送给接收方，例如，服务类型只能由清分方产生并发
送给其他参与方，发行方和收费服务方不能产生并发送该
类型的消息
4.6.2 通用重发请求消息结构
4.6.2.1 应用范围
应用于数据接收方向数据发送方请求重发某些数据，如基础信息。
4.6.2.2 消息头
名称数据类型取值或说明
MessageClass Int 1，Request
MessageType Int 请求重发的数据类型对应的MessageType
SenderId Hex(16) 当前参与方Id
ReceiverId Hex(16) 准备接收确认消息的参与方Id
4.6.2.3 消息内容
通用重发请求消息中没有更多的数据，其Body为空。
4.6.3 名单数据的形式
名单数据主要应用于用户状态名单、基础信息等所有经常变动的数据。
名单数据会随着系统运行不断更新。所有名单类数据的更新方式分为整体更新和增量更新两类。整体更新是数据包包含所有名单记录，接收方通过删除原有名单，直接使用接收到的新名单即可达到名单同步的目的。增量更新是发送方只告知接收方发生数据内容改变的记录，接收方根据增量内容修改其现有名单从而达到数据同步。
4.6.4 名单数据的版本控制
以下处理规则用于确保名单数据在通讯系统不保证数据的接收与发送顺序一致的情况下正确更新。如果通讯的双方能够保证发送顺序与接收顺序相同，则不必须使用下文中有关版本控制的处理逻辑。
4.6.4.1 名单顺序
整体下发可以保证发送方与接收方名单数据的同步，但每当名单发生变化时都使用整体形式下发会降低系统效率，因为大部分名单数据在两次下发之间是没有变化的。整体下发是静态的。
增量下发是动态的，相对整体下发数据量少，适合及时通知接收方名单的改变。
通过以上两种方式可以有效地同步发送方与接收方的名单数据，但这种方式对发送顺序与接收顺序要求十分严格。如果接收顺序与发送顺序不同，会使数据更新异常。大多数中间件均不能保证消息的发送顺序与接收顺序相同，所以在名单数据中，以版本号表示发送的先后顺序。
4.6.4.2 主动发送的版本处理
处理规则
发送方保证版本号逐一递增。接收方校验版本号，并根据版本号及名单形式执行相应处理。
设接收方已处理的版本号为OldVer，刚刚接收的名单版本号为NewVer，处理规则如下：1）若NewVer <= OldVer，说明当前使用的名单比接收到的名单版本更新，所以直接忽略接收到的名单。否则，转至下一步。
2）如果新接收的名单是整体名单，则只要NewVer > OldVer则可直接处理接收到的名单，清除在第3步中临时保存的版本<=NewVer名单，完成后更新OldVer的值，即设置OldVer = NewVer。
3）如果新接收的名单是增量名单，则只有NewVer = OldVer +1时方可立即处理，并更新OldVer的值后转到第4步。否则临时保存该名单直到合适的名单（NewVer= OldVer+ 1的增量名单或NewVe r > OldVer的整体名单）到达。等待时间可设定。若等待一段时间后仍没有合适的名单，则向发送方请求重发名单（如果以前已经发送过整体名单请求重发消息且没有收到回复则不发送），之后收到的名单分别按第2或3步处理。
示例
以下是名单处理示例流程图：
上图中未包含退出等待状态，说明见下文示例。
GB/T ××××—×××ד处理名单”包括的操作有：
l根据名单更新本地数据库；
l删除临时保存的版本号小于NewVer的名单；
l如果仍有临时保存的名单中存在，版本连续且与NewVer相临，则循环处理这些名单；
l更新OldVer值为最大已处理名单的版本号。
处理完成后临时保存的只有版本号大于OldVer + 1的名单。
等待状态中可以继续接收消息并处理。
举例：当前已处理的状态名单版本为3，之后收到的版本顺序为：6（增量）,7（增量），4（增量）,9（增量），8（整体）,10（回复请求重发的整体名单），5（增量）。
处理过程为：
l收到版本为6的名单：临时保存，进入等待状态（假设等待时间结束为收到版本为9的名单之后）。
l收到版本为7的名单：临时保存，保持原等待状态。
l收到版本为4的名单：处理此名单，更新OldVer为4，因为临时保存的名单显示仍缺版本为5的名单，所以不改变等待状态。等待时钟重新计时（假
设等待时间结束仍为收到版本为9的名单之后）。
l收到版本为9的名单：临时保存，保持原等待状态。
l等待结束，说明通讯可能发生问题，为及时得到最新的名单，发送名单请求重发消息给发送方。
l收到版本为8的整体名单：处理此名单，更新OldVer为8，删除临时保存的版本为6和7的名单，不对这两个名单进行处理。
l处理临时保存的版本为9的名单，更新OldVer为9，退出等待状态。
l收到版本为10的回复名单：处理此名单，更新OldVer为10。
l收到版本为5的名单：忽略。
4.6.4.3 响应请求重发的版本处理
名单接收方可以向名单发送方请求发送当前完整的名单信息。名单的发送方有两类，一类是名单的产生方，即产生用户状态名单的发行方；另一类是名单的转发方，即清分方。
名单的产生方在接收到重发请求后，可以产生包含整体名单数据及新版本号的数据名单，接收方的处理与主动发送的版本处理相同。
名单的转发方自己并不产生名单，所以不能产生新的版本号，只能使用当前最新的版本号。
名单转发方的处理规则如下：
l名单转发方接收到重发请求后，根据本地数据产生整体名单，并使用最新的版本号作为名单的版本号。
l设接收方已处理的版本号为OldVer，刚刚接收的名单版本号为NewVer，处理规则如下：
l若NewVer < OldVer，说明当前使用的名单比接收到的名单版本更新，所以直接忽略接收到的名单。否则，因为重发请求回应是整体名单，所以直接
处理接收到的名单并更新OldVer，删除所有临时保存的名单。
4.7 名单数据的有效期
名单数据除服务类型外，通讯消息中每条记录均有生效时间。各个系统在使用名单数据时均需检查生效时间，并根据接收到的新的名单处理已有记录的失效时间。到达失效时间后，系统应自动将记录从名单中备份删除。名单数据应能保存多个版本。
用于传送名单数据的消息仅包含每条记录的生效时间，但在系统中，应保存名单记录的生效时间和失效时间。失效时间由接收系统自行维护。
以用户状态名单为例，当前系统使用的用户状态名单记录如下：（生效时间及失效时间均可精确到秒，但示例中为简单仅精确到日；卡ID也只使用发行序号）
8月1日状态名单
卡ID 状态生效时间失效时间
1 透支2007年8月1日无
2 挂失2007年8月1日无
3 禁用2007年8月1日无
因为名单消息中仅指出每条记录的生效时间，没有失效时间，所以默认为永不失效。失效时间根据新接收到的名单发生变化。
2007年8月4日接收到增量状态名单，包含卡ID为1、2、4、5的记录：
8月4日增量名单
卡ID 状态生效时间
1 正常2007年8月5日
2 禁用2007年8月5日
4 挂失2007年8月5日
5 禁用2007年8月5日
根据该增量名单更新后，系统中的名单记录为：
8月4日更新后的状态名单
卡ID 状态生效时间失效时间
1 透支2007年8月1日2007年8月5日
2 挂失2007年8月1日2007年8月5日
2 禁用2007年8月5日无
3 禁用2007年8月1日无
GB/T ××××—××××卡ID 状态生效时间失效时间
4 透支2007年8月5日无
5 挂失2007年8月5日无
在8月5日之前，1号卡仍然处于透支状态；到8月5日，系统应自动将其删除。同理，系统在8月5日删除2号卡状态为挂失的记录。在未收到新的名单之前，2至5号卡的状态均永久有效。
在以上结果中，同时保存了有关2号卡的两条记录。系统根据自行维护的失效时间删除符合失效时间范围的记录。
8月6日收到整体名单如下：
8月6日的整体名单
卡ID 状态生效时间
2 禁用2007年8月5日
4 透支2007年8月5日
6 禁用2007年8月8日
则系统内状态名单更新为：
8月6日更新后的状态名单
卡ID 状态生效时间失效时间
2 禁用2007年8月5日无
4 透支2007年8月5日无
6 禁用2007年8月8日无
整体名单包含全部最新的状态记录，所以直接删除系统中现有记录，并使用新数据更新即可。
4.8 参与方ID
在消息交换中使用的发送方ID、接收方ID，以及消息中包含的收费服务方ID、发行方ID 及清分方ID均可以8字节整数存储，在整个系统内唯一。
在XML中，参与方ID表现为16位长的16进制字符串，数据类型为HexBinary，不足16位左侧补0。
4.9 卡ID及卡类型
卡类型分为国标IC卡和车载单元两种。不排除各发行方使用同一个参与方ID发行多种卡的可能。
卡ID在本系统中的唯一性表示为：网络编码+ 卡发行号。
网络编码为4位16进制数，卡发行号为16位16进制数。在XML文件中，均以HexBinary 表示。不足位数左侧补0。
5 交易处理
5.1 应用范围
交易处理是公路收费交易从收费服务方到清分方，再到发行方的整个传输、记帐、争议处理、清分统计、结算划帐等各个过程的总和。本节说明在整个处理过程中使用的消息结构及处理流程。
所有交易消息的接收方均需通过通用确认消息通知发送方消息接收结果。
5.2 处理规则
5.2.1 交易处理
参见《高速公路联网电子收费清分结算系统运行规则》。
5.2.2 清分
清分系统每天统计如下两组交易：
l所有收到的，已由发行方记帐确认的，消息包的清分目标日早于或等于需统计的清分目标日的交易包所包含的交易。统计时仍未收到的交易包，或
交易包已收到但尚未得到发行方记帐确认的交易包后到下一日统计。
l在清分目标日内及以前产生的未清分统计过的争议交易处理结果所包含的交易。
所统计的交易必须同时满足以下所有条件：
1）所统计的交易必须符合时间区段的约束，即交易包的清分目标日或争议处理日期必须早于时间区段的结束时间；
2）所有已由发行方确认的交易包所包含的确认付款的交易；
3）所有由争议处理确认付款的交易；
4）所统计的交易尚未参与清分。
对进行过清分统计的清分目标日不再进行清分统计，其统计结果不能更改。
下图举例说明：
15.
假设交易包1、2和争议处理结果1、2均未进行过清分统计，但争议结果2不符合清分目标日的时间范围，所以清分时仅统计交易包1、2和争议处结果1。
因此，清分结果包含交易1、2、3、4、5、8、9、10、11、12、13和14。
包含交易6、7的争议结果2会在后续的清分日统计。
GB/T ××××—××××
交易15尚未进行过处理，所以直到争议处理后再统计。
5.3 原始交易消息结构
5.3.1 应用范围
由收费服务方将交易分组打包后发送给清分方的原始交易数据。交易数据的发送方向是：收费服务方→本地清分方，本地清分方→异地清分方，异地清分方→异地发行方，三个阶段的传输使用相同的消息结构。
5.3.2 消息头
名称数据类型取值或说明
MessageClass Int 5，Notification
MessageType Int 7，Transaction
SenderId Hex(16) 收费服务方系统Id/清分方Id
ReceiverId Hex(16) 清分方Id/发行方Id
SenderId与ReceiverId的取值：
发送阶段SendId ReceiverId
收费服务方→清分方收费服务方Id 清分方Id
本地清分方→异地清分方本地清分方Id 异地清分方Id
清分方→发行方清分方Id 发行方Id
5.3.3 消息内容
交易信息中，Body的ContentType始终为1，Body各个子节点说明如下：名称数据类型取值及说明
ServiceProviderId Hex(16) 收费服务方Id，表示消息包中的交易是由哪个收费服务方产生的。
IssuerId Hex(16) 发行方Id，表示产生交易记录的电子介质所属的发行方。
MessageId Long 交易消息包Id。由收费服务方发送包到清分方时，该字段与消息头的MessageId相同。清分方转发的消息此字段不用改变。各参与方可通过ServiceProviderId和MessageId在系统唯一确定一个原始交易信息包。
ClearTargetDate Date 清分目标日
Count Int 本消息包含的记录数量
Amount Decimal 交易总金额
收费服务方按照电子介质所属的发行方，将原始交易分组打包，发送给清分方。清分方按交易包中指明的发行方将交易提交给对应对发行方处理。
交易包中包含原始交易记录。交易记录的格式如下：
GB/T ××××—××××
交易记录的属性说明如下：
名称数据类型取值及说明
TransId Int 是由收费服务方产生的该包内顺序Id，从1开始递增。在收费服务方、清分方、发行方三方的交易通讯过程中均采用此Id表示包内唯一的交易记录。通过MessageId与TransId，可以在系统中唯一确定一条交易。
CardType Short 卡类型
NetNo Hex(4) 网络编码
CardId Hex(16) IC卡物理编号（发行号）。
TransTime DateTime 交易的发生时间
ServiceType Short 交易的服务类型，取值见基础信息维护
Fee Decimal 交易的发生金额
Description String(100) 对交易的文字解释。如：回龙观北入至清河主出
OriginalData String 包含所有校验信息在内的原始信息
为了给用户提供完整的消费清单，即使消费金额为0，也应将交易信息发送给发行方。
为减小每个数据包的大小，保证通讯质量，每个交易消息包最多包含10000条交易。若一次需传送的交易数量大于10000条，则需分多个消息传送。
每个交易包中的交易，必须属于同一个清分目标日，不属于同一清分目标日的交易需分别打包。
OriginalData项以字符串方式记录收费交易详细，各字段数据间以“|”作为分隔符。若某字段数据为空，则在前后两个“|”之间不填写任何字符串。
本规范列出的七个字段是OriginalData必须填写的字段，由收费服务方产生，用于发行方做TAC码认证。发行方可以在TAC字段后增加个性化字段定义，包含在OriginalData中一并传送。省（区、市）外的收费服务方并不一定在OriginalData中生成这些个性化字段内容，发行方在处理时应首先确定OriginalData中的个性化字段是否是自己定义的内容。
清分方原则上不处理OriginalData中的数据。
字段组织顺序及内容如下：
序号字段名交易终端数据描述接口数据格式描述
1.卡类型无1：储值卡；2：计帐卡
2.交易金额4字节，交易金额8位的16进制字符串，例如：11223344
3.交易类型标识1字节，PBOC定义2位的16进制字符串，例如：A8
4.终端机编号6字节，即PSAM号，PSAM中
0016文件中的终端机编号12位16进制字符串，例如：0102301AF3D9
5.终端交易日期4字节YYYY-MM-DD
6.终端交易时间3字节HH:mm:ss
7.终端机交易序号4字节，PSAM卡脱机交易序号，
在MAC1计算过程中得到8位16进制字符串。仅在卡类型为储值卡时有效，若是计帐卡，此字段为空
储值卡TAC验证字段（上表第2到7项）引自《中华人民共和国金融行业JR/T 0025-2005 中国金融集成电路（IC）卡规范》第1、2部分。
记帐卡交易时不生成终端机交易序号，因此对应字段填空值。
5.3.4 发送规则
收费服务方将计算费率后的记录打包生成原始交易包发送给清分方需满足如下两个条件之一：
l到达预定义的时间间隔（如10分钟、半小时）；
l在时间间隔未到达前，积累未发送的记录达到一定数量（如前面定义的10000条）。
清分方仅转发收费服务方的交易数据包。
5.4 记帐处理消息结构
5.4.1 应用范围
记帐消息是由发行方根据清分方传来的收费服务方原始交易包经过记帐处理后的结果。对每一个收费方原始交易包，发行方均返回且仅返回一个记帐处理结果。
清分方接到记帐处理后要转发到相应收费服务方。记帐数据的发送方向是：异地发行方→异地清分方→本地清分方→本地收费服务方，三个阶段的传输使用相同的消息结构。
5.4.2 消息头
数据管理办法 第一章总则 第一条为适应集团信息化发展要求,充分利用数据资源为生产、经营、管理和决策服务，保证各类信息合理、有序流动和信息安全，确保集团信息化建设快速协调有序安全发展，根据国家有关法律法规以及《集团信息安全管理办法》（中平〔2013〕188号）、等规定，特制定本管理办法。 第二条本办法适用于集团各职能部室，直属和特设机构、专业化公司、事业部、区域公司及其所属各单位（以下简称各单位）。 第二章管理范围 第三条本办法管理范围包括：各单位与生产、经营、办公、安全等相关的应用系统和数据，以及为其提供支撑的基础设施资源、计算存储资源和办公终端资源等。 第三章组织机构和工作机制 第四条集团信息化领导小组是集团数据资源管理体系的最高层，负责审定集团有关数据资源管理的规章、制度、办法，负责审核有关标准、规范、重要需求等。集团信息化领导小组办公室（以下简称集团信息办）负责集团数据管理的监督、检查和考核，指导集团数据管理工作，查处危害集团数据安全的事件。各单位负责本单位数据的采集、传输、使用、安防、备份等管理
工作。中国平煤神马集团平顶山信息通信技术开发公司（以下简称信通公司）作为技术支撑及运维部门，负责集团数据中心的运维和运营工作。 第四章数据分级管理 第五条根据数据在生产、经营和管理中的重要性，结合有关保密规定，按照集团级应用系统和数据、厂矿级应用系统和数据、区队（车间）级应用系统和数据分别制定管理标准。 第六条集团级应用系统和数据，技术管理由集团信息办负责，业务管理由相关业务处室负责，运维管理由信通公司负责。厂矿级应用系统和数据由各单位信息管理部门管理，集团需要利用的管理数据和生产数据要同步上传到集团数据中心。区队（车间）级应用系统和数据由各单位信息管理部门管理和维护。 第五章数据标准管理 第七条集团信息办负责集团数据编码和接口标准的统一规划和标准制定，负责对集团及各单位应用系统的数据标准管理进行引导和考核。各单位新建应用系统应严格执行集团下发的数据编码和接口标准，在用应用系统应根据自身实际逐步按照集团标准进行完善。 第八条数据编码和接口标准应符合以下要求： （一）数据编码应能够保证同一个对象编码的唯一性及上下游管理规范的一致性；
附件4：数据交换接口规范 一、概述 计量器具检定数据交换接口采用Web service作为数据传输机制，是自包含、自描述（WSDL）、模块化的应用，由省局发布、定位、各技术机构通过web方式调用。接口基于标准的互联网协议，支持超文本传输协议(HTTP)和XML。与省局交换的数据都封装成XML格式的文件，传输前以GZIP格式将文件压缩，然后设置BASE64编码，最后在接收端将其解压，解析读取数据。 二、软件准备 JDK1.6，tomcat6.0，Web service相关包以及数据库。三、数据交换示意图 四、服务端接收数据过程 1、用户合法性校验：服务端在接收数据时同样需要进行用户合法性 校验，并返回信息。
2、数据封装：为方便数据传输和解析，客户端通过Web service交 换的数据需要封装成可扩展标记语言XML的规范，并严格按照此规范。 3、数据压缩：为提高数据的传输效率和减小传输的数据量，客户端 在传输之前需将数据以GZIP格式进行压缩，并设置BASE64位编码，以便基于HTTP传输。 4、对上传文件进行规范性校验：服务端在接收数据之前，校验客户 端数据是否按照XML规范要求，并按GZIP格式进行压缩，设置BASE64编码，否则返回不合法文件格式。 5、返回结果：服务端进行完校验，解析成功并反馈给业务系统后， 会反馈成功信息给客户端，如不成功则返回不成功。 五、客户端接收数据过程（与服务端接收过程类似。） 六、术语说明
THANKS !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
国家标准《信息技术会计核算软件数据接口》（征求意见稿） 编制讲明 一、任务来源 国家标准化治理委员会2002年下达的国家标准项目打算中，列入了《信息技术会计核算软件数据》（编号为20020389—T—424 ）；2004年国家标准化治理委员会又下达《关于调整信息技术会计核算软件数据国家标准打算项目的复函》（标委办函[2004]6号），明确由中华人民共和国审计署、中华人民共和国财政部作为主管部门，组织《信息技术会计核算软件数据》的起草单位和相关单位，承担《信息技术会计核算软件数据接口》国家标准的制定。 二、要紧工作过程 2002年3月上海市技术监督局制定了《信息技术会计核算软件数据接口规范》，并作为地点标准。2002年依照国家标准项目打算中编号为20020398—T—424的国家标准打算项目《信息技术会计核算软件数据》，上海市技术监督局组织相关单位和专家进行该标准的起草工作，于2003年底提出了《信息技术会计核
算软件数据接口规范》国家标准草案文本。 审计署依照工作需要，自1999年以来开展了“会计核算软件数据接口”方面的研究和实践。经国家电子政务治理委员会、国务院信息化工作办公室批准，审计署于2002年2月开始组织研究编写《会计核算软件数据接口》国家标准，于2003年底提出标准草案文本。 2004年2月，依照国家标准化治理委员会“标委办函[2004]6号”—“关于调整《信息技术会计核算软件数据》国家标准打算项目的复函”的精神，审计署计算中心召集上海《信息技术会计核算软件数据》标准起草组成员，审计署南京特派员办事处、南京审计学院等相关专家与人员，在北京对上述两个标准草案文本进行了深入细致的分析研究，综合整理提出了《信息技术会计核算软件数据接口规范（企业、事业单位）（草案稿）》。 2004年3月，依照国家标准化治理委员会关于“要符合国家标准撰写格式及语言规范；要使用数据元素表示；会计核算软件数据输出文件要有文本和XML格式”的要求，组织审计署计算技术中心、财政部会计司、审计署南京特派员办事处、信息产业部电子标准化所、用友公司、金算盘公司、浪潮公司等相关人员共同研究，编制出《信息技术会计核算软件数据接口（征求意见
{业务管理}数据业务管理平台接口规范分册
QB-GF-003-2003 移动数据业务管理平台(D S M P ) 接口规范 版本号：1.5.0 中国移动通信集团公司 发布 2003-1-31发布 2003-1-31实施 M o b i l e D a t a S e r v i c e M a n a g e m e n t P l a t f o r m I n t e r f a c e S p e c i f i c a t i o n
目录前言III 1 适用范围1 2 引用标准2 3 相关术语与缩略语解释4 4接口命名规范5 5 接口在网络中的位置6 6系统接口描述7 6.1 DSMP对外接口描述7 6.2接口消息实现8 7 字段类型说明8 8 DSMP接口定义8 8.1 DSMP与业务网关之间的接口(Sg接口)8 8.2 DSMP与BOSS系统接口(Mb接口)8 8.3 DSMP与SCP接口(Sscp接口)8 8.4 DSMP与客服/1860之间的接口(Sk接口)9 8.5 DSMP之间的接口(Sim接口)9 8.6 DSMP与SP之间的接口(Ma接口)9 8.6.1 DSMP与SP之间接口消息定义9 8.6.2 DSMP与SP之间接口消息体定义9 9 返回值的统一定义11
10 编制历史15 附录A 模式（schema）描述16 Schema字段描述16 附录B DSMP与SCP之间通信协议中共用的通用元素的定义17 附录C DSMP平台Web Services 数据类型定义17 附录D DSMP平台Web Services 接口定义和SOAP绑定19 1 DSMP平台Web Service接口设计和开发准则19 2 举例说明20 3 DSMP接口的WSDL定义23
监管报表数据报送接口规范修订历史纪录
一、销售机构、基金资金划付明细文件格式建议（J01） （一）报表格式 使用标准txt文件，文件内容格式如下(左侧数字表示行号)： 1.总记录数（不包括本行） 2.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| 3.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| （二）报表说明 用于表示基金销售机构与基金之间的实际资金划付。其中资金划付日期是指实际资金汇划的日期；交易确认日期是与指该笔资金划付相对应的基金交易的确认日期；交易申请日期是与指该笔资金划付相对应的基金交易的申报日期；业务类型是指基金交易业务代码，包括：认购（一次交易确认为120、二次交易确认为130）、申购122、定额申购139、赎回124、定额赎回163、强制赎回142、分红143。 对于三种特殊业务类型“交易申请日期”字段的说明。分红143业务：“交易申请日期”填写权益登记日；强制赎回142业务：“交易申请日期”填写交易确认日期的上一工作日（由于上工作日的赎回可能会和当日的强赎合并划款）；认购退款130业务：“交易申请日期”填写交易确认日期。 报送的实际资金划付数据是按照基金代码、业务类型进行
汇总的，即对于某个具体的资金划付日期，针对一只基金的某种业务类型，只申报一条汇总数据记录。 对于一种业务类型而言，只存在销售机构向基金划付金额或者只存在基金向销售机构划付金额。 基金代码---目前为6位编码，最长可扩展至30位。 业务类型---目前为3位编码，最长可扩展至30位。 登记结算机构代码--目前为8位编码，最长可扩展至30位。 （三）核对逻辑 中国结算每日将基金确认成功的交易数据按照基金代码、销售机构代码、业务类型进行汇总统计，得出销售机构各业务对基金应划入金额和应划出金额，用于与J01报表中的实际划付金额数据进行核对。中国结算汇总统计基金划入和基金划出金额的方法是：对认购业务，第一次确认（业务类型120）时统计的基金应收金额为：汇总每笔交易的确认金额全额；第二次确认（业务类型130）时统计的基金应付金额为：汇总每笔交易的（一次确认金额-二次确认金额+退回给投资人的利息）。 对申购（业务类型122）和定额申购（业务类型139）业务，统计的基金应收金额为：汇总每笔交易的（确认金额全额-代理费）。 对赎回（业务类型124）、定额赎回（业务类型163）、强制赎回（业务类型142）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得金额+代理费）。 对分红（业务类型143）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得现金红利金额）。
附件2 武汉市节能智慧管理系统 数据接口规范 武汉市发展和改革委员会 2013年12月
前言 为指导我市各级节能智慧管理系统建设，市发改委组织有关专家，以我国现行相关标准为依据，结合我市节能智慧管理系统建设、验收和运行管理要求，研究制定了本数据接口规范。 本规范包括主要用能单位上传数据接口标准规范和市区各级系统上传数据接口标准规范两部分，其中两部分包括了接口的标准应用范围、接口的实现、接口的要求、术语和定义和基本原则。 本规范由市发改委负责管理和解释。
目录 1. 主要用能单位上传数据接口规范 (5) 1.1标准应用范围 (5) 1.2术语和定义 (5) 1.3基本原则 (5) 1.4接口实现 (6) 1.4.1数据提供方 (6) 1.4.2数据接收方 (6) 1.4.3接口的实现方式 (7) 1.4.4传输方式 (7) 1.4.5传输协议 (7) 1.4.6传输过程 (7) 1.4.7编码原则 (8) 1.4.8接口的验证方式 (8) 1.4.9使用策略 (9) 1.5接口数据的要求及保障 (9) 2. 区分系统上传数据接口规范 (10) 2.1标准应用范围 (10) 2.2术语和定义 (10) 2.3基本原则 (10) 2.4接口实现 (11)
2.4.1数据提供方 (11) 2.4.2数据接收方 (12) 2.4.3接口的实现方式 (12) 2.4.4传输方式 (12) 2.4.5传输协议 (12) 2.4.6传输过程 (12) 2.4.7编码原则 (13) 2.4.8接口的验证方式 (13) 2.4.9使用策略 (14) 2.5接口数据的要求及保障 (14) 附录1 数据采集器身份认证过程和数据加密 (15) 附录2 数据采集器或子系统和市数据中心通信过程 (16) 附录3 数据传输的XML数据格式 (17)
中国财务软件数据接口标准(DOC7) 编者按:标准应该是衡量事务的准则。标准的制定一样都由国际/国家有关标准机构或行业主管部门完成。但一些行业的生产厂商为了爱护用户的投资,促进行业有序进展,也按照本行业的特点,联合起来制定了一些大伙儿认可并共同遵守的规范,这种做法在国外已被广泛采纳。随着中国改革开放的深入,国内一些行业的厂家也开始进行这方面的探究,本期我们刊登的《中国财务软件数据接口标准》确实是由该财务软件行业的民间组织——中国软件行业协会财务及企业治理软件分会制定的,起草者为闻名财务软件厂商深圳金蝶公司。 一、背景 目前,国内财务软件众多,它们采纳的数据库平台和数据库结构各不相同,不同财务软件之间的数据交换,因为数据库平台和结构不同而产生许多困难,几乎任意两个不同软件之间要实现数据传递都会存在专门的数据转换咨询题。烦琐的数据转换工作白费了大量人力和物力,同时也阻碍了财务软件产业的健康进展。国内财务软件的商业化差不多比较成熟,各财务软件公司都有一批用户。由于各种缘故,一些用户期望从一个软件交叉升级为另一软件。由于用户在旧软件上已做了大量的工作,必定期望升级后原有数据能移植到新的软件中,然而有些软件的数据文件通过加密或数据库结构未公布,要从中直截了当读取数据几乎不可能。为了爱护用户已付出的劳动,各财务软件需要提供一个标准的数据输入输出接口。如此,建立一个公用的数据交换标准是专门必要的。 用户在使用财务软件时,有一些需求通过财务软件本身是难以实现的,如:用户期望把会计报表通过电子表格软件处理输出为各种专门形式;另一些高级用户,则期望在其它治理软件中能取到财务数据。这些数据交换工作都需要有一个标准的数据接口来规范。财务会计通过长期的进展已形成一定的理论,财务会计工作也有规范可循,国内财务软件是在这些理论和规范的基础上开发出来的,各软件储存财务数据的模式也大同小异。财务数据要紧按会计科目、凭证、余额及发生额、报表几个部分分块储备,它们之间既
税控发票开票软件发票信息 数据接口规范V4.0 1概述 为进一步优化纳税服务，满足纳税人内部管理信息系统与增值税发票税控开票软件的衔接需要，国家税务总局下发了税控发票开票软件发票信息数据接口规范V1.0、V2.0、V3.0版。随着增值税发票管理新系统的全国推广和营改增的全面实施，公布的接口已经不能满足需要，现对该接口进行更新升级，形成V4.0版。 本接口规范适用于是增值税发票税控开票软件（金税盘版）与增值税发票税控开票软件（税控盘版）的商品编码版本（以下统一简称为税控发票开票软件），配合手工导入开具、自动导入开具和发票明细导出功能使用。 2接口说明 2.1待开发票信息导入接口 通过税控发票开票软件中的手工导入开具和自动导入开具功能，将待开发票的信息批量导入到税控发票开票软件，完成发票开具。 选择手工导入开具时，首先选择要导入的XML文件，再对导入发票信息逐张开具并打印发票。
选择自动导入开具时，首先设置文件存储路径和轮询时间。自动导入开具功能开启后，系统自动轮询指定路径下的XML文件，自动完成发票开具，并将开具结果写入指定文件目录。 2.2已开发票信息导出接口 通过税控发票开票软件中的发票明细导出功能，实现已开发票信息的批量导出，生成EXCEL文件或XML文件。 3接口定义 本接口规范内容包括待开发票信息导入接口和已开发票信息导出接口，发票类型为增值税专用发票、增值税普通发票、货物运输业增值税专用发票、机动车销售统一发票和二手车销售统一发票。3.1增值税专用发票和增值税普通发票 3.1.1修改说明 单据新增了Version节点，增加商品编码功能后的版本为2.0； 单据新增了Spbmbbh节点，增加商品编码功能后为税局下载的商品编码表版本号； 单据新增了Hsbz节点，用于区分营改增新增的5%不含税税率和中外合作油气田（原海洋石油）5%税率、1.5%税率、差额税； 单据商品明细中新增了Spbm（商品编码）、Qyspbm（企业商品编码）、Syyhzcbz（享受优惠政策）、Lslbz（零税率标识）、Yhzcsm
中国结算开放式基金新版系统管理人数据接口规范(TXT) 版本1.1 二○○九年九月
1. 总则 (4) 2. 术语定义 (4) 3. 基本要求 (8) 4. 数据接口 (10) 4.1. 信息格式 (10) 4.2. 接口文件名定义 (11) 4.3. TA支持业务 (13) 4.4. 业务数据项 (15) 4.4.1. 开户确认业务101 (16) 4.4.2. 销户确认业务102 (20) 4.4.3. 客户资料修改确认业务103 (21) 4.4.4. 撤销交易账号确认109 (25) 4.4.5. 变更交易帐户确认158 (27) 4.4.6. 认购业务数据项020 (27) 4.4.7. 认购结果业务数据项057 (29) 4.4.8. 申购业务数据项022 (31) 4.4.9. 定期定额申购业务数据项039 (34) 4.4.10. ETF一次申购业务数据项091 (37) 4.4.11. ETF二次申购业务数据项092 (39) 4.4.12. 赎回业务数据项024/定期定额赎回业务数据项063 (42) 4.4.13. ETF一次赎回业务数据项093 (46) 4.4.14. ETF二次赎回业务数据项094 (48) 4.4.15. 预约赎回业务数据项025 (51) 4.4.16. 撤预约单业务数据项053 (53) 4.4.17. 转托管业务数据项026/028 (55) 4.4.18. 转托管入业务数据项027 (56) 4.4.19. 设置分红方式业务数据项029 (58) 4.4.20. 基金转换业务数据项036 (59) 4.4.21. 份额冻结业务数据项031 (62) 4.4.22. 份额解冻业务数据项032 (64) 4.4.23. 非交易过户业务数据项033 (65) 4.4.24. 强增业务数据项044 (67) 4.4.25. 强减业务数据项045 (68) 4.4.26. 开通定期定额协议业务数据项059 (70) 4.4.27. 撤销定期定额协议业务数据项060 (71) 4.4.28. 变更定期定额协议业务数据项061 (72) 4.4.29. 认购业务数据项120 (74) 4.4.30. 认购结果业务数据项130 (75) 4.4.31. 申购业务数据项122 (78) 4.4.32. 定期定额申购业务数据项139 (81) 4.4.33. ETF一次申购业务数据项191 (83) 4.4.34. ETF二次申购业务数据项192 (85) 4.4.35. 赎回业务数据项124/定时定额赎回163 (88) 4.4.36. 强制赎回业务数据项142 (91)
1 具体需求 功能需求 功能需求1 对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成： a．引言 描述的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能意图的由来 和背景。 b．输入 1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、 有效输入范围（包括精度和公差）； 2)操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的 位置。例如：当打印检查时，要求操作员进行格式调整； 3)指明引用接口说明或接口控制文件的参考资料。 c．加工 定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明： 1)输入数据的有效性检查； 2)操作的顺序，包括事件的时间设定； 3)响应，例如，溢出、通信故障、错误处理等； 4)受操作影响的参数； 5)降级运行的要求； 6)用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）； 7)输出数据的有效性检查。 d．输出 1)详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关
系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息； 2)有关接口说明或接口控制文件的参考资料。 此外，对着重于输入输出行为的系统来说，需求说明应指定所有有意义的输入、 输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以 根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。 功能需求2 ．．．．．． 功能需求n 外部接口需求 用户接口 提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求： a．对屏幕格式的要求； b．报表或菜单的页面打印格式和内容； c．输入输出的相对时间； d．程序功能键的可用性。 硬件接口 要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
1 前言 《企业信用信息基础数据库数据接口规》（简称“数据接口规”）规定了企业信用信息基础数据库与外部系统进行信息交换时应遵循的有关信息格式和数据管理规定，本文档分为六部分。 前言简介本规各部分的容。 报文规规定了本规中报文的基本概念、设计原则、数据处理原则、文件命名原则、报文文件的结构和种类。 数据采集要求规定了公积金管理中心提交数据的围、频率以及文件传送方式。 公积金信息采集报文和公积金信息删除报文中规定了公积金中心向企业信用信息基础数据库报送采集报文和删除报文的具体数据项以及对数据项的描述和约束。 公积金信息反馈报文规定了企业信用信息基础数据库向公积金中心反馈容的具体数据项以及对数据项的描述和约束。 附录包含公积金信息采集接口规的代码表、数据校验规则。 本接口规适用于与企业信用信息基础数据库进行报文交换的公积金机构及公积金部门的数据处理。文档的主要读者有：拟建系统用户、系统设计人员、系统编码人员、项目经理、系统测试人员、项目监理人员。 2 报文规 2.1术语和定义 下列术语和定义适用于本规。 2.1.1报文 由报文头、报文体构成的，按照一定规则组合起来的数据集合体。 2.1.2报文文件 包含报文的数据文件。 本规中报文文件与报文是一对一的关系。 2.1.3段 一个已标识、命名和结构化的、在功能上相互关联的复合数据元和/或独立数据元的集合。段有各自固定的长度。 本规中段为基础段。 2.1.4信息记录 数据采集的基本信息单位，包含报送机构一笔业务的有关数据。 本规中的信息记录由基础段组成。 2.1.5报文头 每个报文必须包含且只包含一个报文头，报文头表示一次数据采集的开始，该部分给出本次采集数据的信息提要。 2.1.6报文体 报文体是数据采集报文的主体容，报文体部分可包含一种或多种不同类型的信息记录，最后一条信息记录结束即为报文结束。 信息记录之间用一个回车换行符（“﹨r﹨n”或“﹨n”）分隔。 2.1.7信息记录 此信息记录由基础段组成。 每个信息记录包含且仅包含一个基础段。 信息记录的容中不允许存在回车换行符（“﹨r﹨n”或“﹨n”）。 2.1.8基础段 基础段是由固定数据项按照一定次序排列组成的信息集合体。 2.2设计原则
软件开发管理办法 修订记录 版本编号修订日期主要修订摘要 审核记录 审核人员属于部门审核日期 第一章总则 第一条为规范公司的开发管理流程，使各开发项目的管理进行标准化管理，特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象：软件开发管理人员，软件开发人员，软件维护人员，系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责： 第五条软件开发人员职责： 第六条软件维护人员职责： 第七条系统管理人员职责： 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期，需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境，便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴，是系统正式运行，提交给各业务科室的正式环境，包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境，包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境，包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后，提交发布版本到测试环境中，由专门的测试人
员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离，保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程，分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析，确认软件的市场需求 2.在调查研究的基础上进行可行性研究，写出可行性报告 3.评审和审批，决定项目取消或继续 4.若项目可行，制订初步的软件开发计划，建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型，与用户共同研究，直到用户满意 4.对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可 有相应的缓冲时间） 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划
上海证券交易所技术文档 IS120 上海证券交易所行情网关BINARY数据接口规范 0.3240版 上海证券交易所 二○一九年十二五月
修订记录 2018-03-09，0.10版，文档创建。 2018-03-25, 0.20版，根据原有文件接口进行字段及内容调整。 2018-07-11，0.30版，根据反馈意见调整部分说明、调整价格精度、增加成交笔数及期权虚拟匹配数量。 2018-07-25，TradingPhaseCode闭市集合竞价相关调整。 2019-01-10，0.31版，增加债券回购延长对市场状态消息字段的说明。 2019-01-25, 0.32版，增加盘后固定价格交易的行情接口说明，调整国债预发行接口字段取值。 2019-03-04，调整盘后固定价格行情的产品状态取值。 2019-12-05，0.40版，原内容移入第二章，增加章节描述通过行情网关接收的文件及外部转发数据。
目录 1引言 (5) 1.1名词释义 (5) 2BINARY实时行情 (6) 2.1会话机制 (6) 2.1.1消息序号 (7) 2.1.2会话安全 (7) 2.1.3建立行情会话 (7) 2.1.4行情数据发布 (7) 2.1.5关闭行情会话 (7) 2.1.6心跳 (7) 2.1.7行情网关主动关闭行情会话的情况 (8) 2.2协议介绍 (8) 2.2.1字段说明 (8) 2.2.2BINARY消息头 (9) 2.2.3BINARY消息尾 (9) 2.3会话消息 (10) 2.3.1登录消息（MsgType=S001） (10) 2.3.2注销消息（MsgType=S002） (10) 2.3.3心跳消息（MsgType=S003） (11) 2.4应用消息 (12) 2.4.1市场状态消息（MsgType=M101） (12) 2.4.2行情快照消息（MsgType=M102） (13) 3文件接收 (20)
增值税发票税控开票软件 数据接口规范V3.0 1概述 为进一步优化纳税服务，满足纳税人内部管理信息系统与增值税发票税控开票软件（以下简称开票软件）的衔接需要，国家税务总局下发了开票软件数据接口规范V1.0和V2.0版。随着增值税发票管理新系统的全国推广和营改增的全面实施，公布的接口已经不能满足需要，现对该接口进行更新升级，形成V3.0版。 本接口规范适用于是开票软件（金税盘版）与开票软件（税控盘版）的商品编码版本，配合手工导入开具、自动导入开具和发票明细导出功能使用。 2接口说明 2.1待开发票信息导入接口 通过开票软件中的手工导入开具和自动导入开具功能，将待开发票的信息批量导入到税控发票开票软件，完成发票开具。 选择手工导入开具时，首先选择要导入的XML文件，再对导入发票信息逐张开具并打印发票。 选择自动导入开具时，首先设置文件存储路径和轮询时间。自动导入开具功能开启后，系统自动轮询指定路径下的XML文件，自
动完成发票开具，并将开具结果写入指定文件目录。 2.2已开发票信息导出接口 通过开票软件中的发票明细导出功能，实现已开发票信息的批量导出，生成EXCEL文件或XML文件。 3接口定义 本接口规范内容包括待开发票信息导入接口和已开发票信息导出接口，发票类型为增值税专用发票、增值税普通发票、货物运输业增值税专用发票和机动车销售统一发票。 3.1增值税专用发票和增值税普通发票 3.1.1修改说明 单据新增了Version节点，增加商品编码功能后的版本为2.0； 单据新增了Spbmbbh节点，增加商品编码功能后为税局下载的商品编码表版本号； 单据新增了Hsbz节点，用于区分营改增新增的5%不含税税率和中外合作油气田（原海洋石油）5%税率、1.5%税率、差额税； 单据商品明细中新增了Spbm（商品编码）、Qyspbm（企业商品编码）、Syyhzcbz（享受优惠政策）、Lslbz（零税率标识）、Yhzcsm （优惠政策说明），详细内容请查看接口规范中相关说明； 单据只允许对单行商品进行折扣，折扣行紧挨被折行之后，折
电子数据管理制度 第一条 为规范审计项目所采集的电子数据（以下简称电子数据）的保护、管理，维护电子数据安全，保守秘密，制定本制度。 第二条 计算机应用环境要保持清洁、安全，禁止在计算机应用环境中放置易燃、易爆、强腐蚀、强磁性等有害计算机设备安全的物品。 第三条 非本单位技术人员对我单位的设备、系统等进行维修、维护时，必须由本单位相关技术人员现场全程监督。计算机设备送外维修，须经有关部门负责人批准。 第四条 严格遵守计算机设备使用、开机、关机等安全操作规程和正确的使用方法。任何人不允许带电插拨计算机外部设备接口，计算机出现故障时应及时向领导或计算机审计管理中心报告，不允许私自处理或找非本单位技术人员进行维修及操作。 第五条 计算机应设置密码。密码设置应具有安全性、保密性，不能使用简单的代码和标记。如发现或怀疑密码遗失或泄漏应立即修改。 第六条 重要数据需要备份时，备份数据必须异地存放，并明确落实异地备份数据的管理职责。 第七条 计算机要定期杀毒，不准擅自安装其它软件、不准使用来历不明的载体（包括U盘、光盘、移动硬盘等）。 第八条 被审计单位和相关单位提供的原始电子数据，按其原有的秘密种类和等级保护管理。不同秘密种类和等级的电子数据管理、使用的条件和环境，应当符合国家和上级部门的有关保密规定。 第九条 有关单位或人员需要调阅电子数据的，应逐级申请，领导批复后方可使用，使用者负有保密义务。有关单位或人员利用电子数据进行科研、培训、宣传等活动的，不得违反国家和上级部门的有关保密规定。 第十条 调阅电子数据人员调离岗位、审计项目结束或者审计组长认为应该交回或删除电子数据的其他情况，调阅电子数据的单位或人员须马上交回或删除电子数据，不准私自留存。 第十一条 调阅电子数据人员有下列违反本规定的情形之一的，单位采取责令改正错误、书面检查、通报批评、行政处分等处理措施，追究直接责任人员的责任： （一）遗失存储设备、介质，造成电子数据损失的； （二）擅自毁弃、藏匿、删除电子数据，损害信息资产完整性的； （三）擅自留存或不及时移交应当移交的电子数据并造成不良后果的； （四）违规利用电子数据的； （五）其他未按规定管理、使用电子数据并造成不良后果的情形。 违反本规定，造成泄密的，按照党纪、政纪和刑法的有关规定，追究相应责任。 第十二条 国家保密工作部门和上级部门对电子数据的保密管理另有规定的，按其规定执行。
用友集团主数据标准管理办法（试行） 签发人: 王家亮 签发时间: 2014年06月16日 时效: 自发文之日起生效 授权: 全体员工 第一章总则 第101条为加强集团信息管理标准化，明确用友主数据分类标准及制定的管理机构、协作机构，特制订本管理办法。第102条本办法适用于集团本部、股份公司（含下属分支机构）、控股子公司（含下属分支机构）、集团直属业 务中心，以下均简称"成员机构"。 第103条释义 a)主数据（Master Data简称MD） 在企业各系统中交互共享、表示实体对象的基准数据。 b)主数据管理(Master Data Management简称MDM) 保证系统之间主数据的实时性、完整性和有效性的一组 约束和方法。 第二章主数据标准管理 第201条管理原则 a)标准统一 1.主数据标准包括数据名称、分类、编码、主要提供 机构、应用范围及对象、数据主要结构、各字段类
型及含义、数据使用的方法、输入输出关系、新旧 数据标准对照关系等。 2.标准制定考虑全集团所有业务类型的需要，同一主 数据在各系统中名称、编码、分级分类、数据结构 相同，确保数据衔接传递及归集分析规范化、标准 化。 3.主数据标准是各信息系统使用、开发、升级、整合 统一遵循的法则，确保数据描述的一致性和科学 性，避免歧义及理解偏差。 4.主数据标准是公司审核各信息平台的重要依据和评 价方法，凡未严格遵循及执行标准的系统，公司有 权利和义务终止其运行并进行整改。 b)主数据标准与业务流程分离，主数据标准不受业务流程 变化影响。 c)分层归口管理 1.根据主数据特性及部门职责，分层划分主数据标准 的归口管理部门（或人员）。 2.集团级部门牵头组建小组制定主数据标准与规范。 3.子公司（含业务部门）参与制定标准规范并落实执 行。 4.最终用户（主数据归口管理人员）进行主数据操作 实现。
污染源在线自动监控系统数据传输和接口标准技术规范FIX 超时重发机制： 请求回应的超时，在一个请求命令发出后在规定的时间内未收到回应，认为超时。超时后重发，重发规定次数后仍未收到回应认为通讯不可用，通讯结束。超时时间根据具体的通讯方式和任务性质可自定义。超时重发次数根据具体的通讯方式和任务性质可自定义。 执行超时 请求方在收到请求回应（或一个分包）后规定时间内未收到返回数据或命令执行结果，认为超时，命令执行失败，结束。缺省超时定义表（可扩充）： 所有的通讯包都是由ACSII码字符组成(CRC校验码除外)。 通讯包结构组成：
系统编码表（可扩充）（GB/T16706-1996）见《环境信息标准化手册》第一卷第236页
执行结果定义表（可扩充） 命令列表（可扩充）
附录A：循环冗余校验（CRC）算法 CRC校验（Cyclic Redundancy Check）是一种数据传输错误检查方法，CRC码两个字节，包含一16位的二进制值。它由传输设备计算后加入到消息中。接收设备重新计算收到消息的CRC，并与接收到的CRC 域中的值比较，如果两值不同，则有误。 CRC是先调入一值是全“1”的16位寄存器，然后调用一过程将消息中连续的8位字节各当前寄存器中的值进行处理。仅每个字符中的8Bit数据对CRC有效，起始位和停止位以及奇偶校验位均无效。 CRC校验字节的生成步骤如下： ①装一个16位寄存器，所有数位均为1。 ②取被校验串的一个字节与16位寄存器的高位字节进行“异或”运算。运算结果放入这个16位寄存器。 ③把这个16寄存器向右移一位。 ④若向右（标记位）移出的数位是1，则生成多项式1010 0000 0000 0001和这个寄存器进行“异或”运算；若向右移出的数位是0，则返回③。 ⑤重复③和④，直至移出8位。 ⑥取被校验串的下一个字节 ⑦重复③~⑥，直至被校验串的所有字节均与16位寄存器进行“异或”运算，并移位8次。 ⑧这个16位寄存器的内容即2字节CRC错误校验码。 校验码按照先高字节后低字节的顺序存放。
XX数据标准管理办法 第一章总则 第一条为规范我行数据标准管理工作，明确管理职责，推动数据标准在业务领域和技术领域的应用，提高我行整体业务运行和管理效率，提升IT实施能力，特制定本办法。 第二条本办法适用于我行及分支机构所有与数据标准有关的管理活动，包括数据标准的制定、评审、发布、执行、变更及复审等工作。 第三条本办法所称数据标准，是指针对我行各种重要数据制定的规范性文件，以确保这些重要数据在全行内外共同使用和交换中的一致性和准确性，是实施数据治理、提升数据质量的重要基础。 第四条本办法所称重要数据，是指我行跨业务部门或跨系统多处使用的数据。 第五条数据标准按照数据加工程度划分为基础类数据标准和分析类数据标准两大类型，本办法主要针对基础类数据标准。 第六条本办法所称基础类数据，是指日常业务开展过程中所产生的具有共同业务特征的基础性数据，可进一步划分为不同的数据主题，包括客户、产品、协议、交易、资产、财务、地址、组织、渠道、营销十个数据主题。 第七条数据标准内容可以划分为业务和技术两部分：
（一）业务规范是指从业务层面对数据的统一定义，包括数据项的业务涵义和数据项处理加工的业务规则等； （二）技术规范是指从技术实现层面对数据的统一规范和定义，包括字段长度、数据格式等。 第八条XX银行数据标准制定遵循以下原则： （一）以业务为导向。基于我行实际业务情况制定数据标准，并根据业务需求分阶段推进制定工作。 （二）全面性及完整性。数据标准立足于我行整体业务架构，覆盖未来所有经营范围内的相关业务。 （三）前瞻性及科学性。既满足现阶段业务需求，更应结合国内外先进经验，考虑未来我行业务类型逐步发展所带来的数据标准需求。 （四）遵循外部标准。充分遵循各类成熟的外部标准，并按照国家标准/国际标准、金融行业标准、监管报送要求的顺序进行采纳。 第九条我行数据标准信息项及代码的选择遵循以下准入原则： （一）已有的内外部成文规范纳入数据标准，包括：行业、国家或国际组织正式发布的数据标准；监管部门管理指引、监管统计规范等已经明确提出要求的相关数据规范；行内已经发文进行明确的相关数据规范。 （二）未有外部成文规范，但我行当前已经在广泛使用
登记结算数据接口规范（上市公司版V2.9） 二零一五年一月
版本修订历史
目录 前言 (4) 一、概述 (4) 二、数据文件命名规则 (4) 三、基本数据说明 (4) 第一章发送数据接口规范 (7) 一、中国结算上海分公司向上市公司发送的数据清单 (7) 二、中国结算上海分公司向上市公司发送的数据明细说明 (8) 1)s1(上市公司月中/末大股东名册数据) (8) 2)s1c(上市公司月末大股东名册自助补发数据) (9) 3)s2d（上市公司前N名股东名册自助发送数据） (9) 4)s2e（上市公司权益日全体股东名册自动发送） (10) 5)s3(上市公司红利退款明细数据) (11) 6)s4(人工受理的A股全体股东名册) (12) 7)s5(融资融券和转融通担保证券账户的明细数据) (13) 8)s6(股息红利差异化计税补缴明细数据) (14) 9)s7(全体股票激励期权持有人数据) (16) 10)s8(股票激励期权持有变动明细数据) (16) 11)s9(股票激励期权基本信息数据) (17) 12)s10(A股合并普通账户和信用账户前N名名册) (18)
前言 一、概述 为了进一步规范中国证券登记结算有限责任公司上海分公司（以下简称中国结算上海分公司）与上市公司之间的登记结算数据接口，确保登记结算数据处理的正确性，特编写本登记结算数据接口规范文档。本文主要针对中国结算上海分公司发送和接收的上市公司的各类登记结算数据进行详细的说明。 二、数据文件命名规则 数据文件名: =：前缀 + 标识 + “.” + 后缀 前缀：=：s1|s1c|s2d|s2e|s3|s4|s5|…… 标识：=: 证券代码[yyyymmdd][其它]，其中[yyyymmdd]和[其它]为可选内容，参见各文件的数据库名说明。 后缀：=：mdd m：=：1，2，3，……，9，a，b，c dd：=：01，02，03，……，31 目前中国结算上海分公司发送和接收的数据文件，均采用FOXPRO2.5下的标准DBF格式。为了减少数据通讯量，中国结算上海分公司发送的数据文件都经过ZIP软件压缩后发送至PROP电子信箱中。 发送数据文件的命名规则为：“前缀” + “标识” + “.mdd”；其中mdd表示日期，其中m表示月，（m=1,2,3,…,9,a,b,c），dd表示日。例如2001年12月31日发送的600001上市公司的s1数据的数据名称为“s1600001.c31”。 三、基本数据说明 1、股票的数量单位为“股”、基金的数量单位为“份”；债券、融券数量单位为“一元”面 值数量；金额单位为“元”。 2、证券类别（ZQLB）意义如下： GZ 固定收益类 JJ 基金 PT 无限售流通股 PG 配股 PS 配售股
福建万鸿纺织有限公司信息系统数据接口管理办法 第一章总则 第一条为了规范公司信息系统数据接口申请、变更及故障处置管理流程，确保公司信息系统接口数据传递安全、准确、稳定、高效，特制定本管理办法。 第二条信息系统数据接口申请与变更是指因系统架构变化或者管理需求延伸时，需要增加或者修改现有信息系统数据接口的各种业务需求。 第三条信息系统数据接口故障处置是指信息系统运行过程中所出现的各种接口故障问题处理。 第四条本管理办法适用于ERP系统、OA、财务系统、外网网站等信息系统（下面简称信息系统）与其他生产、管理、控制系统（下面简称其他系统）之间的数据接口管理。 第二章管理职责及分工 第五条信息部职责 信息部是公司信息系统数据接口的归口管理部门，负责组织制定公司信息系统数据接口架构方案；负责审批各单位信息系统或者其他系统数据接口申请与变更并组织数据接口谈判、实施、测试与上线；负责收集与归档信息系统维护单位制定或者变更的接口文档；负责组织处置各类信息系统数据接口故障；负责信息系统或者数据接口故障时以及故障
后通知接口对应其他系统所属专业对管辖系统数据接口进行相应处置并组织数据追单；负责信息系统或者数据接口检修前、后通知相关其他系统所属专业对管辖系统数据接口进行相应处置并组织数据追单；负责接受相关其他系统所属专业关于其他系统检修、故障的通报，并组织信息系统维护单位对数据接口进行相应的处置。 第六条各相关单位职责 负责向信息部申请与变更本单位其他系统与信息系统的数据接口需求；负责协调其他系统数据接口实施方与信息部相关专业以及信息系统维护人员数据接口谈判、实施、测试与上线；在其他系统或者数据接口检修前后，负责通报信息部相关专业对相应信息系统数据接口进行处置并组织数据追单；在本单位其他系统或者数据接口故障后以及故障恢复后，负责通报信息部相关专业对相应信息系统数据接口进行处置并组织数据追单；负责接受信息部相关专业关于信息系统或者数据接口检修、故障的通知，并组织本单位系统维护人员对相关其他系统数据接口进行相应处置。 第七条信息系统维护单位职责 负责参与公司信息系统数据接口架构方案的制定，负责配合公司各单位信息系统数据接口需求申请与变更的谈判、实施、测试与上线，负责信息系统数据接口需求申请与变更实施后接口文档的制定与变更，并将数据接口新增与变更文