CN101630431B - 多客户端集中式开票数据处理方法 - Google Patents

Abstract

本发明为一种多客户端集中式开票数据处理方法，针对于多客户端，分散度大的特性，利用网络实现的安全性高的，集中式开票数据处理方法以及发票打印处理方法。

Description

多客户端集中式开票数据处理方法

技术领域

本发明涉及的是一种税控开票处理方法，特别涉及的是一种分散、远距离的多客户端，利用网络实现的安全性高的，集中式开票数据处理方法。

背景技术

税收是国家建设的重要资金来源，也是规范市场运行秩序的重要手段，为此针对税收和税控的技术不断推陈出新。

目前对于税控开票而言，常常存在某些企业具有多个经营分部，并且这些经营分部相隔很远并成分散式排布，如水、电、气行业，这种场合交易点多却分布很散，开票量也很大，现在开票的方式主要有如下两种：

第一种，手工出具。

第二种，每个点安装防伪税控单机开票系统，本地化开具发票，每个点的单机开票系统安装一块金税卡。

上述两种情况，第一种无法实现防伪税控，很快会被停止这种方式，第二种方式由多个独立系统构成，但都属于一个企业，在面向税务局税控系统进行报税和购买发票时需要以整体的形式进行操作，所以第二种方式构建的开票组合，在经营总部的单机开票系统被设置为总机，其它经营分点的开票系统被设置为分机，各分机隶属于总机，在每个月初，企业财务工作人员携带发票购买装置从税务局税控系统购买发票，购买到的发票数据在总机处导入总机的金税卡，总机开票系统再将发票分发成各个分点的发票数据包重新装入发票存储装置，财务人员携带所述发票存储装置依次连接各个分机将发票导入到各分机税控开票系统的金税卡中；报税过程也一样，财务人员携带报税装置依次从各分机读取报税数据，然后到总机进行汇总处理，再由总机将处理后的报税数据导出到报税装置，然后去税务局税控系统报税。

综上可知，现有主分机开票系统有如下缺陷：

如果存在有多少个交易点，就需要配备多少个单机版的税控开票系统，每个点都需要有金税卡，系统整体成本高，并且各分点并不集中在一个办公区，有的甚至在不同的区市，整体管理和维护成本高。

各交易点的业务量并不稳定，有时分配好的发票用不掉，有时不够用，临时调整因为和主机不在一处，需要人员安排工作时间，存在一个调整周期，使得整体业务处理能力低，每个点的开票量有上限。

每次购票后分发发票和报税收集汇总报税数据都需要财务工作人员依次跑遍所有分机，工作量大，效率低。

有的分机和主机之间存在开放的网络连接，但因为安全性无法保证，所以发票数据和报税数据无法利用这个资源。

鉴于上述缺陷，本发明创作者经过长时间的研究和实践终于获得本创作。

发明内容

本发明的目的在于，提供一种多客户端集中式开票数据处理方法，用以克服上述缺陷。

为实现上述目的，本发明采用的技术方案在于，提供一种多客户端集中式开票数据处理方法，其包括的步骤为：

步骤a：在任一客户端录入开发票明细内容，并将明细内容打包成一个明文数据包，加密处理后产生一个密文数据包，通过网络输出给一开票服务器；

步骤b：所述的开票服务器接收密文数据包，并将密文数据包解密；

步骤c：判断所述的解密信息是否有效，如果有效执行下述步骤d，如果无效，产生一开票结果消息为错误提示，执行下述步骤f；

步骤d：将解密后的明文数据包送入一金税卡进行处理，所述的金税卡分配一张发票给当前开票数据；

步骤e所述的金税卡将开票数据中的关键业务数据进行加密，形成新的包含明文密文的开票数据包，同时所述金税卡记录本次开票的数据，产生一开票结果消息为成功开票提示；

步骤f：发送所述开票结果消息到本次开票数据的来源客户端，开票数据处理流程结束。

其中，所述的步骤a中的明文数据包加密处理过程是通过将所述的明文数据包发送给本客户端的数字证书的硬件载体进行加密实现的。

其中，所述的步骤b中将密文数据包解密过程是通过一数字证书的硬件载体管理软件实现的。

其中，所述的步骤b中解密信息是否有效为是否能够将所述的密文数据包解密，如果解密成功为解密信息有效；若解密不成功，则为解密信息无效；并丢弃本次无效的数据包。

较佳的，所述的步骤c还包括：将所述的明文数据包中的本次开票数据写入一数据库中。

