CN106504044A - 一种开票方法及系统 - Google Patents

Abstract

本发明公开了一种开票方法及系统，涉及税控技术领域，用于提高设有多个开票点的纳税人进行开票的便捷性。该开票方法包括：步骤S1、税控服务器向税务局的后台服务器申请空白发票段；步骤S2、税务局的后台服务器将空白发票段发送至税控服务器的发票库中；步骤S3、税控服务器将发票库中的空白发票段分发到至少一个发票池中；步骤S4、开票员通过开票终端登录至发票池；步骤S5、税控服务器判断自身是否处于可开票状态，若处于可开票状态，则执行步骤S6；步骤S6、开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中，税控服务器生成发票，并将发票返回给开票终端。本发明应用于开具发票。

Description

一种开票方法及系统

技术领域

本发明涉及税控技术领域，尤其涉及一种开票方法及系统。

背景技术

发票是单位或个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证。

为便于对纳税人的开票行为进行管理，现有技术中，纳税人需要配置嵌入式税控设备(如，税控盘)才可以正常开具发票，其中，每一个税控盘对应于一个纳税人识别号。然而，本申请的发明人发现，当纳税人设有多个开票点时，纳税人需要为各个开票点配置税控盘，存在开票不便的问题。

发明内容

本发明的目的在于提供一种开票方法及系统，用于提高设有多个开票点的纳税人进行开票的便捷性。

为达到上述目的，本发明所提供的开票方法采用如下技术方案：

一种开票方法，应用于设有至少一个开票点的纳税人，各个开票点均设有开票终端，各个开票终端均与纳税人的税控服务器相连接，该开票方法包括：步骤S1、税控服务器向税务局的后台服务器申请空白发票段；步骤S2、响应于税控服务器的申请，税务局的后台服务器将空白发票段发送至税控服务器的发票库中；步骤S3、税控服务器将发票库中的空白发票段分发到至少一个发票池中，其中，发票池设于税控服务器中；步骤S4、开票员通过开票终端登录至发票池；步骤S5、税控服务器判断自身是否处于可开票状态，若处于可开票状态，则执行步骤S6，若处于不可开票状态，则向开票终端返回不可开票的消息；步骤S6、开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中，税控服务器生成发票，并将发票返回给开票终端。

由上述开票方法的具体步骤可知，各个开票点的开票员只需要通过开票终端登录至税控服务器上的发票池，并将待开发票的明细数据写入发票池的空白发票中，税控服务器就能够生成发票，并将发票返回给开票终端，不需要为各个开票点配备税控盘，相比于现有技术，明显地提高了设有至少一个开票点的纳税人进行开票的便捷性。

另外，本发明还提供了一种开票系统，该开票系统包括纳税人的税控服务器、各个开票点的开票终端以及税务局的后台服务器。其中，税控服务器包括申请模块、分发模块、至少一个发票池、判断模块、写入模块和反馈模块；其中，申请模块用于向税务局的后台服务器申请空白发票段；分发模块用于将申请模块所申请到的空白发票段分发到各个发票池中；判断模块用于判断税控服务器是否处于可开票状态；写入模块用于在税控服务器处于可开票状态时，允许开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中；反馈模块用于在税控服务器处于不可开票状态时，向开票终端返回不可开票的消息。税务局的后台服务器用于响应于税控服务器的申请，将空白发票段下发到税控服务器中；开票员可通过开票终端登录至发票池。

该开票系统中的税控服务器、开票终端和税务局的后台服务器相互配合，以执行上述的开票方法，因此，该开票系统具有和上述开票方法相同的有益效果，此处不再进行赘述。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例所提供的开票系统的硬件架构示意图；

图2为本发明实施例所提供的税控服务器的硬件架构示意图；

图3为本发明实施例所提供的税控开票软件的模块示意图；

图4为本发明实施例所提供的开票方法的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为便于本领域技术人员理解，在描述本发明实施例所提供的开票方法及系统前，首先对本发明实施例中的开票系统的硬件架构进行介绍，具体地，如图1所示，税控服务器1分别与税务局的后台服务器2、管理员终端3、开票终端4通过互联网相连接。此外，企业还可以将企业自身的信息化管理服务器5与税控服务器1相连接。

