第一篇：责任矩阵分配表,项目范围说明书,项目变更文件,工作总结体会
项目范围说明书
1.项目名称及描述：
名称：大学生校园生活信息咨询服务台
描述：主要解决的问题是，为大学低年级学生提供其想了解的，在生活和学习上的问题，并且为其解决各方面的难题。
2.项目目的：
虽然当前大学生获取各方面的信息途径有很多，信息量也很庞大，但是很杂乱，缺乏系统性信息和缺乏指导。为此，我们项目小组提供一个了校园生活信息咨询服务台这样的一个平台，提供一个沟通和指导的途径，旨在减少校园生活和学习上的误区，为其提供一个完整的大学规划。
3.项目目标：
项目时间期限：项目启动阶段一周、计划阶段三周、执行阶段两周、收尾阶段一周。费用预算：坚持节约、高效的原则，合理对费用进行使用。本项目实施过程中，费用涉及较多的内容是打印费，海报制作费，材料费等，初步定费用预算值60元左右。
质量要求指标：为了测定此次活动的实际价值，项目小组将质量要求指标量化，即在项目结束阶段，借助整理通过学生反馈回来的服务满意度来衡量。
4.项目可交付成果：
（1）信息搜集调查问卷
（2）可行性研究报告
（3）项目范围说明书
（4）项目调查报告
（5）项目实施系列文件
（6）服务满意度调查问卷
5.项目制约因素：
开展实施项目小组活动主要是利用课余时间，在实施阶段受到最主要的制约因素就是时间因素，计划时间随时可能因为课程计划而变化。此外，团队各个人员分工在已经明确的情况下，人员的变动如请假或离开，也影响项目的计划实施。
6.假设前提：
假设我们开展活动一切顺利，各项任务按时按序有效地完成。
7.附件：
大学生信息服务台项目责任分配矩阵图
注意：P（President）表示主要负责人，S（Service）表示次要负责人。任务编号为1200---1325，除主要负责人外，其余均为次要负责人。
项目变更文件
项目中一些不确定性因素导致了项目的推动过程不会像计划的那样顺利，随着工作的深入，那些不确定因素逐渐变得明确且和当初的预测不一致的时候，就会导致项目变更，项目的变更是不可避免的。一般来说，项目的目标是项目所有活动的最终判断准则，变更的发生可能会引起项目目标变化。所以，变更控制是所有项目管理者要高度关注的问题，变更往往会牵一发而动全身，搞不好会一招不慎，全盘皆输，所以大家对变更的普遍态度是慎之又慎。
为了对项目变更进行有效控制，应由项目实施组织建立变更控制系统。变更控制系统就是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其它书面文件，责任追踪和变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。
变更控制系统可细分为整体、范围、进度、费用变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。
从变更产生的来源来看，变更的因素可以分为两类：内部因素和外部因素。内部因素是指项目的实施过程中，对实施的状态对比计划，发现产生了偏差，从而导致变更项目计划。外部因素则是指服务对象对项目目标本身发生了变化，从而引起计划的变更。
在本次项目小组活动中，从项目整体、范围、费用上看，几乎没有变动；少许变动影响到项目小组的进度，主要是在项目开展时间、项目成员任务划定等，但未有影响项目按照原定计划完成。
影响变动内部原因和解决措施：
一、项目实施计划时间即将预定，突如其来的‘考研交流会”影响到我们小组60%以上的成员，原定的计划不得不将其推迟至下一周。
二、人员的任务都已经确定，此时有小组成员因为请假离开一段时间，小组各个成员任务不得不重新制定和分配。
三、原定项目利用两次课余时间开展两次活动，由于小组内部对项目实施反馈结果意见不统一，最后成员协商通过，第二次取消。
影响变动的外部原因和解决措施：无。
WBS工作分解图
第二篇：软件项目范围说明书
软件项目范围说明书
一、引言
1、编写目的
说明编写这份项目需求说明书的目的，指出预期的读者。
2、背景说明
(1)待开发的软件系统的名称。
(2)本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。(3)该软件系统同其他系统或其他机构的基本的相互来往关系。
3、定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
4、参考资料
列出用得着地参考资料，如：
(1)本项目的经核准的计划任务书或合同、上级机关的批文。(2)属于本项目的其他已发表的文件。
(3)本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发飙日期和出版单位，说明能够得到这些文件资料的来源。
二、任务概述
1、目标
叙述该项软件开发的意图、应用目标、作用范围以及其它应向读者说明的有关该软件的开发的背景资料。解释被开发软件与其它有关有软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容子涵，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2、用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
3、假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
三、需求规定
1、对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地描述对软件所提出的功能要求，说明输入什么量、经过怎么样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
2、对性能的规定
(1)精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。(2)时间特性要求
说明对于该软件的时间特性要求，如对： ① 相应时间。
② 更新处理时间。③ 数据的转换和传送时间。④ 解题时间。
等的要求。(3)灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
① 操作方式上的变化。② 运行环境的变化。
③ 同其他软件的接口的变化。④ 精度和有效时限的变化。⑤ 计划的变化或改进。
对于为了提供这些灵活性而进行的专门的设计的部分应该加以表明。
3、输入输出要求
解释各输入输入数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例。包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
4、数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。
5、故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
6、其它专门要求
如用户单位对安全保密的啊哟球，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
四、运行环境规定
1、设备
列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能，包括：(1)处理器型号及内存容量。
(2)外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量。(3)输入及输出设备的型号和数量，联机或脱机。(4)数据通信设备的型号和数量。(5)功能键及其他专用硬件。
2、支持软件
列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
3、接口
说明该软件同其他软件之间的结构、数据通信协议等。
4、控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
五、数据要求
1、数据的逻辑描述
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指再运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据。包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。
(1)静态数据：列出所有作为控制或参考用的数据元素。
(2)动态输入数据：列出动态输入数据元素（包括在常规运行中或联机操作中要改变的数据）。
(3)动态输出数据：列出动态输出数据元素（包括在常规运行中或联机操作中要改变的数据）。
(4)内部生成数据：列出向用户或开发单位中的维护调试人员提供的内部生成数据。(5)数据约定：说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容量、文卷、记录和数据元的个数的最大值）。对于在设计和开发中去顶的临界性的限制更要明确指出。
2、数据的采集
(1)要求和范围
按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。具体的内容包括： ① 输入数据的来源：例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组。② 数据输入（指把数据输入处理系统内部）所用的媒体和硬件设备。如果只有指定输入点的输入才是合法的，则必须对此加以说明。③ 接受者：说明输出数据的接受者。
④ 输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接受到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，应具体说明。⑤ 数据值的范围：给出每个数据的合法值的范围。⑥ 量纲：给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意。⑦ 更新和处理的频度：给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的平度和平均值，或变化情况的某种其他度量。(2)输入的承担者
说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
(3)预处理
对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。
(4)影响
说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响，例如要求用户单位增设某个机构等。
第三篇：《××项目软件需求变更说明书》
软件需求变更说明书
项目名称： 长益高速收费数据分析系统一、概述
因湖南省高速公路联网拆分系统软件升级，导致长益下属收费站入口和出
口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据，从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析，在与业主方多次探讨后，提出以下变更说明。
二、变更内容
MTC实收和流量
原始情况：
人工收费系统出口站收费数据和出口流量的导入，是由收费站工作
人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数据，导入长益收费数据分析系统。
变更后：
收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车
型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、绿通车减免金额、免费车减免金额、手工票金额。
运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站
进，其他路段出的代收流量的各车型估算流量。其中包括各车型流量、绿通车流量、免费车流量。
MTC实得
原始情况：
人工收费系统实得数据的导入，是由收费站工作人员从站级拆帐网
下载的“拆帐统计报表”，导入长益收费数据分析系统。
代收实得的导入，是由运营部工作人员从拆帐网下载的“长张高速
公司名称，版本号
2公路联网收费实际分配收入统计表”，导入长益数据分析系统。
变更后：
运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各
车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。
报表输出
由于原始基础数据的变更，所导致从数据模型上的建立发生了变化，从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出，需要转换为估算的数据输出，需要对所有的报表进行修改。
需要修改的报表有以下：
公司－绿色通道车辆 公司－收费站拆帐情况表 公司－单车收费标准计算表 公司－流量对比表 公司－各类车流量收入比重对比图 公司－各类车流量收入比重表 公司－实征率 公司－高速免费车 公司－收费车流量统计 公司－ETC收费车与免费车 公司－月流量分析 公司－ETC征费情况 公司－月收入图 公司－月收费情况总表 公司-收费车流量与收入统计 路劲-收入影响因素对比表 路劲-项目每月输入及车流汇总表 路劲-各站每月收入及车流汇总表 路劲-历年路费收入图 路劲-历年次票车流量图 路劲-日报 省局-交通流量统计月报表 省局-绿色通道和免费车公司名称，版本号
省局-其他收入分项统计
三年同天对比-1月
三年同期对比-2月
三年同天对比-3月
三年同期对比-4月
三年同期对比-5月
三年同期对比-6月
三年同期对比-7月
三年同期对比-8月
三年同期对比-9月
三年同期对比-10月
三年同期对比-11月
三年同期对比-12月
周报-高速公路
周报-总表
周报-流量图
周报-收入图
周报-老路
月报-月收费
月报-财务系统内金额拆帐
月报-月度收费情况
公司名称，版本号 4
第四篇：关于合作开发项目相关文件材料移交说明书
关于合作开发项目相关文件材料移交说明书
新疆珠江塑料厂、新疆珠江塑料有限责任有限公司、乌鲁木齐容天物业管理有限公司与新疆安隆房地产开发有限公司就土地合作开发项目前期的土地挂牌、土地司法解封及拆迁阶段性工作已完成，现就所完成工作的相关文件、法律裁定及土地证等材料移交作以说明。
一、移交方所移交的相关文件、材料仅为该土地开发项
目的顺利实施使用，不得进行其他用途。移交后如
出现相关的经济、法律等纠纷损失应由接收方承担。
二、高级法院（长城资产公司）、中级法院（外经贸公司
和富润祥公司）和沙区法院（东方资产公司）关于
土地解封的全部法律文件及裁定移交详见2014年1
月22日的两页《移交材料情况》清单。
三、关于相关的土地证及它项证的移交材料详见2014
年1月24日新疆安隆公司的《承诺书》及《收条》。
以上情况，仅此说明。
移交方代表：新疆珠江塑料有限责任公司接收方：新疆安隆房地产开发公司签字盖章：签字盖章：
2014年1月24日2014年1月24日
第五篇：营改增系统改造项目需求范围说明书
奇瑞徽银汽车金融股份有限公司
营改增系统改造项目
需求范围说明书
奇瑞汽车金融股份有限公司
二〇一六年三月
1/ 19
项目要求 第一节 概述
根据国家税务总局的安排，银行业将实施“营改增”，即银行由缴营业税改缴增值税，同时为客户提供增值税税票。为配合“营改增”改革后各类应税和税务管理信息化需求，满足财政部、国税总局颁布的各类监管要求，启动营改增系统改造建设和现有系统改造。
第二节 系统方案与技术方面要求
1.1.总体目标
1.2.技术要求
技术方案需充分考虑到先进性要求，体现在以下方面但不限于以下方面：
1、开标供应商提供的功能应满足我司业务开展的要求；
2、开标供应商所提供的系统软件应符合业界相关技术标准；
3、提供系统完整的源代码，提供开发平台，至少满足我司二次开发的要求。
4、通过我司会计核算平台及核心、总账对接的方案，5、提供完整的营改增系统改造功能应用，基于营改增要求，完成我司现有系统改造功能；
6、系统支持跨平台部署等；
7、系统应充分考虑我司数据标准化的要求，能够支撑标准化和监管统计需求；
2/ 19
8、系统应采用平台化设计，支持功能性拓展；
9、系统扩充方便，设置修改灵活，操作维护简单，能够适应业务的快速变化及发展；
10、系统提供的软件产品在业务扩展、应用工具、数据库、操作系统等方面具有开放性，做到标准化、通用化；
11、系统安全、可靠，供用户进行有效的维护与使用,系统运行维护要求自动化、参数化和交易化;
12、系统严格按照软件工程要求提供详细的各类文档；
13、能够满足我司现有的开发规范，保证代码的可读性和统一性；
14、操作系统、数据库和中间件的配置符合我司技术架构要求，ip地址与目录等参数配置信息不得写在程序中；
15、基础软件，包括操作系统、数据库、中间件必须符合我司基础软件规范；
16、不允许使用RSA1024及以下强度的加密算法，建议使用国密算法；
17、在设计技术架构时需要充分利用我司现有的软硬件环境，充分考虑我司现有的软硬件环境，保证兼容性，保护我司现有投资；
18、满足我司应用架构的管理要求，充分考虑与其他系统之间的关联性。
19、系统支持负载均衡部署方式，性能不足时可以通过增加设
3/ 19
备线性扩展处理能力。
20、产品必须是行业主流产品，符合业界相关技术标准，在国内外有成功的技术实施案例，满足监管需求；
21、产品必须有后续研发系列，并有良好的发展前景；
22、可与主流厂商软件集成而不影响系统性能；
23、与系统连接的整体配置无单点故障，所有部件采用冗余设计，确保无任何单点故障，并能满足未来7×24小时的应用服务。
24、支持在线维护、更换、升级硬件部件和微码；
25、提供后续开发支持，对于人员成本单独报价。
1.3.系统技术设计原则
1、实用性和适用性
充分利用成熟的先进技术，采用性能/价格比比较高的产品。应用系统设计必须符合实际，适用于银行信息系统建设。
2、完整性
所设计需满足增值税管理所有要求，设计范围包括营改增系统改造和现有系统改造。
3、开放性、兼容性和连通性
所设计的系统在结构上真正实现开放，各种设计规范、技术指标及产品均符合国际和工业标准，包括各种广域网、局域网、计算机及数据库协议，并可提供多厂家产品的支持能力，从而为未来的业务发展奠定基础。系统中所采用的所有产品都要满足相关的国际标准和国家标准，是开放的可兼容系统，能与不同厂牌的产品兼容，4/ 19
可以有效保护投资。系统具备与各种协议计算机通行网络互连互通的特性，确保综合网公用基础设施功能充分发挥。
3、先进性
系统技术水平要保证先进性，符合当代信息技术发展形势，代表当前计算机科学的发展方向。所选择的各平台供应商应有能力对该项进行持续开发，可以保证该项技术不断地更新并可顺利升级而维持系统的先进性。提供良好的技术支持和技术服务，以满足当前的业务需求，使业务或生产系统具有较强的运作能力。
4、高可靠性和可用性
通过提供给用户高可靠的产品（硬件、软件、服务），带有系统容错性的方案(冗余、备份)，较强的管理机制和控制手段，具备事故监控和网络安全保密等技术措施，保证系统的安全可靠和高可用性。
系统建设尽量用主流产品，以保证系统的高质量和稳定性。系统应最大限度集成世界上最稳定且优秀的技术及组件，采用成熟技术以降低系统的不稳定性。对系统如硬件、操作系统、网络、数据库应设计尽可能详尽的故障处理方案，以保证系统的快速恢复。
5、灵活性和可扩充性
所设计的系统应具有良好的扩充性，能够根据管理要求，方便扩展网络覆盖范围、网络容量和网络各层节点的功能，以适应今后可能出现的较大任务符合。硬件平台具有可升级性，当需要时可以通过新的计算机设备同原有计算机设备一起工作以提高系统的5/ 19
处理能力，而保护原有的投资。在源系统改造或者前端应用的需求发生变化时，整个系统的架构和设计方法可以适应这种变化，不会对已有的平台造成影响。
6、易维护性
在系统总体设计上注意系统的维护性。尽量采用大家熟悉的易于维护系统平台。系统软件安装简单、易于操作。
7、标准化
应用软件开发符合软件开发标准的要求，方便维护和扩展。业务处理符合国家法律、法规和有关政策规定。
1.4.功能要求
系统需满足（但不限于）奇瑞汽车金融营改增系统改造系统的以下全部需求：
基于我司IT架构优化，设计现有系统改造功能，包括： 交易认定、价税分离； 会计核算； 客户信息管理； 发票回传。
需要建立统一 “营改增系统改造”实现各类应税和税务管理信息化的目标，包括以下几个功能：
实现“增值税票”的管理、打印等功能 搭建统一的税务管理平台
6/ 19
满足对外披露需求
基础功能 1 价税分离模块
1.1 价税分离原始数据导入
通过系统自动接口（手工导入作为辅助方式）方式，将涉及价税分离的各类交易数据导入营改增外挂管理平台，并支持导入数据验证校验、版本控制、导入日志记录等功能。
1.2 价税分离交易认定规则设置
提供增值税相关各类交易（包括常规贷款交易及特殊交易，如：经销商服务费摊销、贴息摊销、逾期利息转表外、期末补提利息、期初冲回等）认定规则和计税方法配置功能，形成交易明细与价税分离规则映射关系。
1.3 税率设置
提供增值税所属税目及税率信息维护功能，根据交易代码设置的税率，并作为价税分离计算参数。
1.4 价税分离计算
根据价税分离交易认定规则、税率和交易明细数据，进行价税分离计算。
1.5 会计分录生成
支持根据价税分离计算结果和银行会计科目及分录规则，自动生
7/ 19
成增值税调整及相关分录。2 销项发票管理模块
2.1空白发票管理
支持集中维护银行购买的空白发票功能，并提供总行对空白增值税专票的统一管控功能。包括请领入库，将购买的空白专票维护到营改增外挂平台中，每笔开票记录应与实物专票一一对应；专票分发，由总行或地市分行统一管理下辖所有机构空白发票的请领入库，并分发至各机构，系统上对空白发票的请领和分发进行统一管理（目前没有分支机构，但是该功能需保留）。
2.2发票盘点
支持对空白发票进行盘点，保证总分行发票打印的准确性及发票库存的准确性。其中各打印终端可按日盘点打印成功及待打印发票信息，按月盘点发票库存情况。支持生成盘点报表，并经复核人复核。
2.3发票打印
能够与金税系统开票请求接口集成，执行增值税专票打印工作。打印时，对客户资质、是否已开具发票等自动校验，防止错开或重复开票。同时，支持同一交易对手增值税发票打印的合并与拆分，拆分方式可选择平均拆分或自定义拆分。
2.4例外处理
对增值税打印过程中遇到系统异常等意外情况进行记录，并支持对例外事件后续跟进处理。例如，打印未成功需重打，但已经从待打印池中已找不到该笔发票信息；需要冲红已打印的发票再重打；打印
8/ 19
冲红发票等情况。
2.5手工开票
对于需手工开票的业务收入，若属于系统内中间业务收入，由专票打印员通过模糊查询，向交易数据的接口提交数据请求，交易系统返回交易信息和客户信息给营改增外挂管理平台，选择需要打印的任务，提交审批完成后发起打印请求；若属于系统外相关业务收入，由专票打印员手工录入专票信息，提交审批完成后发起打印请求。
2.6发票追溯
提供增值税发票的追溯功能，支持对发票各个节点操作的记录、时间、操作人进行追溯。
2.7发票遗失管理
对遗失的增值税专用发票进行登记记录，并将信息传给金税系统进行挂失处理。
2.8发票作废
当发生空白专票或已开专票作废情况时（如尚未使用的纸质专票损毁），支持相应专票作废处理流程，并进行详细记录。
2.9红字发票管理
支持红字发票开具、申请和审批流程管理功能，并进行详细记录。2.10电子税票管理
待电子发票在行业内推行之后，支持电子发票的开具与管理，并与税务局电子发票系统对接，实现发票数据的传输。3 进项发票管理模块
9/ 19
3.1认证 扫描认证
登记银行收到的各类增值税发票，记录各类进项税票银行内部审批结果，支持进项发票审批状态查询。通过金税系统扫描登记进项专票信息，提交给税务专员审核。
电子认证
对于取得的专票，能够实现与税务局电子发票系统对接，进行电子认证。
3.2进项转出
支持对涉及进项转出的数据信息录入平台，并按照预设逻辑对进项发票进行进项转出操作，并提供汇总功能。
3.3预警提示
对进项发票的认证状态进行跟踪，对于接近认证期限仍未进行认证的发票设置自动预警提示。
3.4抵扣认证
支持通过审批的进项专票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。
3.5未通过认证管理
对于未通过认证发票，显示原因并记录后续跟进和处理流程。4 税务管理
4.1纳税申报管理
10/ 19
支持增值税纳税申报数据采集、计算和人工调整功能，生成纳税申报报表和相应会计分录。
4.2税务管理统计查询
支持多维度、跨组织的税务管理数据、增值税计算明细、发票信息综合查询功能，并提供税务数据分析和风险监控功能。
4.3税会差异分析
针对增值税会计口径数据、税务申报口径以及开票口径进行自动差异分析，形成税会差异分析报表。5 系统基础管理
5.1纳税主体管理
提供纳税主体基本信息维护功能。5.2用户权限和日志管理
提供基于角色授权的用户权限管理体系和详细的系统操作日志记录机制，保障系统数据信息安全。
5.3系统接口管理
提供包括金税系统、数据仓库、财务系统、业务系统等与平台相连接的数据接口管理和维护功能，接口应为开放式，对于新增业务能够及时维护，并导入数据。
5.4工作流设置
支持系统内部各类管理流程的审批工作流配置与维护。5.5 数据备份还原管理
支持平台中各类数据、信息的备份和还原功能，确保业务连续性。
11/ 19
电子发票管理
6.1电子发票数据生成
支持按预先设置的开票规则填开发票，提交税务机关后台系统生成电子发票数据，并自动分配电子发票号码同时对开票信息加密，生成防伪码和二维码，最终生成完整的电子发票。
6.2电子发票作废
当发生开票错误等情况时支持电子发票的作废处理，并进行详细记录。
6.3电子发票红冲管理
支持电子红字发票开具、申请和审批流程管理功能，并进行详细记录。
6.4电子发票查询和统计
支持在系统中查询和统计已开/未开电子发票以及已收进项电子发票的开票项目、开票金额等信息。
6.5进项电子发票认证抵扣
支持系统录入获得的进项电子发票信息，将通过审核的进项电子发票上传至税务局网站进行认证，可即时联机认证或统一批量认证，认证通过后将认证信息回传至财务管理系统进行进项科目的调整。
6.6电子发票预警
支持对电子发票开具过程中异常情况的预警，包括作废过多、红冲过多、申报异常等。营改增系统改造其他业务要求
12/ 19
7.1实现财管系统、会计核算平台、数据集市及其他相关系统的对接，与其他系统交互通过DS或文件分发平台。
1.5其他要求
一、系统测试
系统测试是项目质量的重要保证，开标供应商必须配备专业的测试人员，组建专业的测试团队，制定完善的测试方案。测试方案包括功能测试和非功能测试。
1.功能测试方案应包括如下测试内容： －测试目标 －测试范围
－参加测试人员及组织分工。－测试过程中的缺陷管理。－测试完成标准
－测试工具：测试用例管理工具、缺陷管理工具、性能测试工具、配置管理工具等。－测试数据。－测试实施计划。-测试风险分析。－测试交付物。
－测试的审核和结果认定方法。2.非功能测试方案应包括如下测试内容： －测试目的
13/ 19
－测试范围 －测试启停准则
－模型：业务模型、测试模型 －测试指标 －测试策略 －测试内容
－测试实施准备：环境准备、工具准备、数据准备、脚本准备 －测试组织结构 －测试实施计划 －测试风险分析 －测试交付物
－测试的审核和结果认定方法。
二、项目验收
验收是在项目完成开发并成功试运行的基础上进行的。试运行期不能少于两个月。测试验收由采购人组织，对应用软件进行测试验收，合格后出具合格证明。如试运行期间统计或测试数据表明系统在功能、性能指标或可靠性方面不符合要求，开标供应商有责任及时解决，应根据问题严重程度和解决时间，顺延或重新开始试运行。
成交供应商必须为每一项的测试编写测试手册。验收测试手册的内容包括：测试目的、测试环境和测试所需的设备、测试过程的描述、测试结果及分析、具体的安装、测试和验收要求以最终合同
14/ 19
签订为准。
验收需要开标供应商提交的文档至少包括：系统建设的详细工程日志、系统的需求说明书、系统的概要设计、详细设计说明书、系统的数据库设计说明书、系统的使用说明书、系统的操作说明书、系统的测试大纲、系统的测试报告。
验收需要开标供应商提交的全部源程序，提供开发工具、自有产品及开发平台，以及相应的书面说明等，并保证其合法性，由此产生的所有争议和法律问题由开标供应商负责，由此产生的全部费用由开标供应商负责。
如试运行期间统计或测试数据表明符合要求，将通过延伸，在双方签署验证证书后进入保修期。
三、技术支持及售后服务
开标供应商在邀标文件中必须书面声明充分了解并接受奇瑞汽车金融股份有限公司的技术支持及售后服务条款，即：
1、在跟踪维护期内，乙方每年必须为甲方提供2次应用系统检测和评估，并提供检测和评估报告，侦测应用系统中可能会出现的问题，以协助防范可能出现的风险；
2、在跟踪维护期内，乙方保证按照本合同约定的服务内容、服务方式和服务质量向甲方提供合格的服务，乙方保证服务质量符合甲方要求，并通过甲方验收；
3、在跟踪维护期内，乙方保证提供服务的技术人员的数量和素质满足履行本合同的要求；保证人员的稳定性，未经甲方同意不
15/ 19
得随意更换；如果甲方要求更换服务人员的，乙方应根据甲方的要求更换；
4、对于重大系统的上线、决算等重要时点，乙方将提供现场的技术支持服务，以协助系统的顺利运行。
5、乙方提供7x24x365的故障应急反应机制。甲方系统一旦出现重大故障，则马上启动故障应急反应程序，提供远程技术支持，并承诺采用最快的交通工具赶到现场，提供现场的技术支持和技术保障，以协助生产和运行的顺利进行。到达现场后，乙方将协助客户进行故障诊断和排除。如故障发生的原因是由乙方提供的产品或服务引起的，则乙方会调集技术人员以尽早修复，并提出书面故障分析报告；如确认故障发生的原因是由第三方提供的产品或服务引起的，则乙方向客户提供书面故障诊断分析报告，在提供书面故障诊断分析报告之前，乙方将口头报告故障原因，并协助客户与该第三方交涉，配合第三方排除故障。
6、在跟踪维护期内，乙方为甲方提供甲方工作时间的远程技术电话支持。乙方在接到甲方通过电话或电子邮件方式提出的服务请求后，应在2小时之内给予响应。如有软件故障不能通过电话解决，乙方应在24小时内提供现场技术支持。
7、服务完成后，乙方应将完整的、与所提供服务有关的技术资料，包括但不限于：系统维护纪录、系统变更记录、完整的源程序代码等装订成册提交给甲方系统管理部门；
8、乙方应提供必要的技术指导和不少于5人天的封闭式技术
16/ 19
业务培训，保证甲方能正确、安全、有效地使用及维护系统。
9、根据甲方要求对修正系统差错、改进系统性能、增加系统功能；
10、乙方保证派出人员遵守甲方有关制度、工作纪律和安全规定，乙方服务人员应在甲方规定的工作场地范围内工作。
11、在跟踪维护期内，由于乙方软件产品质量产生的问题，乙方免费提供维护。
四、项目实施
1、项目管理
开标供应商应按照项目管理的要求向我司提供开发计划、时间进度。
开标供应商应明确提出参与本项目的工作人员构成、职责、学历背景、从业背景及参与本职工作的时间。开标供应商应确保在项目实施过程中不变更奇瑞汽车金融认可的项目经理。
在技术需求应答书中，开标供应商应明确其分担职责，进行清晰的工作任务描述。
开标供应商应向买方明确提出详细的质量控制、风险控制措施，确保项目的顺利进行。
2、项目人员
a、项目经理、咨询人员
项目经理、咨询人员必须有2（含）家以上相关银行营改增系统改造完整项目实施、咨询经验。
17/ 19
b、开发人员以及测试人员
开发、测试人员必须有2年以上的开发、测试工作经验，在通过我司相关考试、审核后方能进入项目组开始项目的开发、测试工作，开发、测试人员不允许复用。
以上项目经理、咨询、开发、测试人员，中选方在驻场实施前必须提供相应的工作、学习简历，供采购方进行审核，如采购方不予认可，成交供应商必须按照采购方的要求更换人员。在项目实施阶段，如采购方认为项目经理及实施人员达不到相应要求，采购方有权要求成交供应商更换符合要求的人员，成交供应商不得以任何形式、理由进行拒绝。另，成交供应商需承诺保证实施过程中研发团队的稳定性。
3、进度
项目应在2016年5月1日前完成（包括应急方案）。
4、技术业务支撑
参与我司项目各阶段（系统调研、硬件采购、需求分析、系统设计、系统联调测试、培训、系统上线）的工作。
第三节 售后服务
开标供应商对售后服务及系统维护、数据整理和维护工作的技术责任应作明确说明，包括质保期限承诺、服务响应承诺、系统应急方案、技术支持和相应软件的升级承诺。
一、中选供应商承诺提供一年免费原厂维护。
二、在保修期内，如果软件设计厂家对用户购买的软件有了升级
18/ 19
版本，成交供应商应及时通知用户。如果用户有要求，成交供应商应向用户免费提供相同功能的相同软件升级和技术支持。成交供应商有责任在保修期内提供以下形式的技术支持服务：
详见第二节1.5项”技术支持及售后服务”部分。
三、保修期后，成交供应商有义务在本系统的维护、运行管理和开放方面继续给予用户技术协作和咨询，并明确维护费用标准。19/ 19
点击咨询 