较佳的，还包括：所述的步骤e’：所述的金税卡如果发现发票用完，则产生一开票结果消息为发票用完提示，并执行下述步骤f。

与现有技术比较本发明有益效果在于，可靠性高，运行和维护成本低，发票集中导入，集中报税，业务处理能力提高，尤其是分发发票和报税，和以前需要人工依次处理分布在不同地域的分机系统相比较，通过集中处理的方式当某个分点的业务量有突然增多或减少的情况时，也不会出现发票不够用或有剩余的现象，提高了工作效率。

附图说明

图1为本发明多客户端集中式开票数据处理方法以及多客户端集中式发票打印处理方法中对应的硬件系统示意图；

图2为本发明多客户端集中式开票数据处理方法以及多客户端集中式发票打印处理方法中对应的软件架构示意图；

图3为本发明多客户端集中式开票数据处理方法的流程图；

图4为本发明多客户端集中式发票打印处理方法的流程图。

具体实施方式

以下结合附图，对本发明上述的和另外的技术特征和优点作更详细的说明。

请参阅图1所示，其为本发明多客户端集中式开票数据处理方法以及多客户端集中式发票打印处理方法中对应的硬件系统示意图；集中式税控管理系统包括：一台开票服务器3与多个客户端1，并通过局域网或者广域网2形成系统；

集中式税控管理系统集成了数字证书认证和加解密体系，数字证书使用USB接口的硬件载体，在开票服务器端进行数字证书的发行、废止等管理，在客户端使用数字证书进行认证和加解密操作，数字证书的硬件载体在本方案中的作用是对要通过网络传送的数据进行加密和对从网络收到的数据进行解密；

客户端通常是由基于PC的计算机系统、客户端开票软件、发票打印机组成，开票软件集成了对数字证书的硬件载体的访问程序，在进行相关业务处理时调用数字证书的硬件载体进行数据的加解密；

所述的开票服务器包括：一服务器计算机系统、服务器开票专用金税卡、数据库、开票服务软件、开票管理软件数字证书的硬件载体管理软件组成；

所述的服务器开票专用金税卡为一个嵌入式计算机硬件产品，由处理器、存储器和通信接口组成，在所述的处理器内运行有固件程序，所述金税卡整体具有数据加解密功能和数据存储功能；

请参阅图2所示，其为本发明多客户端集中式开票数据处理方法以及多客户端集中式发票打印处理方法中对应的软件系统示意图；所述的软件系统采用三层架构模型，分为存储层，业务层以及客户层；其中，

所述的存储层用于存储开据的发票信息，其分两部分，一部分是金税卡，存储未开出和以开出的发票信息和企业信息，主要用于抄报税，税控数据的真实性以所述金税卡中的数据为主。其中，所述的金税卡又分两个子部分，一个子部分是嵌入在金税卡内部的金税卡内部程序模块，主要实现数据的存储，校验，金税卡的状态设置及数据的保密安全；另一子部分是金税卡的硬件驱动程序，用于驱动金税卡正确工作。

另一部分是数据库，主要用于存储已开出的发票信息，所述的数据库存储主要为了解决查询速度或金税卡数据的备份作用。所述的数据库主要用于已开发票的存储及开票人员信息的存储，主要是解决两个问题，一，用于提高查询的速度，金税卡处理数据速度较慢，又要负担开票等任务，如果数据从金税卡里查询，对金税卡处理负担较重。二，起数据备份作用。如果金税卡出现损坏问题，将以数据库的中数据进行恢复。

所述业务层实现了开票，查询，管理，抄报税等所有的业务逻辑。其具有包括开票业务逻辑和管理业务逻辑。所述的业务层可从软件架构和业务模型两个角度分析，其中，

所述的业务层从软件架构角度分五个模块，分别是Web服务接入模块，命令解释分配模块，服务队列模块，金税卡软件接口模块以及数据存储模块；

对于所述的Web服务接入模块，用于接收客户端的处理请求，采用web方式便于网络的传输。由于客户端传过来的数据是加密的，此处还负责解密数据。此处分两个子模块，开票端接入子模块，主要用于开票数据的接收。管理端接入子模块，用于管理端数据的接收处理；

对于所述的命令解释分配模块，对于接入模块解密出来的数据按格式进行解析，命令及参数在客户端是打包成XML的数据包，这里要把命令及参数提取出来，进行部分的校验，分析相应的资源，把它传给服务队列模块；