接着，对本发明实施例中的税控服务器1的硬件框架进行介绍。具体地，如图2所述，税控服务器1包括通用服务器11、税控板卡12和税控核心板13。其中，通用服务器11可以根据纳税人的需求选用不同性能指标及价位的各类商用服务器，并装载经过定制化修改和剪裁的Linux系统。随后在通用服务器11上进一步安装税控服务器主应用程序、各种驱动和插件等。配合税控板卡12和税控核心板13，安装在通用服务器11上的主应用程序可以实现包括发票库领购、退回发票段、发票分发、开具正数发票、开具红字发票、发票作废、发票报送、发票签名和发票上传等全套税控业务。同时，通用服务器11还可以运用搭载在通用服务器11上的大容量磁盘阵列，提供高安全性和高冗余的加密RAID1存储，存储包括发票明细数据和报送数据等在内的税控数据。

税控板卡12是通用服务器11的PCI(Peripheral Component Interconnect，外设组件互联标准)插槽和多块税控核心板13的连接与通信工件。也就是说，通用服务器11的一个PCI插槽上可以插一块税控板卡12，该税控板卡12上可以连接有多块税控核心板13，具体地，根据不同类型的通用服务器11，可以有搭载不同数量(例如，2块)税控核心板13的税控板卡12。同时，税控板卡12还可以提供心跳判断功能，即税控板卡12可以定时自动向搭载在该税控板卡12上的税控核心板13发送用于验证税控核心板13与税控板卡12之间的链接是否正常的心跳信号。

税控核心板13是由现有技术中的嵌入式税控设备发展而来，将原嵌入式税控设备中安全要求较低、性能和存储占用较大的功能模块转移到通用服务器11的主应用程序中，而税控核心板13则保留了关键性的、安全性要求较高的多个功能模块，这些功能模块可以实现存储发票模板、存储对称和非对称加解密密钥、生成税控码、生成数据报送签名和生成发票上传签名等功能。此外，值得一提的是，一块税控核心板13对应一个纳税人识别号和一个发票库，同时在一块税控核心板13上可以设有多个发票池，一个发票池对应于一个开票点，也就是说，一块税控核心板13上可以对应于多个开票点。例如，可以在一台税控服务器1中配置2块税控板卡12，每块税控板卡12上连接有5块税控核心板13，每块税控核心板13上设有100个发票池，那么该税控服务器1可以支持10个纳税人识别号，同时可以支持1000个开票点的同时使用。此外，还值得一提的是，还可以在税控服务器1内设置备用的税控核心板，从而当某块税控核心板13损坏时，可以直接切换至备用的税控核心板上进行正常的开票业务。

以上为对税控服务器1的硬件框架的介绍，另外，在实际使用的过程中，对于不同规模的纳税人可以灵活地配置税控服务器1。例如，对于规模较大的企业而言，可以将税控服务器1架设在企业自有的机房内。又例如，也可以将税控服务器1架设在税务局指定的机房内，规模较小的企业可以购买或者租用税控服务器1中的若干块税控核心板13，从而不必在企业内部配置完整的税控服务器1，减轻企业的负担，实现高性价比的开票点部署。需要说明的是，将税控服务器1架设在税务局指定的机房内可以为将税控税服务器1架设在税务局自身的机房内，也可以为将税控税服务器1架设在经税务局认可的第三方机房内。

接着，对与税控服务器1对应的税控开票软件6进行介绍。具体地，税控开票软件应用于开票终端上，采用B/S(Browser/Server，浏览器/服务器)架构，如图3所示，其主要包括五大功能模块：服务器管理模块61，包括添加服务器、更新服务器、编辑服务器、同步服务器信息和启动发票上传等功能；服务器信息管理模块62，包括设置服务器基本信息、管理信息和税种税目等功能；发票管理模块63，包括发票领购、发票分发和发票退回等功能；系统管理模块64，包括参数设置、发票类型代码、操作员管理和日志管理等功能；发票开具模块65，包括正数发票开具、负数发票开具、发票作废和发票查询等功能。其中，管理信息可以包括监控管理数据和离线开票控制的相关管理数据。

以上为对本发明实施例中的开票系统的硬件架构、税控服务器1的硬件架构和税控开票软件的介绍，下面对本发明实施所提供的开票方法及开票系统进行介绍。

实施例一

本发明实施例提供了一种开票方法，应用于设有至少一个开票点的纳税人，各个开票点均设有开票终端，各个开票终端均与纳税人的税控服务器相连接，如图4所示，该开票方法包括：

