企业应用集成之数据集成规范
单位：
地址：
邮编：
电话：
传真：
日期：
修订文档历史记录
目录
第一章前言 (3)
1.1 概述 (3)
第二章通用的约定 (4)
2.1 数据输出的内容 (4)
2.1.1 枚举信息 (4)
2.1.2 企业信息 (4)
2.1.3 业务报表 (5)
2.1.4 报表样式 (6)
2.1.5 层级信息 (6)
2.2 业务子系统称谓与编码的约定 (6)
2.3 委处室与业务编码的约定 (7)
2.4 数据输出方式的约定 (8)
2.4.1 输出类型 (8)
2.4.2 输出位置 (9)
2.4.3 输出文件的命名 (11)
2.4.4 输出数据的时机 (12)
2.5 文件格式的约定 (12)
2.6 时间格式的约定 (13)
2.7 时间类型的约定 (13)
第三章数据集成接口格式 (15)
3.1 枚举信息的输出格式 (15)
3.1.1 枚举信息格式说明 (16)
3.1.2 枚举信息的输出例子 (18)
3.2 企业基本信息的输出接口 (19)
3.2.1 企业基本信息的内容 (19)
3.2.2 输出文件格式规范 (20)
3.2.3 企业属性的类型 (22)
上海市国有资产监督管理信息系统数据集成规范
3.2.4 企业信息输出文件示例 (24)
3.3 层级信息的输出格式 (26)
3.3.1 层级格式的说明 (28)
3.4 业务报表的输出接口 (29)
3.4.1 输出文件命名规范 (29)
3.4.2 数据文件结构与报表分区 (30)
3.4.3 数据报表的关联关系 (31)
3.4.4 数据文件元素的层次 (33)
3.4.5 单元格的数据类型 (34)
3.4.6 二进制单元格的处理 (35)
3.4.7 枚举型单元格的处理 (35)
3.4.8 附报文件的处理 (36)
3.4.9 报表数据的输出文件格式 (36)
3.4.10 报表数据输出文件示例 (42)
3.4.11 独立上报文件的处理 (47)
3.5 报表样式的输出格式定义 (47)
3.5.1 样式文件的元素结构图 (52)
3.5.2 样式文件表达式定义 (52)
附录I 企业基本信息统计项列表 (54)
附录II 枚举信息的格式定义enum.xsd (55)
附录III 企业信息的格式定义orginfo.xsd (58)
附录IV 报表数据的格式定义report.xsd (62)
附录V 报表样式的格式定义report_style.xsd (71)
附录VI 层级信息的格式定义hierarchy.xsd (75)
第一章前言
1.1 概述
地址：山东中路337号邮编：200001 电话：8621－6351 6236 传真：8621－6351 7610
第二章通用的约定
2.1 数据输出的内容
业务子系统分别负责为委的不同处室收集业务数据，然后按照统一约定的格式将数据以XML文件的方式输出，提供给监管系统。监管系统需要收集两种信息：企业基本信息、与业务数据报表，其中业务数据报表涉及到所有的集成子系统，而企业信息则只来自一个特定的业务系统。
2.1.1 枚举信息
有些报表的科目（单元格），其取值来自于枚举项。在导出报表数据时，将会直接导出科目值，这样虽然报表值没有错，但枚举信息却不完整了，所以需要事先将所有的枚举信息统一导出。
枚举信息包括枚举类型，以及每个类型下的枚举项，此信息只需导出一次，如果枚举信息没有变化，以后不需要重复导出。
举个例子：如果报表中有一个科目叫“企业经营类别”，并且该项的值只能从一下四个中选择一个：“私营企业”、“集体所有制企业”、“股份制企业”、“其他”。则“企业经营类别”就是一个枚举类型，此类型具有四个枚举项，分别为：“私营企业”、“集体所有制企业”、“股份制企业”、“其他”。
各个子系统都需要输出此文件，没有枚举信息的可以填空元素。
2.1.2 企业信息
业务系统在实现企业数据填报的时候，都会将企业的基本信息作为报表封面。监管信息系统归纳整理了所有业务子系统的企业基本信息，并汇总形成一个企业基本属性的列表，有关这些基本属性的内容请参考文档《上海市监管信息系统企业基本信息说明》。
为配合应用集成，截止到试运行版本的需求，企业基本属性还需补充一些统计分类信息，这些信息参见附录的列表。
此文件只与“收集平台”或“层级查询”子系统有关。
各业务子系统需要输出本系统中最主要的业务报表。业务报表是由子系统采集的业务数据，各个子系统会按照委的要求提供各种“表格”供企业来填报数据，每种“表格”的填报结果都将产生一个报表。这里的“表格”是一种广义上的说法，并不局限于一张传统的表格，比如，在任何子系统中，只要有界面提供了一组域供用户填写数据，而且此数据最终会提交到委，则用户所填入的这组数据就形成了一张报表。
业务报表的概念与各个子系统的数据库结构可能并不一致。在有的子系统中，通常使用关系数据库的一张表（Table）来存储实体信息，一个实体就是一条记录，不能将整张实体表（Table）中的所有记录当成一张报表，而是每个实体就是一张报表。
有的报表可能会带有附件，附件是一组文件，文件的长度不限。对于文件附件，则直接输出此文件，不需要做任何加工处理。但是，输出文件必须与其所附的报表输出的XML文件处在相关位置（附件可与报表文件处于同一目录或报表文件所在目录的子目录）。比如，子系统中有报表X，此报表具有三个附报文件（a、b、c），则子系统将会输出共四个文件：x.xml、a、b、c，假如x.xml 文件位于目录k，则文件a、b、c可位于目录k或者k下面的子目录，最终x.xml 报表文件中将包括要输出的附报文件的控制信息，其中就含有附报文件的相对路径与文件名。
有时候，企业需要直接上报某些特定的文件，这些文件可能并不作为任何报表的附报文件存在，文件可以是任意格式，比如.doc或.xls文件。对于单独上报的文件，子系统需要输出一个额外的xml描述文件，我们可以将此描述文件看作一个空的报表文件，而将上报文件看作其附报文件。
子系统承担着委处室的业务功能，其业务流程仍然在子系统中进行，子系统导出的所有数据应该是走完了业务流程的结果数据（已审核过的数据），比如，对于“法人治理信息系统”，它所输出的数据应该通过了委审核后的数据。
各个子系统都需要输出此文件。
为满足原表展现的用户需求，导出的数据报表需要在“监管信息系统”中按照原表样式展现出来，这需要各子系统输出报表的样式。对于每种不同格式的报表，其数据有多分，但样式只需输出一份。
各个子系统都需要输出此文件。
2.1.5 层级信息
层级信息只与“层级查询”子系统有关。主要用来输出不同统计口径下的企业层级信息。
仅“层级查询”子系统需要输出此文件。
2.2 业务子系统称谓与编码的约定
目前，门户需要集成的业务子系统比较多，为便于沟通与程序间的交流，我们将业务子系统的名称统一起来，并且使用统一的编码来代表不同的子系统。
业务子系统的编码如下：
2.3 委处室与业务编码的约定
各个业务子系统一般会侧重于服务委的某些业务处室，我们将委的各业务处室的名称统一起来并做编码，便于门户与子系统的交流。
委的业务处室以及编码的约定如下：
该表列出了准备集成的五个业务子系统所涉及到的委处室称谓与编码，该表将随监管信息系统功能的不断完善而逐步补充完整。
2.4 数据输出方式的约定
各子系统原有的界面、业务操作均可维持不变。为配合监管系统的数据集成，实现数据交换的对接，需要增加一个数据输出功能。新功能可以通过增加菜单来体现，具体实现方式由子系统自行决定。
2.4.1 输出类型
数据导出方式必须满足下列要求之一：按照时间段输出、更新输出、自动增量输出。其中按照时间段输出、更新输出为强制要求，自动增量输出为可选要求。
子系统可以将所采用的输出方式标示在配置文件中。
●按照时间段的数据输出
用户可选择一个时间段（比如一个年度：2008年），子系统能将发生在该时间段内的、系统中所有企业的所有数据批量输出来，包括该企业的下属企业，只要是发生在此时间段内的数据，都批量输出来。
用户可选择的时间仅限于年度。输出程序运行时，可给出一个年度时间列表供用户选择，它列出了系统中所有历史数据的时间跨度，以年度为单位。
●更新输出
更新输出的数据一般是上次已经输出过了，这次可能发生了更改，需要重新输出。更新输出的数据在导入时，一般需要按照一定的条件在目的库中做删除操作，将原有的记录直接删除掉，然后再插入新的记录。
●增量输出
增量数据的自动输出要求能在监管系统的日常运行中周期性地输出子系统中新录入的结果数据，其周期与起始时间可作为参数来配置，也可以每次综合结果数据时自动触发执行。各子系统需要内部定义计数器来记录最近输出数据的时间戳，以确保下次只输出新增的数据。
如果使用配置起始时间与周期，则必须满足以下条件：起始时间一旦配置完成，并且只要执行过一次自动增量输出，则起始时间就不再可配置了，用户只能调整周期。另外，无论是否到达周期执行点，用户都可以手工触发运行增
量数据的输出功能。
增量数据输出所产生的数据可能包含多家企业单位，输出结果的文件与目录结构与带参数的数据输出保持一致。
2.4.2 输出位置
监管信息系统的数据集成发生在委内网中。在委内网，将设置一个公用的文件服务器，通过网络共享，所有的业务系统能将数据报表批量导出并存储在文件服务器上的指定位置。
所有业务系统的输出数据将存放在统一的文件服务器上，具有同一个起始位置，通过使用不同的子目录来形成不同的路径。假设起始位置为
尽管各业务子系统可能有各种存在形态：单机版、C/S版、B/S版，它们可能分布在受监管企业的不同部门、或者安装部署在委外网环境。无论它以什么形态存在，所有的业务系统都在委内网提供了安装或部署，各企业使用子系统录入数据，最终依靠网络或存储介质将数据向委提交，委的工作人员会将数据转移到内网的业务系统中。
输出数据按照企业分类，存放在一个目录结构中。输出数据的存储目录结构约定如下：
首先，以此企业的企业代码创建一个目录，并作为输出数据的根目录，我们称之为“企业目录”，在企业目录下创建一个名为DATA的子目录，该企业的报表数据则以DATA目录为根目录来存放。对于一家企业，在其DATA目录下，先按照年度创建一个年份子目录，在此年分目录下，如果有多套报表的（比如有财务预算，财务决算，每月的财务快报等），则需在此年分目录下用报表类名分别创建子目录，而属于该类的报表文件则存放在此子目录中，如果同一类报表还细分为不同的种子类（比如财务报表的1表、0表、9表等），则在报表类名下再建ID子目录来区分。
所有企业目录并行放置在子系统的根目录下。
下面用个例子来详细说明输出数据的文件与目录结构。例子中的材料属于假想情况，仅用来辅助描述子系统输出数据时的文件与目录结构。
比如，企业代码“1111111”是一家集团企业；其下属企业有“22222228”与“222222226”两家二级企业；而“22222228”下面还有一家“333333456”作为三级企业。假设用户选定了2007这个时间年度，在该年度，这四家企业都填报了：财务预算、财务决算、以及9月份的财务月报。对于此种情形，子系统输出数据的文件与目录结构示意如下：
2.4.3 输出文件的命名
配置文件对每个子系统只有一份，统一命名为exp_conf.xml，放在子系统输出的根目录下，比如：
枚举信息对每个子系统只有一份，统一命名为enum.xml，放在子系统输出的根目录下，比如：
企业信息，一次只需输出一个文件，所有企业都在这个文件中，每家企业都是文件中的一个
业务报表按照分类存储在子系统根目录下层的特定位置处，文件名则为报表名加上xml后缀。比如：<子系统存储的根目录>/<企业代码>/DATA/<年份>/<报表类别>/<可能的报表ID>/报表名称.xml
报表样式对每张报表只需要一份，所有企业将通用同一份样式，除非报表采用了新的格式。报表样式的输出文件存放在：<子系统存储的根目
录>/STYLE/<年份>/<报表类别>/报表名称.xml。
层级信息只与层级查询系统有关，分为几类固定的层级关系，存放位置为：
这里所说的<子系统存储的根目录>是指输出位置约定的各个子系统所在的根目录。比如：层级查询子系统为
2.4.4 输出数据的时机
因为委内网与外部网络处于物理隔离状态，业务系统的数据采集端只能位于外网中才能提供企业直接填报的途径，采集的数据必须经过人工转移才能汇集进入内网中对应的业务系统。因此，业务系统输出数据最适当的时间就是在内网中人工导入采集数据的时候。
业务系统每次输出的数据文件都带有时戳信息，监管系统会定时查询文件服务器中指定的位置，如果发现有新的数据文件，就导入这些文件，然后将它们删除掉。
2.5 文件格式的约定
所有输出数据都按照XML文件格式生成，每个XML文件都使用UTF-8编码。输出数据是区分大小写的。
每个报表都单独输出并生成一个XML文件。有些报表会细分很多子表，比如企业财务报表，以决算为例，财务报表只是一个统称，它还细分为：资产负债表、利润表、现金流量表、所有者权益表、资产减值准备情况表等等，在输出数据的时候，每个子表都将产生一个单独的XML文件，该XML文件的文件名就是子表的表名。
后面的描述将详细约定每一种输出数据的xml文件格式，为便于程序自动处理，我们采用xml schema来定义xml文件格式，并且在附录中附上了这四种输出数据格式定义的xml schema文件，所有的xsd文件将随此规范同时提供电子版。
2.6 时间格式的约定
时间值统一用字符串表示，格式约定如下。
如果时间值只具有年、月、日的信息，则字符串表示为：“YYYY-MM-DD”，是10个字符组成的字符串，其中YYYY代表年，MM代表月，月份不足两位的左边补一个0，DD代表日，日期值不足两位的左边补一个0。一个日期值的例子如：“2009-07-20”表示2009年7月20日。
如果时间值具有时、分、秒信息，则字符串表示为：“YYYY-MM-DD HH24:MI:SS”，是19个字符组成的字符串，其中YYYY代表年，MM代表月，月份不足两位的左边补一个0，DD代表日，日期值不足两位的左边补一个0，DD后面是个空格符，HH24占2位，代表小时（24进制），不足两位时左边补0，MI表示分钟，不足两位时左边补0，SS表示秒，不足两位时左边补0。小时统一用24进制。
一个带时分秒的时间值例子为：“2009-07-31 14:05:53”，表示2009年7月31日下午2点05分53秒。
2.7 时间类型的约定
报表中的时间信息可以分为五类：
●以年度为单位的时间参数
有些报表是按年度申报，其时间的有效期为一年。在统计运算中，时间的月份、日期值不具有意思。年度时间码的分界线从每年一月1日到十二月31日。年度时间码的类型为：TC_YEAR。
●以半年为单位的时间参数
有些报表每半年申报一次，其时间参数的跨度为半年。在统计运算中，时间的日期值将被忽略，而月份值则被用来判别是上半年还是下半年，比如：如果两份每半年申报的报表，其时间分别为2008-02-10与2008-05-30，在系统中他们被当做同一批报表处理，而时间为2008-07-20的，则被归入下半年。半年时间码的起止日期从每年的一月1日到六月30日。半年时间码的类型为：TC_SEMIYEAR。
●以季度为单位的时间
有的报表是按季度申报，其时间参数跨度为一个季度。在统计运算中，时间值的日期将被忽略，而月份则被用来判定是哪个季度。一年分四个季度，定义为：一月到三月为1季度；四月到六月为2季度；七月到九月为3季度；十月到十二月为4季度。季度时间码的类型为：TC_QUARTER。
●以月份为单位的时间
有的报表是按月申报，其时间跨度为一个月。在统计运算中，其时间值的日期将被忽略，只有年份、月份信息有意义。月份时间码的类型为：TC_MONTHLY。
●具有明确日期的时间参数：
有些报表需要非常明确的时间信息，其时间参数精确到日期值，时分秒不计。比如：企业的股权变更申请，或在委系统中要求做到一事一报的一些报表等，在这一类的报表中，其时间参数需要明确的年、月、日的信息。此类时间码的类型为：TC_EXPLICIT。
第三章数据集成接口格式
数据交换涉及到多种数据内容：枚举信息、企业基本信息，企业层级信息、业务报表、报表样式。每类数据都按照XML格式的文件输出，这几类XML 文件的格式用XML Schema来定义，下面分别作详细介绍，它们对应的xsd文件在附录中给出。
3.1 枚举信息的输出格式
枚举信息用来表示子系统中所有引用到的枚举类型与枚举项。
枚举信息的输出格式为：
…
…
…
枚举信息的格式结构如下图：
3.1.1 枚举信息格式说明
3.1.2 枚举信息的输出例子
…
数据集成整体解决方案 继系统集成、应用集成、业务集成之后，最头痛的数据集成（Data Integration）已渐被各大企业纷纷触及。目前国内大多数企业还仅停留在服务于单个系统的多对一架构数据集成应用，这种架构常见于数据仓库系统领域，服务于企业的商务智能。早期那些数据集成大家大都是从ETL启蒙开始的，当时ETL自然也就成了数据集成的代名词，只是忽然一夜春风来，各厂商相继推出DI新概念后，我们不得不再次接受新一轮的DI洗脑，首推的有SAS DI、Business Objects DI、Informatica DI、Oracle DI（ODI）等厂商。 数据集成，主要是指基于企业分散的信息系统的业务数据进行再集中、再统一管理的过程，是一个渐进的过程，只要有新的、不同的数据产生，就不断有数据集成的步聚执行。企业有了五年、八年的信息化发展，凌乱、重复、歧义的数据接踵而至，数据集成的空间与需求日渐迫切，企业需要一个主数据管理（Master Data Manager）系统来统一企业的产品信息、客户信息；企业需要一个数据仓库（Data Warehouse）系统来提高领导层的决策意识，加快市场战略调整行动；企业需要一个数据中心（Data Center）系统来集中交换、分发、调度、管理企业基础数据。 数据集成的必要性、迫切性不言而喻，不断被推至企业信息化战略规划的首要位置。要实现企业数据集成的应用，不光要考虑企业急需集成的数据范围，还要从长远发展考虑数据集成的架构、能力和技术等方面内容。从数据集成应用的系统部署、业务范围、实施成熟性看主要可分三种架构。一种是单个系统数据集成架构、一种是企业统一数据集成架构、一种是机构之间数据集成架构。 单个系统数据集成架构，是国内目前大兴土木所采用的架构，主要是以数据仓库系统为代表提供服务而兴建的数据集成平台，面向企业内部如ERP、财务、OA等多各业务操作系统，集成企业所有基础明细数据，转换成统一标准，按星型结构存储，面向市场经营分析、客户行为分析等多个特有主题进行商务智能体现。这种单个系统数据集成应用架构的主要特点是多对一的架构、复杂的转换条件、TB级的数据量处理与加载，数据存储结构特殊，星型结构、多维立方体并存，数据加载层级清晰。
附件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 !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
监管报表数据报送接口规范修订历史纪录
一、销售机构、基金资金划付明细文件格式建议（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）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得现金红利金额）。
软件项目集成管理解决方案 1 系统概述 软件项目集成管理是实现软件开发过程和软件管理过程的全面管理。软件项目集成管理是通过将项目管理工具（如：MS project）和软件开发平台工具（如：IBM Rational Suite）有机地集成和扩展，依据软件工程和CMM/CMMI理论，按照组织统一的项目管理流程和方法针对软件开发过程、里程碑目标、任务级目标等进行集中管理的过程。软件项目管理一般面向软件开发团队以及有关管理者等部门或个人，最终提高企业软件生产力和项目成功率。 软件项目集成管理技术架构如下图所示： 2 软件项目管理 2.1软件项目计划 2.1.1计划编制 项目经理运用Microsoft Project2003 标准版编写项目计划。Microsoft Project 2003提供了强大的智能任务分解的工具。由于在系统的资源管理模块中已经完成对系统资源的定义，因此在此模块的任务分配中可以首先定义资源的成本，例如人员的计时工资，设备的每次使用成本等有关项目的成本信息，在将资源与相对的任务建立关系后相应资源的成本变为每个任务的成本，所有任务的成本构成项目的总成本。资源的成本定义如下图：
对相应任务分配资源后的项目以及任务成本图例： 项目的计划编写完毕后向服务器发布项目计划，这样项目计划成为最终的项目执行依据。 2.1.2任务执行管理 项目组成员可以在Project中对自己负责任务的完成情况进行设置，待设置被项目经理确认后，登录系统就可以查看项目各个任务的完成情况，如下图： 2.2软件项目跟踪和监督
软件项目跟踪和监控包括对照已文档化的估计、约定、计划评审跟踪软件完成情况和结果，基于实际的完成情况和结果调整这些计划。 在项目经理使用Microsoft Project 2003 标准版做好项目计划时，将做好的最初计划保存为比较基准；当项目进展到一定阶段后可以与比较基准进行比较，得出项目是否按计划进行，还有多少任务没有按时完成，多少任务提前完成等等信息。如下图： 通过这一模块可对项目进度进行控制与更新。以便于上级更好的掌握各种计划的进展情况，同时提供多种形式的进度查询，使领导及时掌握各种任务进展的更新信息。进度更新是更新自己所属任务的进展以及完成情况，便于上级更好的掌握各种计划的安排，以保证项目顺利进行。 3 软件开发过程管理 3.1需求管理 系统采用IBM Rational RequisitePro进行软件需求管理。IBM Rational RequisitePro利用了被广泛应用和熟悉的Microsoft Word工具来简化需求的获取。虽然文档有助于需求的获取，但它不是对信息进行优先级排序和组织的最佳环境，而这些活动在使用数据库时却可以达到最佳效果。通过链接需求文档和数据库，IBM Rational RequisitePro将两者的最佳功能结合在一起。 这个独特的结构充分利用了数据库的强大功能和Word的易用性，以便有效的进行需求管理。IBM Rational RequisitePro中的文档不是简单地将需求从数据库中输入或输出。它们包含当前最新的需求信息，使您可以在熟悉的Microsoft Word环境中对需求进行修改。Word文档中的需求被动态链接到数据库中存储的补充需求信息。数据库和文档被链接在一起，只需简单地在数据库中双击需求，就可启动Microsoft Word，将您直接带到书写该需求的文档
数据集成，主要是指基于企业分散的信息系统的业务数据进行再集中、再统一管理的过程，是一个渐进的过程，只要有新的、不同的数据产生，就不断有数据集成的步聚执行。企业有了五年、八年的信息化发展，凌乱、重复、歧义的数据接踵而至，数据集成的空间与需求日渐迫切，企业需要一个主数据管理（Master Data Manager）系统来统一企业的产品信息、客户信息；企业需要一个数据仓库（Data Warehouse）系统来提高领导层的决策意识，加快市场战略调整行动；企业需要一个数据中心（Data Center）系统来集中交换、分发、调度、管理企业基础数据。 数据集成的必要性、迫切性不言而喻，不断被推至企业信息化战略规划的首要位置。要实现企业数据集成的应用，不光要考虑企业急需集成的数据范围，还要从长远发展考虑数据集成的架构、能力和技术等方面内容。从数据集成应用的系统部署、业务范围、实施成熟性看主要可分三种架构。一种是单个系统数据集成架构、一种是企业统一数据集成架构、一种是机构之间数据集成架构。 企业统一数据集成架构，组织结构较复杂的大型企业、政府机构尤为偏爱这种数据集成的架构，因此类单位具有业务结构相对独立、数据权力尤为敏感、数据接口复杂繁多等特征，更需要多个部门一起协商来建立一个统一的数据中心平台，来解决部门之间频繁的数据交换的需求。如金融机构、电信企业，公安、税务等政府机构，业务独立、层级管理的组织结构决定了内部数据交互的复杂性。概括来说此类应用属于多对多的架构、数据交换频繁、要有独立的数据交换存储池、数据接口与数据类型繁多等特点。
对于企业管理性、决策性较强的信息系统如主数据管理系统、财务会计管理系统、数据仓库系统等数据可直接来源于数据中心，摆脱了没有企业数据中心前的一对多交叉的困扰，避免了业务系统对应多种管理系统时需要数据重复传送
中国财务软件数据接口标准(DOC7) 编者按:标准应该是衡量事务的准则。标准的制定一样都由国际/国家有关标准机构或行业主管部门完成。但一些行业的生产厂商为了爱护用户的投资,促进行业有序进展,也按照本行业的特点,联合起来制定了一些大伙儿认可并共同遵守的规范,这种做法在国外已被广泛采纳。随着中国改革开放的深入,国内一些行业的厂家也开始进行这方面的探究,本期我们刊登的《中国财务软件数据接口标准》确实是由该财务软件行业的民间组织——中国软件行业协会财务及企业治理软件分会制定的,起草者为闻名财务软件厂商深圳金蝶公司。 一、背景 目前,国内财务软件众多,它们采纳的数据库平台和数据库结构各不相同,不同财务软件之间的数据交换,因为数据库平台和结构不同而产生许多困难,几乎任意两个不同软件之间要实现数据传递都会存在专门的数据转换咨询题。烦琐的数据转换工作白费了大量人力和物力,同时也阻碍了财务软件产业的健康进展。国内财务软件的商业化差不多比较成熟,各财务软件公司都有一批用户。由于各种缘故,一些用户期望从一个软件交叉升级为另一软件。由于用户在旧软件上已做了大量的工作,必定期望升级后原有数据能移植到新的软件中,然而有些软件的数据文件通过加密或数据库结构未公布,要从中直截了当读取数据几乎不可能。为了爱护用户已付出的劳动,各财务软件需要提供一个标准的数据输入输出接口。如此,建立一个公用的数据交换标准是专门必要的。 用户在使用财务软件时,有一些需求通过财务软件本身是难以实现的,如:用户期望把会计报表通过电子表格软件处理输出为各种专门形式;另一些高级用户,则期望在其它治理软件中能取到财务数据。这些数据交换工作都需要有一个标准的数据接口来规范。财务会计通过长期的进展已形成一定的理论,财务会计工作也有规范可循,国内财务软件是在这些理论和规范的基础上开发出来的,各软件储存财务数据的模式也大同小异。财务数据要紧按会计科目、凭证、余额及发生额、报表几个部分分块储备,它们之间既
企业应用集成之数据集成规范 单位： 地址： 邮编： 电话： 传真： 日期：
修订文档历史记录
目录 第一章前言 (3) 1.1 概述 (3) 第二章通用的约定 (4) 2.1 数据输出的内容 (4) 2.1.1 枚举信息 (4) 2.1.2 企业信息 (4) 2.1.3 业务报表 (5) 2.1.4 报表样式 (6) 2.1.5 层级信息 (6) 2.2 业务子系统称谓与编码的约定 (6) 2.3 委处室与业务编码的约定 (7) 2.4 数据输出方式的约定 (8) 2.4.1 输出类型 (8) 2.4.2 输出位置 (9) 2.4.3 输出文件的命名 (11) 2.4.4 输出数据的时机 (12) 2.5 文件格式的约定 (12) 2.6 时间格式的约定 (13) 2.7 时间类型的约定 (13) 第三章数据集成接口格式 (15) 3.1 枚举信息的输出格式 (15) 3.1.1 枚举信息格式说明 (16) 3.1.2 枚举信息的输出例子 (18) 3.2 企业基本信息的输出接口 (19) 3.2.1 企业基本信息的内容 (19) 3.2.2 输出文件格式规范 (20) 3.2.3 企业属性的类型 (22)
上海市国有资产监督管理信息系统数据集成规范 3.2.4 企业信息输出文件示例 (24) 3.3 层级信息的输出格式 (26) 3.3.1 层级格式的说明 (28) 3.4 业务报表的输出接口 (29) 3.4.1 输出文件命名规范 (29) 3.4.2 数据文件结构与报表分区 (30) 3.4.3 数据报表的关联关系 (31) 3.4.4 数据文件元素的层次 (33) 3.4.5 单元格的数据类型 (34) 3.4.6 二进制单元格的处理 (35) 3.4.7 枚举型单元格的处理 (35) 3.4.8 附报文件的处理 (36) 3.4.9 报表数据的输出文件格式 (36) 3.4.10 报表数据输出文件示例 (42) 3.4.11 独立上报文件的处理 (47) 3.5 报表样式的输出格式定义 (47) 3.5.1 样式文件的元素结构图 (52) 3.5.2 样式文件表达式定义 (52) 附录I 企业基本信息统计项列表 (54) 附录II 枚举信息的格式定义enum.xsd (55) 附录III 企业信息的格式定义orginfo.xsd (58) 附录IV 报表数据的格式定义report.xsd (62) 附录V 报表样式的格式定义report_style.xsd (71) 附录VI 层级信息的格式定义hierarchy.xsd (75)
中国结算开放式基金新版系统管理人数据接口规范(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)
综合系统集成解决方 案 Revised on November 25, 2020
For personal use only in study and research; not for commercial use For personal use only in study and research; not for commercial use 系统综合集成 解 决 方 案 二○一四年三月七日
目录
系统综合集成解决方案 一、项目背景 现代飞速发展的信息技术，给通信系统信息化建设带来全新革命，正在深刻改变着系统工作、管理、服务、保障的各个环节。信息化发展到当前阶段，用户已经不仅仅满足于传统语音这一单一的通信方式，如何考虑充分利用既有信息资源，减少资源重复建设，融合语音、视频、数据的多媒体通信，实现“所见即所得、所见即可通、所见即可处”和“畅通无处不在”的目标，提升系统的感知能力、执法能力、处置能力、管理能力、服务能力，推动系统的工作模式、管理模式、服务模式的创新，成为系统的迫切需求。 二、当前系统现状 目前，通信系统已建了视频会议系统、视频监控系统、语音系统、无线超短波系统等各自独立、自成体系的通信系统。 (一)视频会议 系统各级部署有多个厂家的视频会议系统，还有一些软终端,这些系统有的基于协议，有的基于SIP协议。
(二)视频监控 系统大部分单位部署了视频监控系统，视频监控建设地点主要分布在各级的港口、码头、办公区等点位。因建设方式不统一，采用的监控管理平台也不统一，主要有海康威视、前卫视讯、大华和其它厂家等品牌，前端摄像机既有模拟摄像机，也有高清摄像机。 （三）语音系统 语音系统为主要使用的各类程控交换机、IP交换机，用于实现单位内部电话通话、以及与PSTN电话网络的互通。 (四)超短波系统 总公司和下属分公司及直属单位建立了全区或部分区域联网的超短波通信网，使用多个厂家、不同系列的超短波设备。 现有的视频会议系统、视频监控系统、各类语音系统、超短波系统等，使用的品牌多样，协议制式不统一，硬件设备跨代多。各系统为各自独立的信息孤岛，相互独立，互不能兼容互通，存在全网统一管理难实现，多协议制式难融合，多系统互通难达成等问题。
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 一、数据集成要解决的问题 从分布、异构和自治的数据源中集成数据，同时保留数据在现存的不同系统上的完整性和一致性 对用户（对统一数据的需求方）隐藏数据的差异性，为其提供统一的数据接口，用于查询、获取和分析 对信息化发展过程中积累的凌乱、重复、歧义的数据进行“再集中、再统一” 二、数据集成的几种架构 单系统数据集成架构：是国内目前主要采用的架构，主要是以数据仓库系统为代表提供服务而兴建的数据集成平台，面向企业内部如ERP、财务、OA等多个业务操作系统，集成企业基础明细数据，转换成统一标准，按星型结构存储，面向市场经营分析、客户行为分析等多个特有主题进行商务智能应用。 企业统一数据集成架构：组织结构较复杂的大型企业、政府机构比较偏爱，因为此类单位具有业务结构相对独立、数据权力尤为敏感、数据接口复杂等特征，需要多个部门协商来建立一个统一的数据中心平台，来解决部门之间频繁的数据交换的需求。业务独立、层级管理的组织结构决定了内部数据交互的复杂性。 机构之间的数据集成架构：跨企业、跨机构、多个单位围绕某项或几项业务进行的业务活动，或由一个第三方机构来进行协调这些企业、机构之间的数据交换、制定统一数据标准，从而形成一个多机构之间的数据集成平台。典型的有中国银联与各商业银行之间的应用案例、市政府信息中心与市政府各机关单位之间的应用案例、外贸EDI（海关、检验检疫局、外汇局、银行、保险、运输等）。 三、数据集成的核心应用 国内企业常见的数据集成应用有数据仓库、数据同步、数据交换，随着企业1袁满整理（中国华融资产管理股份有限公司，研究发展部）
并购、新旧系统升级、分布系统向数据大集中看齐、电子商务的发展、多个企业单位协同作业等等众多业务需求的诞生，数据集成的应用开始繁荣起来。 目前大部分数据集成软件厂商都是围绕数据仓库（Data Warehousing）、数据迁移（Data Migration）、数据合并（Data Consolidation）、数据同步（Data Synchronization）、数据交换（Data Hubs或者叫主数据管理:Master Data Management）这5种常见的企业应用形式来发展各自的产品技术。 数据仓库：集成企业基础数据，面向特定主题 数据迁移：新旧系统升级、数据大集中 数据同步：交通、证券交易、实时汇率 数据合并：企业并购、HR系统的合并、财务系统的合并、其它业务系统的合并，当系统需要合并必然产生数据的合并 数据交换（主数据管理）：一般构成企业主要的基础数据分别是客户数据、产品数据、员工信息数据、供应商数据，要从企业多个系统中快速、可 靠地建立唯一、完整的企业主数据视图。是目前最复杂的数据集成应用四、现有解决方案和案例（以Informatica解决方案为例） 数据集成解决方案的核心是“抽取、转换和装载，即Extraction Transformation Load, ETL 过程”，ETL过程的优劣或者是否适合于企业的数据和业务也是解决问题的主要参考标准。 案例一：中国电信江苏省分公司 1.基本情况 13个地市级分公司+6家直属单位+3个子公司+56个县级电信局 2.集成需求 江苏电信的数据仓库共有 64 节点，源自 28 个源生产系统，因此系统独立、数据分散、缺乏一致性、制约决策分析的应用支持，计划建立企业数据架构（EDA，Enterprise Data Architects），融合后端90%以上数据。 3.解决方案、措施和结果 数据仓库为数据处理核心，数据分布和流转过程首先从各个联机事务处理环
上海证券交易所技术文档 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)
XX集团 系统集成解决方案 金蝶软件(华南区)系统集成部 2011年03月
目录 一、项目背景 (3) 二、方案整体介绍 (4) 2.1系统部署架构 (4) 2.2双机互备和数据备份方案 (5) 2.2.1双机互备方案 (5) 2.2.2数据备份方案 (6) 2.3基础设施选型 (7) 2.4网络指标要求 (11) 2.5网络安全管理 (11) 2.5.1防火墙 (11) 2.5.2VPN技术 (12) 2.6统一身份安全认证平台 (14) 2.7远程接入方案 (15) 三、投资预算 (18) 四、附录服务与支持介绍 (19) 4.1O RACLE专项服务 (19) 4.2小型机专项服务 (26)
一、项目背景 XX集团经过多年的经营，公司业务和规模在不断发展，公司管理层和IT部门也认识到通过信息化手段可以更好地支撑公司业务运营、提高企业生产和管理效率。目前的主要需求是，在公司总部部署协同OA、HR和房地产行业的业务应用系统，且提供分支机构客户端接入，达到整个公司业务的综合管理、数据集中管理和系统统一运维。
二、方案整体介绍 2.1系统部署架构 现在IT的发展趋势是数据集中，数据集中的核心是对服务器进行整合，特别是一些大型企业，建立企业数据中心，购买高性能的主机，对数据集中管理，已成为一种趋势。所以EAS的网络服务器部署应采用集中式应用，系统部署架构如下：
2.2双机互备和数据备份方案 2.2.1双机互备方案 我们在数据库服务器和应用服务器的设计上采取了基于双机热备与SAN数据存储相结合的数据库冗余备份方案，采用HA服务器群集技术，提高了数据库系统及业务应用系统的可靠性，而不是单台主机的可靠性。 双机互备方案的典型应用是采用两台服务器做HA双机系统，一台安装应用服务器，一台安装数据库，两台主机互为备份。其主要功能是提高客户计算机系统及其应用的可靠性，而不是单台主机的可靠性。HACMP有多种配置方式，视具体应用复杂程度和配置不同，其接管时间在30秒到300秒。 HA技术原理： 作为双机系统的两台服务器（主机A和B）同时运行HA软件； 服务器除正常运行自己的应用外，同时又作为对方的备份主机； 两台主机系统（A和B）在整个运行过程中，通过“心跳线”相互监测对方的运行情况（包括系统的软硬件运行、网络通讯和应用运行情况等）； 一旦发现对方主机的运行不正常，故障机上的应用就会立即停止运行，本机（故障机的备份机）就会立即在自己的机器上启动故障机上的应用，把故障机的应用及其资源包括用到的IP地址和磁盘空间等接管过来，使故障机上的应用在本机继续运行； 应用和资源的接管过程由HA软件自动完成，无需人工干预； 当两台主机正常工作时，也可以根据需要将其中一台机上的应用人为切换到另一台机(备份机)上运行。 HA技术特性： 支持并行数据库； 支持动态集群重配置； 广泛的集群管理工具； 支持2到32个集群节点的扩展； 自动失败检测和恢复； 多节点的灵活配置；
污染源在线自动监控系统数据传输和接口标准技术规范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错误校验码。 校验码按照先高字节后低字节的顺序存放。
信息整合整体解决方案 1.前言 经过近几年的努力，国内主要的发电公司和电网公司在信息化建设方面都取得了长足的进步，大量业务系统投入运行，这些信息系统加强了信息管理手段，提高了公司管理水平。随着电力体制改革的不断深入，在电力行业完成组织机构重组和区域重新划分之后，“厂网分开、竞价上网”的经营模式将逐渐变为现实。电力公司为了赢得合理的经济效益和社会效益，迫切需要一个既能集成、优化原有各应用系统，又能满足当前和未来挑战性需求的综合实时的信息整合平台。为了实现整个电力运营的全过程管理和控制，就必须及时真实地了解、应用、分析各方面的信息，从而提高判断与决策的及时性和准确度。信息资源整合将为实现以上目标提供有力的技术手段和保障，并进一步加强已有应用系统的应用深度和广度。 2.信息整合的意义 * 消除信息孤岛，使电力业务系统形成互通互联的整体 * 形成了各个应用系统的统一访问入口 * 提供满足信息安全的统一数据发布平台 * 提供了已有业务系统升级的新手段 * 为建立企业决策系统提供了数据准备 * 解决了数据不规范、编码不一致等问题 * 规范了信息模型，遵循国际标准 * 形成了“按需定制”的企业信息架构 3.基本原则 建设信息整合必须要遵守的原则 * 全方位集成原则，信息整合系统既是“数据中心”也是“业务中心”，信息整合要具有界面集成、数据集成、应用迁移、业务集成等能力。 * 全面集成原则，既要支持逻辑集成，也要支持物理集成。
* 开放性原则，信息整合平台不能成为第N+1个系统。 * 标准化原则，基于IEC61970国际标准。 * 规范化原则，规范各个应用系统数据。 * 统一原则，实现代码统一，信息模型统一。 * 平台化原则，采用标准的平台，保证可靠性和标准性和开放性。 * 流程化原则，业务基于流程引擎实现流程重组和可定制。 清华同方提供的信息整合解决方案，完全满足上面的原则。 4.核心功能 从功能模块上来划分，整个信息整合平台可以分解成六大中心，如下图所示： 4.1存储中心 采用SAN/NAS技术，为电网企业的核心业务系统（营销系统、95598、生产管理、综合信息平台等）提供统一、集中的存储服务。统一考虑，避免各个专业系统重复建设存储系统。 4.2信息交换中心 建设统一的信息交换中心，解决如下信息交换需求：
1. 数据集成的需求 继系统集成、应用集成、业务集成之后，最头痛的数据集成（Data Integration 简称DI）已渐被各大企业（政府机关）纷纷触及。业务增长迫使企业必须提高其自身的 IT 能力，以满足变化的业务需求。引入一些新的应用程序以支持这种新型的需求。以新的方式对现有的信息进行处理和分析，以便更好地把握关键性的业务挑战。有些企业并购了其他的企业，进一步地加速了它们在新的领域中的增长。遗憾的是，信息/数据方面却不能始终以一种受到严格控制和有组织的方式发展，以支持这种增长。因此出现了冗余和不一致的信息孤岛。 为了能够在特定的领域中实现最高的效率，对于相同的数据，不同的应用程序以不同的方式进行表示。例如，大多数企业不会只将客户信息存储在某一个地方。如果不清楚应该从何处获取相应的信息，以及哪个系统中保存着最新的并且最精确的信息，那么这就会成为一个很大的问题。如果不清楚这些问题的答案，就不可能实现返回一致的用户相关信息的服务。我们从客户关系系统中取得的联系电话与销售系统中的不一致，而实际上呼叫中心存放的才是最新的、正确的联系电话，这是许多企业经常遇到的问题。 不同行业企业的业务需求会表现出来具有很大的差异，但是潜在的信息需求却是基本相同的—-都需要集成的、最近的、详细的数据以及进行即时的存取操作。我们企业信息化过程中，常常面临着下面的情景： 我们所在的企业并购了其它企业，那么就会产生数据合并的问题，如两个企业的HR系统的合并、财务系统的合并、其它业务系统的合并，当系统需要合并必然产生数据的合并，因此对企业数据进行统一标准化、规范化、数据的补缺、数据的一致性都将导致数据合并。这就是数据合并应用问题，需要利用数据集成技术去解决。 当企业一个系统的业务活动会影响其它多个系统的进程时，数据的实时性、准确性就尤显重要。如航空公司与航空机场之间的数据同步、证券交易所与证券公司之间的股票信息同步、金融业的汇率信息同步等等。影响数据同步的实时性与可靠性的因素会有网络的连通性、传输效率、数据接口、数据格式等，这些诸多因素都属于数据集成中的数据同步要解决的问题。这是数据同步应用问题，也需要利用数据集成技术去解决。 一般来讲，构成企业主要的基础数据分别是客户数据、产品数据、员工信息数据、供应商数据等等，要从企业多个系统中快速、可靠地建立唯一、完整的企业主数据视图。要实现企业主数据管理应用的数据集成平台，必须具备有良好的数据连通性、良好的数据质量探查与分析、良好的数据转换能力等。利用数据集成技术同样可以解决这里所讲的数据交换应用问题。 那么采取怎样的技术框架和产品去解决我们上述问题呢？这正是我们下面要重点讨论的问题。 2. 数据集成技术分类 数据集成是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中，从而为企业提供全面的数据共享。在企业数据集成领域，已经有了很多成熟的框架可以利用。目前通常采用联邦式、数据仓库和基于中间件模型等方法来构造数据集成的系统，这些技术在不同的着重点和应用上解决数据共享问题。 联邦数据库系统(FDBS)由半自治数据库系统构成，相互之间分享数据，联盟各数据源之间相互提供访问接口，同时联盟数据库系统可以是集中数据库系统或分布式数据库系统及其他联邦式系统。在这种模式下又分为紧耦合和松耦合两种情况，紧耦合提供统一的访问模式，一般是静态的，在增加数据源上比较困难;
登记结算数据接口规范（上市公司版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 配售股