所述的服务队列模块，把调用金税卡的命令串行化，由于金税卡是串行处理，对于多客户端发过来的并列请求，在此处进行排队，并采用先进先出的队列，逐一把命令传给金税卡软件接口模块；

对于所述的金税卡软件接口模块，其是在金税卡驱动之上建立起来的对各种命令的外包装；

对于所述的数据存储模块，当一个命令生理完成时，针对于命令结果保存到数据库中。

所述的业务层从业务模型角度分两个模块：管理端模块和开票端模块。

所述的管理端模块实现了发票卷的购入，分配，查询，金税卡的状态设置，查询等管理功能；

所述开票端模块主要实现发票的开具，可开专票，普票，废旧物质发票三种票；作废发票；查询发票等功能。

对于第三个层次客户层，主要是操作界面和输入数据的校验。所述的客户层分为四个模块，其分别为：组件接口模块，客户端模块，设置及打印队列模块以及管理端模块；

对于所述的组件接口模块，用以提供开票及相关业务的接口，主要给开次开发人员或企业的ERP系统调用。对传入的数据进行校验，加密和服务器通信。由两套接口组成，一套是新接口，以XML为参数传递，效率更高，使用更方便。另一套是与单机版接口组件相兼容的老接口，为在原接口上开发的ERP系统调用所使用。

对于所述的客户端模块是一个开票程序，操作员可以用来开票，打印，查询，用户校验等开票软件所具备的功能。客户端主要完成开票软件的界面控制。通过调用组件接口实现开票功能。

对于所述的设置及打印队列模块，其分两子模块：设置子模块以及打印队列子模块。其中，所述的设置子模块主要是为了解决组件接口和老接口兼容的问题。老接口是单机版开票软件的文本接口，因为现在是网络方式，与老接口有一些差异。为了让在调用老文本接口软件的程序在不改动的情况下能直接调用开票服务器的组件接口，我们将差异的地方放在了所述的设置子模块里。这样先运行一下设置程序，或原有程序在不改动的情况下无缝的调用现在的开票服务器的组件接口。所述的打印队列子模块，因为开票方式中有组件概念，就是把一卷票分给一个组，一组中可以有多个开票员，每个开票员都可以开此卷票，但每个开票人员都打印发票会造成混乱，所以这个模块可以实时打印，当有发票开票完成时，他会自动打印，也可以都开票完成一起打印。管理端模块用于开票服务器业务的管理查询，其采用BS结构。管理端从软件架构的逻辑上分两个子模块，界面控制子模块和数据封包解包传输子模块。所述的界面控制子模块主要是对数据输入的检验，界面显示等；所述的数据封包解包传输子模块是把数据封装成XML或和XML中提取数据，并处理数据加密和与服务器传递数据。管理端从业务逻辑上分五个子模块：

1.发票卷管理子模块，其实现包括发票卷的购买，发票卷的分配，发票卷的查询功能；

2.金税卡设置子模块，其实现金税卡时钟设置，企业信息设置，开票限额设置等功能；

3.已开发票的管理，查询子模块；

4.帐户系统子模块，其实现对开票人员的添加，修改删除，组设置的管理功能；

5.抄报税子模块，用以连接抄税卡，实行抄取等业务。

基于上述的系统硬件结构和系统的软件架构，则可以实现一种高效的、安全的多客户端集中式开票数据处理方法以及多客户端集中式发票打印处理方法，其中，请参阅图3所示，其为本发明多客户端集中式开票数据处理方法的流程图；其包括的步骤为：

步骤a：在任一客户端录入开发票明细内容，并将明细内容打包成一个明文数据包，加密处理后产生一个密文数据包，通过网络输出给一开票服务器；

步骤b：所述的开票服务器接收密文数据包，并将密文数据包解密；

步骤c：判断所述的解密信息是否有效，如果有效执行下述步骤d，如果无效，产生一开票结果消息为错误提示，执行下述步骤f；

步骤d：将解密后的明文数据包送入一金税卡进行处理，所述的金税卡分配一张发票给当前开票数据；

步骤e：所述的金税卡将开票数据中的关键业务数据进行加密，形成新的包含明文密文的开票数据包，同时所述金税卡记录本次开票的数据，产生一开票结果消息为成功开票提示；

步骤e’：所述的金税卡如果发现发票用完，则产生一开票结果消息为发票用完提示；

步骤f：发送所述开票结果消息到本次开票数据的来源客户端，开票数据处理流程结束。