步骤S1、税控服务器向税务局的后台服务器申请空白发票段；

具体地，纳税人的管理员可以在管理员终端上插上税控钥匙，税控钥匙与税控服务器进行密钥协商，确认了管理员的身份后，管理员可以通过管理员终端上的浏览器登录税控服务器，然后，管理员就可以通过税控服务器向税务局的后台服务器申请空白发票段。需要说明的是，管理员终端可以为安装了浏览器的PC(Personal Computer)机。

具体地，上述税控钥匙指的是一种基于PKI(Public Key Infrastructure)体系的USB-KEY技术所研发出来的嵌入式安全设备。它采用USB接口，可方便对接各类终端设备，且内置嵌入式智能卡芯片，可以提供一定的安全存储空间，例如，税控钥匙可以存储用户的私钥以及数字证书，并可以利用内置的公钥算法实现身份认证。同时，由于用户的私钥存储在安全存储空间中，理论上任何方式都无法读取，从而保证了用户身份认证和通信的安全性。值得一提的是，税控钥匙可以支持SM1、SM2、SM3、SM4、RSA、3DES、SSF33、SSF44和SHA等各类国密算法以及常见的商用算法，并能够提供各类非对称或对称算法的加解密、签名验证和密钥协商等功能。

步骤S2、响应于税控服务器的申请，税务局的后台服务器将空白发票段发送至税控服务器的发票库中；

具体地，税务局的后台服务器所返回的空白发票段存储于税控服务器中与该纳税人相对应的税控核心板中，也就是说，发票库设于税控核心板中，以保证发票库的安全性。

步骤S3、税控服务器将发票库中的空白发票段分发到至少一个发票池中，其中，发票池设于税控服务器中；

例如，纳税人设有3个开票点A、B和C，那么，税控服务器的税控核心板中设有3个与开票点相对应的发票池。如果税务局的后台服务器向税控服务器的发票库中发送了100张空白发票，那么，管理员可以根据实际需要将这100张空白发票分发到各个发票池中。例如，在实际开票的过程中，发现开票点A的开票需求较大，开票点C的开票需求较少，那么，管理员可以向开票点A所对应的发票池中分发50张空白发票，向开票点B所对应的发票池中分发30张空白发票，向开票点C所对应的发票池中分发20张空白发票。由上述内容可知，管理员可以根据实际需要对各个发票池中的空白发票的数量进行调配，以满足不同开票点的开票需求。

步骤S4、开票员通过开票终端登录至发票池；

具体地，当各个开票点的开票员均配备有税控钥匙时，本步骤具体可以包括：开票员将税控钥匙插入开票终端；税控钥匙与税控服务器进行密钥协商，对开票员的身份进行验证；身份验证成功后，开票员通过开票终端登录至发票池。例如，开票点A的开票员通过身份认证后，那么，该开票员就可以通过开票点A的开票终端登录至发票池，通过税控钥匙可以保证开票行为的合法性。需要说明的是，开票终端可以为安装了浏览器的PC机。

步骤S5、税控服务器判断自身是否处于可开票状态，若处于可开票状态，则执行步骤S6，若处于不可开票状态，则向开票终端返回不可开票的消息；

步骤S6、开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中，税控服务器生成发票，并将发票返回给开票终端。

由上述开票方法的具体步骤可知，各个开票点的开票员只需要通过开票终端登录至税控服务器上相对应的发票池，并将待开发票的明细数据写入发票池的空白发票中，税控服务器就能够生成发票，并将发票返回给开票终端，不需要为各个开票点配备税控盘，相比于现有技术，明显地提高了设有至少一个开票点的纳税人进行开票的便捷性。需要说明的是，税控服务器所生成的发票可以是一种专用防伪认证的发票明细数据，该发票明细数据返回给开票终端后，可由开票终端打印，或者直接将其以电子发票的形式提供给开票户。

为便于本领域技术人员进一步理解上述开票方法，下面对上述步骤S5进行具体地说明。

可选地，当税控服务器中存有税务局写入的管理信息时，步骤S5中，税控服务器可以根据管理信息判断自身是否处于可开票状态。示例性地，管理信息可以包括：每月5号前报税、每月最多可以开具1000张发票以及每个月的发票额度为10万元。当税控服务器发现当前时间已超过报税期限，或者本月已开发票的数量超过了1000张，或者本月已开发票的数额已超过10万元，则管理信息会自动将税控服务器设置为不可开票状态，只有不违反上述三条限制条件中的任意一条时，税控服务器才会处于可开票状态。

