发票真伪查询平台完善推广项目可行性研究报告.docx
- 文档编号:10786752
- 上传时间:2023-02-22
- 格式:DOCX
- 页数:38
- 大小:318.41KB
发票真伪查询平台完善推广项目可行性研究报告.docx
《发票真伪查询平台完善推广项目可行性研究报告.docx》由会员分享,可在线阅读,更多相关《发票真伪查询平台完善推广项目可行性研究报告.docx(38页珍藏版)》请在冰豆网上搜索。
发票真伪查询平台完善推广项目可行性研究报告
发票真伪查询平台完善推广项目
可行性研究报告
1总论【尚忠玉】5
1.1主要依据【尚忠玉】5
1.2主要原则【尚忠玉】5
2项目必要性及可行性【尚忠玉、何华权】5
2.1现状分析5
2.1.1发展现状5
2.1.2现存问题分析【何华权】5
2.2必要性5
2.2.1业务必要性5
2.2.2管理必要性6
2.3可行性6
2.3.1技术可行性6
2.3.2技术应用案例6
3功能性需求分析【张旭】6
3.1业务需求分析6
3.2非功能性需求分析6
4项目方案6
4.1项目目标和范围【任小强】6
4.1.1目标6
4.1.2范围6
4.2项目技术方案【何华权】7
4.2.1业务架构7
4.2.2应用架构10
4.2.3数据架构15
4.2.4技术架构19
4.3项目实施方案【张旭】27
4.3.1组织模式27
4.3.2实施策略27
4.3.3实施阶段细则27
4.3.4实施风险27
4.4项目实施计划【张旭】27
4.4.1项目环境27
4.4.2项目人员28
4.4.3项目进度28
5项目估算【尚忠玉、张旭】29
5.1概述29
5.2编制原则和依据29
5.3估算表及附件29
5.3.1系统需求设计费用1
5.3.2系统开发测试费用1
5.3.3系统实施费用2
5.3.4项目投资其他费用表1
6效益分析1
7附件2
7.1.1附件一:
国家电网公司信息化项目说明书2
7.1.2附件二:
人力资源排程表3
7.1.3附件三:
可研费用估算明细表3
1
总论
通过2013年的研发,发票真伪查询平台已基本形成,与吉林省员工报销的整合应用,更是让国网的各网省对此产生了浓厚的兴趣,纷纷咨询购买和合作,作为公司的这种畅销、亮点产品我们还需要对其继续完善,加大宣传推广力度,待成熟稳定后推向行业外市场,为公司创造更多价值和利润。
1.1主要依据
技术依据:
《国家电网公司“十二五”信息发展规划》
《国家电网公司信息化建设管理办法》
《国家电网公司信息化项目可研编制与评审管理暂行办法》
《某信息技术有限公司2013年工作报告》
《研发中心-生产管理内控管理办法》
《公司1533质量体系》
《网络与信息系统安全隔离实施指导意见》
《网络与信息系统安全隔离方案》
《国家电网公司管理信息系统安全防护总体方案》
《电力市场交易运营系统安全防护方案》
《信息安全网络隔离装置SGI-NDS100实施方案》
《电力二次系统安全防护总体方案》
《国家电网公司SG186工程安全防护总体方案》
应用依据:
以下项目为2014年各公司储备项目:
某生产经营管理系统
某某员工报销发票真伪查询系统
某某员工报销发票真伪查询系统
某某ERP及财务管控发票真伪查询系统
某某生产经营管理系统
某某员工报销发票真伪查询系统
1.2主要原则
以市场为导向,以财务为目标
提高产品质量,加大宣贯力度。
2项目必要性及可行性
2.1现状分析
2.1.1发展现状
发票真伪查询统一平台完成了集成查询、并提供了web查询、webservice接口发布、平台基本管理功能。
2.1.2现存问题分析
目前国内各地税务政策存在较大差异,对发票真伪判别存在以下问题:
表1 各地发票种类存在较大差异,给发票真伪鉴别带来一定难度;
表2 官方发票信息查询平台由各省市各自的官方网站发布,较为分散;
表3 各企业报销的发票量大真伪判别工作量大;
表4 人工判别存在位差也较大;
表5 由于存在假发票报销等问题,企业存在税务审核等方面的风险。
目前平台还存在如下问题:
表6 发票真判别结果,存在一些不能判别或错误判别的情况;
表7 对税务网站监控还存在误判的情况,不具备一定的自动修复功能;
表8 对外接口方案和安全还不够完善。
2.2必要性
2.2.1业务必要性
随着公司并入国网体系,面对全国众多同样进入国网体系的研发单位,尤其是具备ERP实施能力的研发单位,“缺乏核心技术支撑、缺乏可持续的产品保障”成为某ERP人心中的心结。
因此,在2013年,研发中心-ERP技术支持中心明确了工作思路,加大力气投入新技术研究、新产品研发工作,提升自身核心竞争力,为公司各ERP产品部发展提供坚强的后盾。
发票真伪查询平台验收过后,推广效果很好,受到了国网的重视。
现在查询平台还有许多不完善的地方,还有很大的进步空间,所以给予机会做更完善的研究和拓展。
期望后期能有更好的用户体验和更多的利润转化。
2.2.2管理必要性
无
2.3可行性
2.3.1技术可行性
2.3.1.1WebService服务
WebService作为当前较为通用的接口技术,能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件,就可相互交换数据或集成。
依据WebService规范实施的应用之间,无论它们所使用的语言、平台或内部协议是什么,都可以相互交换数据。
WebService是自描述、自包含的可用网络模块,可以执行具体的业务功能。
WebService也很容易部署,因为它们基于一些常规的产业标准以及已有的一些技术,诸如XML和HTTP。
WebService减少了应用接口的花费。
WebService为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
WebService需要一套协议来实现分布式应用程序的创建。
任何平台都有它的数据表示方法和类型系统。
要实现互操作性,WebService平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。
目前这些协议有:
1、XML和XSD
可扩展的标记语言XML 是WebService平台中表示数据的基本格式。
除了易于建立和易于分析外,XML主要的优点在于它既与平台无关,又与厂商无关。
XML是由万维网协会(W3C)创建,W3C制定的XMLSchemaXSD 定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。
WebService平台是用XSD来作为数据类型系统的。
当你用某种语言如VB.NET或C# 来构造一个WebService时,为了符合WebService标准,所有你使用的数据类型都必须被转换为XSD类型。
如想让它使用在不同平台和不同软件的不同组织间传递,还需要用某种东西将它包装起来。
这种东西就是一种协议,如SOAP。
2、SOAP
SOAP即简单对象访问协议(SimpleObjectAccessProtocol),它是用于交换XML编码信息的轻量级协议。
它有三个主要方面:
XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行远程过程调用(RPC)的约定。
SOAP可以运行在任何其他传输协议上。
例如,你可以使用SMTP,即因特网电子邮件协议来传递SOAP消息,这可是很有诱惑力的。
在传输层之间的头是不同的,但XML有效负载保持相同。
WebService希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。
3、WSDL
WebService描述语言WSDL 就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言,用于描述WebService及其函数、参数和返回值。
因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。
4、UDDI
UDDI的目的是为电子商务建立标准;UDDI是一套基于Web的、分布式的、为WebService提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的WebService注册,以使别的企业能够发现的访问协议的实现标准。
5、调用RPC与消息传递
WebService本身其实是在实现应用程序间的通信。
我们现在有两种应用程序通信的方法:
RPC远程过程调用 和消息传递。
使用RPC的时候,客户端的概念是调用服务器上的远程过程,通常方式为实例化一个远程对象并调用其方法和属性。
RPC系统试图达到一种位置上的透明性:
服务器暴露出远程对象的接口,而客户端就好像在本地使用的这些对象的接口一样,这样就隐藏了底层的信息,客户端也就根本不需要知道对象是在哪台机器上。
2.3.1.2RestFul服务
REST指的是一组架构约束条件和原则。
满足这些约束条件和原则的应用程序或设计就是RESTful。
Web应用程序最重要的REST原则是,客户端和服务器之间的交互在请求之间是无状态的。
从客户端到服务器的每个请求都必须包含理解请求所必需的信息。
如果服务器在请求之间的任何时间点重启,客户端不会得到通知。
此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。
客户端可以缓存数据以改进性能。
在服务器端,应用程序状态和功能可以分为各种资源。
资源是一个有趣的概念实体,它向客户端公开。
资源的例子有:
应用程序对象、数据库记录、算法等等。
每个资源都使用URI(UniversalResourceIdentifier)得到一个惟一的地址。
所有资源都共享统一的界面,以便在客户端和服务器之间传输状态。
使用的是标准的HTTP方法,比如GET、PUT、POST和DELETE。
Hypermedia是应用程序状态的引擎,资源表示通过超链接互联。
2.3.1.3Spring框架
Spring是一个开源框架,Spring是于2003年兴起的一个轻量级的Java开发框架,由RodJohnson在其著作ExpertOne-On-OneJ2EEDevelopmentandDesign中阐述的部分理念和原型衍生而来。
它是为了解决企业应用开发的复杂性而创建的。
Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。
然而,Spring的用途不仅限于服务器端的开发。
从简单性、可测试性和松耦合的角度而言,任何Java应用都可以从Spring中受益。
◆轻量——从大小与开销两方面而言Spring都是轻量的。
完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。
并且Spring所需的处理开销也是微不足道的。
此外,Spring是非侵入式的:
典型地,Spring应用中的对象不依赖于Spring的特定类。
◆控制反转——Spring通过一种称作控制反转(IoC)的技术促进了松耦合。
当应用了IoC,一个对象依赖的其它对象会通过被动的方式传递进来,而不是这个对象自己创建或者查找依赖对象。
你可以认为IoC与JNDI相反——不是对象从容器中查找依赖,而是容器在对象初始化时不等对象请求就主动将依赖传递给它。
◆面向切面——Spring提供了面向切面编程的丰富支持,允许通过分离应用的业务逻辑与系统级服务(例如审计(auditing)和事务(transaction)管理)进行内聚性的开发。
应用对象只实现它们应该做的——完成业务逻辑——仅此而已。
它们并不负责(甚至是意识)其它的系统级关注点,例如日志或事务支持。
◆容器——Spring包含并管理应用对象的配置和生命周期,在这个意义上它是一种容器,你可以配置你的每个bean如何被创建——基于一个可配置原型(prototype),你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。
然而,Spring不应该被混同于传统的重量级的EJB容器,它们经常是庞大与笨重的,难以使用。
◆框架——Spring可以将简单的组件配置、组合成为复杂的应用。
在Spring中,应用对象被声明式地组合,典型地是在一个XML文件里。
Spring也提供了很多基础功能(事务管理、持久化框架集成等等),将应用逻辑的开发留给了你。
◆MVC——Spring的作用是整合,但不仅仅限于整合,Spring框架可以被看做是一个企业解决方案级别的框
架。
客户端发送请求,服务器控制器(由DispatcherServlet实现的)完成请求的转发,控制器调用一个用于映射的类HandlerMapping,该类用于将请求映射到对应的处理器来处理请求。
HandlerMapping将请求映射到对应的处理器Controller(相当于Action)在Spring当中如果写一些处理器组件,一般实现Controller接口,在Controller中就可以调用一些Service或DAO来进行数据操作ModelAndView用于存放从DAO中取出的数据,还可以存放响应视图的一些数据。
如果想将处理结果返回给用户,那么在Spring框架中还提供一个视图组件ViewResolver,该组件根据Controller返回的标示,找到对应的视图,将响应response返回给用户。
所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。
它们也为Spring中的各种模块提供了基础支持。
2.3.1.4Springsecurity
SpringSecurity是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
它提供了一组可以在Spring应用上下文中配置的Bean,充分利用了SpringIoC,DI(控制反转InverseofControl,DI:
DependencyInjection依赖注入)和AOP(面向切面编程)功能,为应用系统提供声明式的安全访问控制功能,减少了为企业系统安全控制编写大量重复代码的工作。
Springsecurity集成了多种验证方式,提供了很好的扩展能力,OpenId,LDAP,ACL,数字签证等等认证方式。
保障系统的安全性
2.3.1.5Hibernate框架
Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。
Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。
1、封装了jdbc,简化了很多重复性代码。
2、简化了DAO层编码工作,使开发更对象化了。
3、移植性好,支持各种数据库,如果换个数据库只要在配置文件中变换配置就可以了,不用改变hibernate代码。
4、支持透明持久化,因为hibernate操作的是纯粹的(pojo)java类,没有实现任何接口,没有侵入性。
所以说它是一个轻量级框架。
3功能性需求分析
3.1业务需求分析
专题分析:
基于现有发票真伪查询平台,进行更深入的研究。
包括本平台的真伪验证更加精准,可扩展,而且保证平台的快速响应和稳定性能。
还包括移动智能终端的发票真伪查询,实现二维码扫描,票面识别,查询。
同时优化用户体验和性能等等。
以及提供最新发票相关法律,新闻抓取等等
3.1.1WEB发票查询
用户在网络环境中,可以通过浏览器直接访问发票查询网站,然后进行发票的信息查询。
实现通过发票代码识别发票的所属地区,然后接入该地区的发票查询网站。
返回必须字段,例如:
发票号码,发票验证码,金额等信息。
填写完成过后模拟HTTP请求到该地区网站进行发票查询。
3.1.2接口发票查询
第三方接口使用可以通过Webservice或者RestFul接口进行发票的信息查询。
实现与WEB发票查询步骤相似的流程接口,从提交发票代码,返回必须得查询字段信息,然后接收第三方提供的信息进行查询。
实现接口信息加密技术,支持验证信息加密算法,保证用户信息在传输过程中不被窃取和篡改。
3.1.3报表业务
用户以及网站管理员可以通过报表信息查看自己的统计信息,以及管理各自权限所有业务
用户报表,提供用户的缴费记录查询,用户历史查询记录查询。
网站管理员,提供网站的收入查询,发票异常记录查询,发票查询统计分析。
3.1.4异常监控与自动修复
网站接入的其他发票网站信息,但是网站信息随时更新或者宕机。
需要实现网站的监控,监控网站是否有信息改变,是否宕机,是否无法访问。
精准分析确定原因,然后发送相关异常文件到网站服务员。
实现对网站接入的及时管理。
自动修复,在监控过程中可能出现网络不通原因,所以需要在网站进行查询的接口中判断是否进行异常自动修复。
3.1.5系统业务管理
实现对网站的相关业务进行后台管理
3.1.5.1用户管理
系统:
实现管理网站的各级用户,授权,新建,修改,禁止等等。
个人:
企业用户实现对子账户的管理,涉及子账户的信息维护,查询次数授予,或者套餐授予。
3.1.5.2计费管理
实现对用户的费用信息管理,涉及用户续费,用户续费查询,缴费用户与其他用户的基本信息管理
3.1.5.3接入税务管理
实现税务网站接入的管理,包括新增税务网站接入,信息修改,状态维护。
以及税务接入概况图示,地区详细图示等等
3.1.5.4新闻通知管理
实现网站的通知,以及最新新闻,广告等模块的管理
3.1.6邮件推广
实现网站的邮件系统服务,包括用户购买服务到期提醒,税务网站监控状态提醒,用户消费状况提醒,系统充值活动提醒(推广)
完善客户的体验和对查询平台的推广。
3.2非功能性需求分析
3.2.1性能要求
1,事务失败率
信息系统事务失败率不得超过0.1%。
2,CPU利用率
当系统并发用户数在设计要求范围内时,应用服务器和数据库服务器的CPU平均利用率不得超过60%,且CPU利用率不得连续30秒超过80%。
3,数据库性能
系统数据库应满足如下性能指标:
平均SQL响应时间不得超过5秒;SQL查询涉及多表,并且多表笛卡尔积的数据量小于10万条数据时,该SQL语句执行时间不得超过3秒;SQL查询涉及到多表,并且多表笛卡尔积的数据量小于100万条数据时,该SQL语句执行时间不得超过5秒;SQL查询涉及到多表,并且多表笛卡尔积的数据量小于1000万条数据时,该SQL语句执行时间不得超过8秒。
4,可靠性设计
信息系统代码逻辑应严谨,对各种系统异常进行处理,确保每一个方法和过程都有try…catch语句等;对系统事务失败、通信失败等情况能自动识别并解决,确保系统可用。
3.2.2可靠性要求
表9 系统开发测试过程中,应开展覆盖全过程、全业务的测试工作,确保单元测试、集成测试等环节对测试案例的覆盖率达100%;对内存溢出、资源不释放等问题应进行专项测试;
表10 在承受最大并发用户数持续运行2小时的情况下,系统运行平稳,业务失败率不超过0.1%,CPU平均占用率低于60%,内存占用率没有明显增长且1小时后内存恢复初始值;
表11 在承受百分之四十的最大并发用户数持续运行8小时的情况下,系统运行平稳,业务失败率不超过0.1%,CPU平均占用率低于60%,内存占用率没有明显增长且1小时后内存恢复初始值。
4项目方案
4.1项目目标和范围
4.1.1目标
2014年,“发票真伪查询平台完善推广”的目标是:
利用现有技术、现有的发票真伪鉴别平台及人才优势,加强基础性和前瞻性技术研究,提升公司在ERP技术领域对核心技术和产品的研发能力,打造核心产品、提高核心竞争力,拓展新的利润增长点,为ERP各业务产品部提供优质的、更好的技术服务支持。
4.1.2范围
2014年“发票真伪查询平台完善推广”平台的开发范围如下。
表12 在现有平台的基础上深入完善发票真伪鉴别能力及真伪判断规则:
1.1深化各税务系统查询结果分析鉴别发票真伪及发票票面信息分析是否有盖章、发票类型对应的发票使用范围、发票类型对应的发票金额。
1.2对发票本身的真假防伪鉴定,如克隆票。
1.3对真发票内容的真实性,如发票本身用户家具类发票,结果开成电子类等。
1.4对超额发票鉴定,如发票本身只能开1000元,则开出2000元。
1.5对增值税发票存在校验期限和查询次数,如校验期限为6个月,查询次数为1次等。
表13 在现有平台的基础上深入研究发票校验方式:
例如二维码扫描查询:
2.1移动端新增二维码扫描。
2.2电子凭证管理模块。
表14 在现有平台上深入完善发票真伪鉴别系统与其他项目集成:
例如作为中间件和财务管控集成及其他第三方系统集成:
3.1对发票真伪查询实现原理是否符合国网信息安全。
3.2发票真伪查询平台的实施对ECC和财务管控服务器的影响。
3.3发票真伪查询平台与ECC增值税发票管理平台和财务管控的集成融合等。
表15 在现有平台上深入完善对税务系统异常的预警:
例如自动监控税务系统是否改版,预警本平台解析插件是否能正常解析:
4.1税务网站自动监控和修复能力提升。
4.2税务网站异常通知;
4.3增值税180预警提醒。
表16 在现有平台的基础上完善发票平台后台管理:
5.1用户角色细化,各级用户管理,计费,后台内容丰富。
5.2接口用户查询已查发票明细,报表导出功能等。
5.3通知管理,真假接口用户通知管理,修改通知等。
4.2项目技术方案
4.2.1业务架构
4.2.1.1业务目标
为各种需要发票真伪验证的直接(间接)客户提供友善实用的发票查询服务是本平台的业务目标。
具体服务包含web查询真伪、手机查询真伪、直接扫描发票查询真伪、第三方系统接入等方式。
平台的稳定性、结果的准确性是服务质量保证的基础。
4.2.1.2业务功能
业务功能描述:
一级能力
二级能力
能力描述
能力演进方向
查询界面
Web查询
直接通过平台提供web界面输入发票信息验证发票真伪。
手机查询
通过手机客户端验证发票真伪
查询接口服务
第三方系统接入发票真伪查询平台接口,发布方式包含webservice、RestFul、File。
税务发票查询网站接入管理
目前全国需接入的税务网站有132个,个税务网站存在经常变更和不稳定的情况,通过该功能来管理各税务网站接入情况并维护。
系统监控
监视系统的运行情况,及发票查询异常监控,包括网站变更、网络中断等情况。
用户管理
对平台使用用户的管理,包含用户的增删改、用户权限分配等功能。
计费管理
对用户的计费方式、缴费情况进行管理。
统计分析
对系统用户的发票查询情况统计分析。
4.2.2数据架构
4.2.2.1主数据
4.2.2.1.1平台数据
查询平台产生数据:
1,发票历史查询记录
Web或者移动智能端查询的记录,包括发票代码,发票号码等必要信息
数据产生用于故障分析,用户查询分析
2,发票接入网站记录
网站接入其他税务官网的必要信息,包括税务网站域名,税务网站表单信息等
4,用户数据记录
查询平台的用户信息,包括用户基本信息,用户缴费信息等
4.2.2.1.2接口数据
接入税务网站的返回数据:
1,通过用户提交信息到税务官网进行查询,税务网站所返回的数据。
4.2.2.2数据流转
1,查询平台-税务网站
查询平台提交发票票面信息,包括发票代码,发票号码,验证码等必要信息税务网站通过提交的发票信息,查询出相应的结果,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 发票 真伪 查询 平台 完善 推广 项目 可行性研究 报告