其中，所述的步骤a中的明文数据包加密处理过程是通过将所述的明文数据包发送给本客户端的数字证书的硬件载体进行加密实现的。所述的步骤b中将密文数据包解密过程是通过一数字证书的硬件载体管理软件实现的。同时所述的步骤b中解密信息是否有效为是否能够将所述的密文数据包解密，如果解密成功为解密信息有效；若解密不成功，则为解密信息无效；并丢弃本次无效的数据包。其中，所述的步骤c还包括：将所述的明文数据包中的本次开票数据写入一数据库中。

同时基于上述的发票开出过程，必然对应提供一种多客户端集中式发票打印处理方法，请参阅图4所示，其为一种多客户端集中式发票打印处理方法的流程图；其包括的步骤为：

步骤a1：在任一客户端录入需打印的发票检索信息，输出至一开票服务器；

步骤b1：所述的开票服务器根据发票检索信息，从所述的开票服务器一数据库中查找对应的开票数据；

步骤c1：判断是否有符合条件的开票数据，如果有执行下述步骤d；否则产生打印结果消息为错误提示，并执行下述步骤f；

步骤d1：将检索到的开票数据从数据库中读出并对其进行加密处理，产生一开票数据密文数据包，然后发送给本次流程发起的来源客户端；

步骤e1：所述的客户端收到所述的开票数据密文数据包后进行解密处理，将解密后产生的开票数据明文进行格式排列的整理后输出到一发票打印机进行打印；

步骤f1：本次发票打印过程结束。

其中，所述的步骤a1还包括：对所述的发票检索信息进行加密处理，其是通过将所述的发票检索信息发送给本客户端的数字证书的硬件载体进行加密实现的，这样是为了保证整个过程的安全性，当然在相对安全的环境下，如果没有潜在的安全易患，这一步骤可以不采用所述的步骤b1还包括：将所述的密文数据包进行解密的过程是通过一数字证书的硬件载体管理软件实现的。所述的步骤d1中对所述的开票数据进行加密过程，是通过一数字证书的硬件载体管理软件实现的。所述的步骤e1中对所述的发票检索信息进行加密处理的过程，是通过将所述的发票检索信息发送给本客户端的数字证书的硬件载体进行加密实现的。

以上所述仅为本发明的较佳实施例，对本发明而言仅仅是说明性的，而非限制性的。本专业技术人员理解，在本发明权利要求所限定的精神和范围内可对其进行许多改变，修改，甚至等效，但都将落入本发明的保护范围内。

Claims (6)

1.一种多客户端集中式开票数据处理方法，其特征在于，其包括的步骤为：

步骤a：在任一客户端录入开发票明细内容，并将明细内容打包成一个明文数据包，加密处理后产生一个密文数据包，通过网络输出给一开票服务器；

步骤b：所述的开票服务器接收密文数据包，并将密文数据包解密；

步骤c：判断所述的解密信息是否有效，如果有效执行下述步骤d，如果无效，产生一开票结果消息为错误提示，执行下述步骤f；

步骤d：将解密后的明文数据包送入一金税卡进行处理，所述的金税卡分配一张发票给当前开票数据；

步骤e：所述的金税卡将开票数据中的关键业务数据进行加密，形成新的包含明文密文的开票数据包，同时所述金税卡记录本次开票的数据，产生一开票结果消息为成功开票提示；

步骤f：发送所述开票结果消息到本次开票数据的来源客户端，开票数据处理流程结束。

2.根据权利要求1所述的多客户端集中式开票数据处理方法，其特征在于，所述的步骤a中的明文数据包加密处理过程是通过将所述的明文数据包发送给本客户端的数字证书的硬件载体进行加密实现的。

3.根据权利要求2所述的多客户端集中式开票数据处理方法，其特征在于，所述的步骤b中将密文数据包解密过程是通过一数字证书的硬件载体管理软件实现的。

4.根据权利要求3所述的多客户端集中式开票数据处理方法，其特征在于，所述的步骤b中解密信息是否有效是按照是否能够将所述的密文数据包解密来判定的，如果解密成功则解密信息有效；若解密不成功，则为解密信息无效；并丢弃本次无效的数据包。

5.根据权利要求4所述的多客户端集中式开票数据处理方法，其特征在于，所述的步骤c还包括：将所述的明文数据包中的本次开票数据写入一数据库中。

6.根据权利要求5所述的多客户端集中式开票数据处理方法，其特征在于，还包括：所述的步骤e’：所述的金税卡如果发现发票用完，则产生一开票结果消息为发票用完提示，并执行下述步骤f。

Images