在另外一种可选的情况中，当税控服务器中存有税务局写入的管理信息时，步骤S5中，税控服务器可以根据管理信息，以及未上传至税务局的后台服务器的已开发票数据，判断自身是否处于可开票状态。示例性地，未上传至税务局的后台服务器的已开发票数据可以包括：离线开具的发票的限定时长、张数以及限额，其中，离线开具的发票的限定时长指的是未上传至税务局的后台服务器的已开发票中最早的开票时间与当前时间之间的时长。另外，需要说明的是，管理信息的具体内容可参考前述中关于管理信息的介绍，此处不再进行赘述。

为便于本领域技术人员理解上述方案，下面举两个具体的例子进行具体说明。例如，当地的税务局允许其管辖范围的纳税人可以在一定时长的离线时间内开具一定额度和数量的发票，以应对突发的网络通讯故障，其中，离线时间即为上述离线开具的发票的限定时长。比如说，离线时间的最长时间为2天，离线开具的发票的张数最多为10张，离线开具的发票的限额为1万元，当税控服务器发现当前时间已超过离线时间，或者本月离线开具的发票已超过10张，或者本月离线开具的发票的数额已超过1万元时，税控服务器会处于不可开票的状态，只有不违反上述离线开票的三条限制条件中的任何一条时，税控服务器才会处于可开票的状态。另外，需要说明的是，税控服务器除了会受到离线开票的限制条件限制之外，还同样会受到管理信息的限制，例如，必须同时满足每月5号前报税、已开发票的数额不超过1000张以及已开发票的数额不超过10万元，税控服务器才会处于可开票状态。其中，已开发票包括未上传的已开发票和已上传的已开发票，其中，未上传的已开发票的定义可参考前述内容，已上传的已开发票指的是已上传至税务局的后台服务器的已开发票。

又例如，当地的税务局不允许其管辖范围的纳税人离线开具发票，也就是说，纳税人的税控服务器每开出1张发票，必须将该发票的明细数据上传至税务局的后台服务器才允许其开具下一张发票。对于这种情况，可以将上述离线开具的发票的张数设置为1张，以便于税务局实时对纳税人的开票行为进行监控。

以上为对本发明实施例所提供的开票方法中步骤S5的详细介绍，为便于本领域技术人员具体实施，下面对该开票方法的其它几种可选情况进行进一步地介绍。

可选地，该开票方法还可以包括：在步骤S6之后，步骤a、税控服务器生成报送数据，并将报送数据上传至税务局的后台服务器；

具体地，报送数据包括本月已开发票的明细数据以及数据报送签名，其中，数据报送签名为经税控服务器的税控核心板中的非对称私钥加密，并经特殊算法处理后得到的本月已开发票的汇总数据。这种情况对应于已开展网络报税的地区，即纳税人不需要将税控服务器中的报送数据通过线下的方式(如，通过报税盘)上传至税务局的后台服务器，只需要通过网络将税控服务器中的报送数据上传至税务局的后台服务器，从而实现实时报税的功能。

步骤b、税控服务器根据接收到的报送数据后，对于该税控服务器相对应的管理信息进行更新，并将新的管理信息返回至税控服务器。

例如，新的管理信息包括：下一个月的报税时间、可开发票的张数以及限额。当然，在接收到税控服务器所上传的报送数据后，税务局还会将新的空白发票段、时钟校准因子等其他数据返回至税控服务器，这些数据的具体内容可参考现有技术，此处不再进行赘述。

在另外一种可选的情况中，该开票方法还可以包括：在步骤S6之后，税控服务器生成报送数据，并将报送数据写入纳税人的报税盘中；税务局将报税盘中的报送数据写入其后台服务器；税务局通过其后台服务器根据接收到的报送数据，对与该税控服务器相对应的管理信息进行更新，并将新的管理信息写入报税盘中；将报税盘中的新的管理信息写入纳税人的税控服务器中。这种情况对应于未开展网络报税的地区，即纳税人可以通过线下的方式进行报税。另外，需要说明的是，税务局除了会将新的管理信息写入报税盘之外，还会写入新的空白发票段、时间校准因子等其他信息。

在另外一种可选的情况中，该开票方法还可以包括：在步骤S6之后，步骤S7、税控服务器将已开发票的初始状态标记为未上传；步骤S8、税控服务器对各发票池进行检查，若发现未上传的已开发票已满足上传最低要求，则执行步骤S9，若未上传已开发票不满足上传最低要求，则执行步骤S10；步骤S9、税控服务器将已开发票上传至税务局的后台服务器；税务局的后台服务器向税控服务器返回上传确认消息；根据上传确认消息，税控服务器将已开发票的状态更新为已上传；步骤10、税控服务器将已开发票的状态保持为未上传。其中，最低上传要求可以为：未上传的已开发票的张数、总额度，或者未上传的已开发票中最早的一张未上传的已开发票距离当前的时间。当然，最低上传要求也可以有其他具体内容，本领域技术人员可以根据实际需要进行合理选择，此处不再一一列举。

由上述内容可知，税控服务器所开出的发票的初始状态均为未上传，只有在税控服务器获得税务局的后台服务器所返回的上传确认信息后，已开发票的状态才会更新为已上传。例如，当最低上传要求为未上传的已开发票数量为5张时，若税控服务器开出了10张发票，这10张已开发票的初始状态均被设置为未上传，然后，税控服务器对各发票池进行检查，若发现未上传的已开发票已满足上传最低要求，则按照开票的时间顺序，从这10张已开发票中选取前5张发票上传至税务局的后台服务器，并在接收到税务局的后台服务器返回的上传确认消息后，将这5张已开发票的状态更新为已上传，若未上传已开发票不满足上传最低要求，那么，保持这10张已开发票的状态均为未上传。

也就是说，若税务局允许纳税人的税控服务器离线可以开具的发票的数量最多为10张，当税控服务器未将这10张未上传的已开发票中的前5张上传至税务局的后台服务器时，税控服务器不可以在离线的状态下开具新的发票；若税控服务器已将这10张未上传的已开发票中的前5张上传至税务局的后台服务器时，则当10张已开发票中的5张发票的状态已更新为已上传后，税控服务器可以在离线的状态下开具5张新的发票。

进一步地，上述步骤S9中的税控服务器对各发票池进行检查具体可以包括：税控服务器定时对各发票池进行检查。示例性地，税控服务器可以每隔30分钟对各个发票池做一次检查。此外，在另外一种情况中，税控服务器还可以在生成发票后，还会对已生成的发票进行自动签名。在这种情况下，若税控服务器上传至税务局的后台服务器中的已开发票若无签名，则会返回签名失败的信息。如此设置，可以保证每一张上传至税务局的后台服务器中的已开发票的合法性。需要说明的是，税控服务器对未签名的发票相关数据进行签名可以通过其税控核心板完成。

此外，为便于本领域技术人员对本发明实施例所提供的开票方法的技术效果作进一步地理解，下面对上述开票方法的技术效果作如下总结：第一方面，在该开票方法中，税控服务器集中管理，极大提升了税务局和纳税人自身的税务监管能力；第二方面，税控服务器、税务局的后台服务器和开票终端通过互联网连接，极大提高了税控系统的工作效率和纳税人使用的快捷性和易用性，极大降低了双方的成本；第三方面，多税号多发票池或单税号多发票池的功能，使得大型企业更加方便快捷地进行开票点部署，中小型企业也可以通过购买或租用税控服务器中的若干个发票库或者发票池，来实现高性价比的开票点部署。

实施例二

本发明实施例提供了一种开票系统，该开票系统包括纳税人的税控服务器、各个开票点的开票终端以及税务局的后台服务器。其中，税控服务器包括申请模块、分发模块、至少一个发票池、判断模块、写入模块和反馈模块；其中，申请模块用于向税务局的后台服务器申请空白发票段；分发模块用于将申请模块所申请到的空白发票段分发到各个发票池中；判断模块用于判断税控服务器是否处于可开票状态；写入模块用于在税控服务器处于可开票状态时，允许开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中；反馈模块用于在税控服务器处于不可开票状态时，向开票终端返回不可开票的消息。税务局的后台服务器用于响应于税控服务器的申请，将空白发票段下发到税控服务器中。开票员可通过开票终端登录至发票池。

该开票系统中的税控服务器、开票终端和税务局的后台服务器相互配合，以执行实施例一所述的开票方法，因此，该开票系统具有和上述开票方法相同的有益效果，此处不再进行赘述。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种开票方法，应用于设有至少一个开票点的纳税人，各个开票点均设有开票终端，各个开票终端均与纳税人的税控服务器相连接，其特征在于，该开票方法包括：

步骤S1、税控服务器向税务局的后台服务器申请空白发票段；

步骤S2、响应于税控服务器的申请，税务局的后台服务器将空白发票段发送至税控服务器的发票库中；

步骤S3、税控服务器将发票库中的空白发票段分发到至少一个发票池中，其中，发票池设于税控服务器中；

步骤S4、开票员通过开票终端登录至发票池；

步骤S5、税控服务器判断自身是否处于可开票状态，若处于可开票状态，则执行步骤S6，若处于不可开票状态，则向开票终端返回不可开票的消息；

步骤S6、开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中，税控服务器生成发票，并将发票返回给开票终端。

2.根据权利要求1所述的开票方法，其特征在于，当税控服务器中存有税务局写入的管理信息时，步骤S5中，税控服务器根据管理信息判断自身是否处于可开票状态。

3.根据权利要求1所述的开票方法，其特征在于，当税控服务器中存有税务局写入的管理信息时，步骤S5中，税控服务器根据管理信息，以及未上传至税务局的后台服务器的已开发票数据，判断自身是否处于可开票状态。

4.根据权利要求3所述的开票方法，其特征在于，该开票方法还包括：在步骤S6之后，

税控服务器生成报送数据，并将报送数据上传至税务局的后台服务器；

税务局的后台服务器根据接收到的报送数据，对与该税控服务器相对应的管理信息进行更新，并将新的管理信息返回至税控服务器。

5.根据权利要求3所述的开票方法，其特征在于，该开票方法还包括：在步骤S6之后，

税控服务器生成报送数据，并将报送数据写入纳税人的报税盘中；

税务局将报税盘中的报送数据写入其后台服务器；

税务局通过其后台服务器根据接收到的报送数据，对与该税控服务器相对应的管理信息进行更新，并将新的管理信息写入报税盘中；

将报税盘中的新的管理信息写入纳税人的税控服务器中。

6.根据权利要求3所述的开票方法，其特征在于，该开票方法还包括：在步骤S6之后，

步骤S7、税控服务器将已开发票的初始状态标记为未上传；

步骤S8、税控服务器对各发票池进行检查，若发现未上传的已开发票已满足上传最低要求，则执行步骤S9，若未上传已开发票不满足上传最低要求，则执行步骤S10；

步骤S9、税控服务器将已开发票上传至税务局的后台服务器；税务局的后台服务器向税控服务器返回上传确认消息；根据上传确认消息，税控服务器将已开发票的状态更新为已上传；

步骤10、税控服务器将已开发票的状态保持为未上传。

7.根据权利要求6所述的开票方法，其特征在于，步骤S9中的税控服务器对各发票池进行检查具体包括：税控服务器定时对各发票池进行检查。

8.根据权利要求1的开票方法，其特征在于，该开票方法还包括：在步骤S6之后，税控服务器对已生成的发票进行自动签名。

9.根据权利要求1所述的开票方法，其特征在于，当各个发票点的开票员均配备有税控钥匙时，步骤S4具体包括：

开票员将税控钥匙插入开票终端；

税控钥匙与税控服务器进行密钥协商，对开票员的身份进行验证；

身份验证成功后，开票员通过开票终端登录至发票池中。

10.一种开票系统，其特征在于，包括纳税人的税控服务器、各个开票点的开票终端以及税务局的后台服务器；其中，

税控服务器包括申请模块、分发模块、至少一个发票池、判断模块、写入模块和反馈模块；其中，申请模块用于向税务局的后台服务器申请空白发票段；分发模块用于将申请模块所申请到的空白发票段分发到各个发票池中；判断模块用于判断税控服务器是否处于可开票状态；写入模块用于在税控服务器处于可开票状态时，允许开票员通过开票终端将待开发票的明细数据写入发票池的空白发票中；反馈模块用于在税控服务器处于不可开票状态时，向开票终端返回不可开票的消息；

税务局的后台服务器用于响应于税控服务器的申请，将空白发票段下发到税控服务器中；

开票员可通过开票终端登录至发票池。