一种数据处理方法及系统

本申请涉及数据处理技术领域，具体涉及一种数据处理方法及系统。

目前开票系统以税控盘为核心，将税控盘和用于打印发票的打印机连接到终端上，并且在终端上安装开票软件，通过安装在终端上的开票软件向税控盘发送数据读取指令来获取开票权限和开票所需的开票数据(如纳税人名称、纳税人识别号、纳税人地址、纳税人电话、开户行信息、开户账号信息、发票金额、税率等信息)，以在获取到开票权限的情况下由使用终端的用户将开票数据输入到税控盘的发票界面中相对应位置处生成发票，然后调用打印机打印纸质发票。

从上述开票系统可知，在开具任意一张发票过程中，用户都需要将开票数据输入到税控盘的发票界面中，在反复校对输入的开票数据无误的情况下开具发票，这一过程会提高开票成本以及降低开票效率。

有鉴于此，本申请提供一种数据处理方法及系统，用于自动填充开票数据至发票界面中，降低开票成本以及提高开票效率。

一方面，本申请提供一种数据处理方法，所述方法包括：

第一终端获取待处理的开票数据，生成与所述开票数据对应的开票申请请求；

第一终端发送所述开票申请请求至与所述第一终端建立通信连接的第一服务器；

第一服务器从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与所述目标税控盘通信的目标第二服务器；

第一服务器向所述目标第二服务器转发所述开票申请请求；

所述目标第二服务器确定所述开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据所述开票数据中每条数据在发票界面中的位置，将所述开票数据中的每条数据填充至所述目标税控盘提供的所述发票界面中，得到发票图像数据；

所述目标第二服务器向打印机发送打印指令，所述打印指令指示所述打印机根据所述发票图像数据打印出所述发票图像数据对应的发票。

可选的，所述方法还包括：

第一终端向所述第一服务器发送税控盘状态查询请求；

所述第一服务器向与所述第一服务器通信的各个第二服务器发送所述税控盘状态查询请求；

所述各个第二服务器分别根据所述税控盘状态查询请求和建立通信连接的税控盘的标识信息，查询进程信息中是否运行有所述建立通信连接的税控盘的进程，若运行有所述建立通信连接的税控盘的进程，向所述第一服务器发送指示税控盘处于在线状态的查询结果；

所述第一服务器将所述指示税控盘处于在线状态的查询结果发送给所述第一终端。

可选的，所述方法还包括：

所述第一服务器接收各个第二终端发送的开票申请请求，所述第二终端发送的开票申请请求中携带有开票数据；

所述第一服务器根据预设分配算法分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一终端获取待处理的开票数据，生成与所述开票数据对应的开票申请请求包括：所述第一终端从接收到的所述第二终端发送的开票申请请求中选取待处理的开票数据，生成与所选取开票数据对应的开票申请请求。

可选的，所述第一服务器根据预设分配算法分配所述各个第二终端发送的开票申请请求给所述第一终端包括如下至少一种方式：

所述第一服务器随机分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器平均分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器根据所述第一终端对应的用户权重分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器将携带有相接近的开票数据的开票申请请求分配给同一个第一终端。

可选的，所述方法还包括：

所述第一服务器若确定出当前没有处于在线状态的税控盘，向所述第一终端发送提示信息，所述提示信息用于指示启动税控盘。

另一方面，本申请还提供一种数据处理系统，所述系统包括：第一终端、第一服务器、至少两个第二服务器和至少两个税控盘，所述第二服务器和所述税控盘为一对一通信；

所述第一终端，用于获取待处理的开票数据，生成与所述开票数据对应的开票申请请求，发送所述开票申请请求至与所述第一终端建立通信连接的第一服务器；

所述第一服务器，用于从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与所述目标税控盘通信的目标第二服务器，向所述目标第二服务器转发所述开票申请请求；

所述目标第二服务器，用于确定所述开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据所述开票数据中每条数据在发票界面中的位置，将所述开票数据中的每条数据填充至所述目标税控盘提供的所述发票界面中，得到发票图像数据；

所述目标第二服务器，还用于向打印机发送打印指令，所述打印指令指示所述打印机根据所述发票图像数据打印出所述发票图像数据对应的发票。

可选的，所述第一终端，还用于向所述第一服务器发送税控盘状态查询请求；

所述第一服务器，还用于向与所述第一服务器通信的各个第二服务器发送所述税控盘状态查询请求；

所述各个第二服务器，用于分别根据所述税控盘状态查询请求和建立通信连接的税控盘的标识信息，查询进程信息中是否运行有所述建立通信连接的税控盘的进程，若运行有所述建立通信连接的税控盘的进程，向所述第一服务器发送指示税控盘处于在线状态的查询结果；

所述第一服务器，还用于将所述指示税控盘处于在线状态的查询结果发送给所述第一终端。

可选的，所述第一服务器，还用于接收各个第二终端发送的开票申请请求，所述第二终端发送的开票申请请求中携带有开票数据；

所述第一服务器，还用于根据预设分配算法分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一终端，用于从接收到的所述第二终端发送的开票申请请求中选取待处理的开票数据，生成与所选取开票数据对应的开票申请请求。

可选的，所述第一服务器以如下至少一种方式分配所述各个第二终端发送的开票申请请求给所述第一终端：

所述第一服务器随机分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器平均分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器根据所述第一终端对应的用户权重分配所述各个第二终端发送的开票申请请求给所述第一终端；

所述第一服务器将携带有相接近的开票数据的开票申请请求分配给同一个第一终端。

可选的，所述第一服务器，还用于若确定出当前没有处于在线状态的税控盘，向所述第一终端发送提示信息，所述提示信息用于指示启动税控盘。

从上述技术方案可知，第一终端获取待处理的开票数据后生成与开票数据对应的开票申请请求，并将开票申请请求发送至与第一终端建立通信连接的第一服务器，由第一服务器从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与目标税控盘通信的目标第二服务器，向目标第二服务器转发开票申请请求。目标第二服务器确定开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据开票数据中每条数据在发票界面中的位置，将开票数据中的每条数据填充至目标税控盘提供的发票界面中，得到发票图像数据，目标第二服务器向打印机发送打印指令以指示打印机根据发票图像数据打印出发票图像数据对应的发票，实现通过目标第二服务器自动填充开票数据以及自动指示打印机打印发票，完成从申请开票到打印发票的自动执行，从而降低开票成本以及提高开票效率。

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

图1为本申请实施例提供的数据处理方法对应的数据处理系统的系统架构图；

图2为本申请实施例提供的一种数据处理方法的信令图；

图3为本申请实施例提供的一种开票软件的示意图；

图4为本申请实施例提供的另一种数据处理方法的信令图。

目前开具发票过程中需要用户手动输入开票数据，然后手动触发打印机打印，这一过程会提高开票成本以及降低开票效率，为此本申请实施例提供一种数据处理方法，能够自动输入开票数据至发票界面，并自动触发打印机打印，以自动完成开票数据的输入至发票打印过程，相对应的数据处理系统的架构图如图1所示，可以包括：第一终端10、第一服务器20、第二服务器30、税控盘40和打印机50。

其中第一终端10对应需要开具发票的用户，如第一终端与财务人员对应，由财务人员对待处理的开票数据进行审核，然后对于审核通过的开票数据可以由第一终端10生成与其对应的开票申请请求，以申请开具开票数据对应的发票，开票数据包括但不限于纳税人名称、纳税人识别号、纳税人地址、纳税人电话、开户行信息、开户账号信息、发票金额、税率等。

第一服务器20，分别与第一终端10和第二服务器30建立通信连接，作为第一终端10和第二服务器30之间的通信桥梁，第一服务器20在接收到开票申请请求之后，从建立通信连接的所有第二服务器中确定出目标第二服务器，目标第二服务器则是用于处理开票申请请求的第二服务器，并向目标第二服务器转发开票申请请求。

在本实施例中，多个第一终端10可以与一个第一服务器20建立通信连接，同时多个第二服务器可以与一个第一服务器20建立通信连接，以通过一个第一服务器完成开票申请请求的转发以及从多个第二服务器中确定从目标第二服务器。

第二服务器30，与税控盘40和打印机50建立通信连接，并且第二服务器30、税控盘40和打印机50之间的关系可以是一对一关系，通过税控盘40向第二服务器30提供开票界面，以由第二服务器30自动填充开票数据至开票界面中，得到发票图像数据，然后由第二服务器30指示打印机50打印出发票图像数据对应的发票，完成开票数据的自动填充到发票的自动打印。

为更好地理解本申请实施例提供的数据处理方法，下面将结合信令图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

请参阅图2，其示出了本申请实施例提供的一种数据处理方法的信令图，可以包括以下步骤：

201：第一终端获取待处理的开票数据，生成与开票数据对应的开票申请请求。其中待处理的开票数据是由第一终端对应的用户审核通过后的数据，如由使用第一终端的财务人员对开票数据进行审核以保证要开具发票的开票数据准确无误。

相对应的开票申请请求可以是使用第一终端的用户需要开具发票过程中生成，其中第一终端可通过其安装的开票软件或通过以浏览器形式展示的开票软件生成开票申请请求，相对于安装开票软件的形式来说无需在第一终端上安装开票软件，节省第一终端的资源，开票软件可以由税控盘提供。

202：第一终端发送开票申请请求至与第一终端建立通信连接的第一服务器。

在本实施例中，第一终端生成以及向第一服务器发送开票申请请求可以通过第一终端关联的开票软件中特定控件实现，若特定控件被触发，说明当前需要开具发票，则特定控件被触发时第一终端自动生成所选择的开票数据对应的开票申请请求并自动发送至第一服务器，由此通过特定控件能够生成并发送开票申请请求，生成开票申请请求的方式是：根据第一终端和第一服务器之间的通信协议，将所选择的开票数据封装在请求中，从而得到开票申请请求。

如图3所示，在开票软件中的“开票”这一特定控件被触发的情况下，第一终端生成并向第一服务器发送开票申请请求，以指示第一服务器进行开具发票的流程。这里需要说明的一点是：第一服务器可以是一个云端服务器，通过开票软件，第一终端可以同时选择多条开票数据，从而通过开票申请请求可以申请多条开票数据的发票，以实现发票的批量开具，其中每个开票申请请求中可以携带由开票的标识信息，开票的标识信息至少用于指示开具发票的申请编号，甚至还可以指示申请开具发票的用户信息等等，本实施例不对开票的标识信息进行限定。针对图3所示，圆角矩形中的加粗字体表示当前能够被触控以执行相关操作，而正常字体表示当前不能够被触控，即便触控之后也无法执行相关操作。

第一终端在与第一服务器进行通信过程中，第一终端和第一服务器可以对通过过程中的数据进行加密，以保证数据安全型，第一终端和第一服务器采用的加密方式，本实施例不进行限定。

203：第一服务器从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与目标税控盘通信的目标第二服务器。

204：第一服务器向目标第二服务器转发开票申请请求。

其中空闲的处于在线状态的税控盘用于指示税控盘已启用但是税控盘没有处理开票操作，或者用于指示税控盘已启用但是税控盘的开票队列中已有开票申请请求的数量小于预设数量(预设数量的取值不进行限定)，从这些税控盘中选择一个目标税控盘的目的是为了提高开票申请请求的处理，以加快发票的开具速度。

在本实施例中，处于在线状态的税控盘可通过与税控盘通信的第二服务器确定并将处于在线状态的税控盘的相关信息发送给第一服务器，例如处于在线状态的税控盘的相关信息包括但不限于税控盘的标识信息和与税控盘通信的第二服务器的标识信息，以通过税控盘的标识信息和第二服务器的标识信息来指示所属的税控盘和第二服务器，从而实现对税控盘和第二服务器的区分。之所以反馈第二服务器的标识信息是因为：第二服务器与税控盘通信，由第二服务器与税控盘进行交互来完成开票，在选择出目标税控盘之后，需要获知与目标税控盘通信的第二服务器(即目标第二服务器)，所以在反馈税控盘的标识信息的同时反馈第二服务器的标识信息。

其中，第二服务器确定处于在线状态的税控盘的过程如下：

第一终端向第一服务器发送税控盘状态查询请求，第一终端可以每间隔一定时间向第一服务器发送一次税控盘状态查询请求，该税控盘状态查询请求用于查询与所有第二服务器建立通信的税控盘的状态，以确定税控盘是否在线，而每间隔一定时间发送一次税控盘状态查询请求可以对税控盘的状态更新及时监测，间隔的一定时间可以是一个固定时间(如一小时)，也可以是一个可变时间，本实施例不进行限定。

第一服务器向与第一服务器通信的各个第二服务器发送税控盘状态查询请求，与第一服务器通信的各个第二服务器的标识信息会记录在一个服务器列表中，这样第一服务器在接收到税控盘状态查询请求之后，可以向服务器列表中的所有第二服务器来转发税控盘状态查询请求，第二服务器可以是但不限于是PC(Personal Computer)服务器。

各个第二服务器分别根据税控盘状态查询请求和建立通信连接的税控盘的标识信息，查询进程信息中是否运行有建立通信连接的税控盘的进程，若运行有建立通信连接的税控盘的进程，向第一服务器发送指示税控盘处于在线状态的查询结果。一种查询进程信息中是否运行有建立通信连接的税控盘的进程的方式是：根据与第二服务器建立通信连接的税控盘的标识信息，查询进程信息中是否含有该标识信息的进程，若有说明税控盘处于在线状态。

第一服务器将指示税控盘处于在线状态的查询结果发送给第一终端，以告知使用第一终端的用户当前有税控盘处于在线状态，可以使用税控盘进行开票。

如果第一服务器确定出当前没有处于在线状态的税控盘，第一服务器还可以向第一终端发送提示信息，提示信息用于指示当前没有处于在线状态的税控盘，需要启动税控盘，对于提示信息的输出方式本实施例不进行限定，例如可以在第一终端上显示提示信息。

在本实施例中，第二服务器将用于指示税控盘处于在线状态的查询结果反馈之后，若第一服务器接收到开票申请请求，则可以从这些处于在线状态的税控盘中选择一个空闲的税控盘作为目标税控盘，甚至可以从所有处于在线状态的税控盘中选择一个相对空闲的税控盘。其中相对空闲的税控盘是指在所有处于在线状态的税控盘中开票队列中已有开票申请请求的数量小于其他税控盘的开票队列中的已有开票申请请求的数量，即选择一个当前要处理的开票申请请求最少的税控盘，从而可以提高任一开票申请请求的处理效率。

因为第二服务器与多个税控盘通信，第二服务器可以控制通信的多个税控盘处理的开票申请请求的数量，然后由第二服务器将多个税控盘当前要处理的开票申请请求的数量反馈给第一服务器，从而使得第一服务器能够实时获知税控盘中开票申请请求的数量，然后根据当前各税控盘的开票申请请求的数量来选择目标税控盘。当然第一服务器也可以为处于在线状态的税控盘分配开票申请请求，根据税控盘的处理速度预测当前处于在线状态的税控盘剩余的开票申请请求的数量(即分配给税控盘但是税控盘没有处理的请求的数量)，根据预测出的处于在线状态的税控盘剩余的开票申请请求的数量选择目标税控盘。

在确定出目标税控盘之后，第一服务器可以将开票申请请求转发给与目标税控盘通信的第二服务器，与目标税控盘通信的第二服务器可以记为目标第二服务器，以和其他第二服务器区分。第一服务器在向目标第二服务器转发开票申请请求过程中，可以对转发的数据进行加密，以保证数据安全型，第一服务器和目标第二服务器采用的加密方式，本实施例不进行限定。

205：目标第二服务器确定开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据开票数据中每条数据在发票界面中的位置，将开票数据中的每条数据填充至目标税控盘提供的发票界面中，得到发票图像数据。

其中目标税控盘提供的发票界面是由目标税控盘对应的税控软件提供，开票数据中每条数据在发票界面中的位置用于引导开票数据向发票界面中填充的过程，以使得开票数据中的每条数据都能够自动填充到其对应的位置，例如目标第二服务器通过操作系统接口获取开票界面的窗体位置，在窗体位置中模拟鼠标操作来定位开票界面中元素位置，一个元素为开票界面中的一个参数，与开票数据中的一条数据对应，然后在定位到的元素位置处通过数据拷贝来填充对应的开票数据，这一过程无需用户参与(如无需用户手动输入开票数据)，从而可以节省开票时间。

在本实施例中，开票数据中每条数据在发票界面中的位置的一种表示形式是：开票数据中的每条数据与发票界面中的元素的对应关系，以该对应关系指示每条数据在发票界面中的位置，之所以能够指示每条数据在发票界面中的位置是因为发票界面中每个元素都有各自的位置，那么在定位开票界面中对应的元素位置之后就能够确定开票数据中每条数据在发票界面中的位置，例如对于纳税人名称这条数据，其对应发票界面中元素为“纳税方的名称”，则纳税人名称这条数据在发票界面中的位置为纳税方的名称所在位置，如与纳税方的名称位于同一行且位于纳税方的名称之后。

又或者，开票数据中每条数据在发票界面中的位置的另一种表示形式是：以开票数据中每条数据在发票界面中的坐标表示，这是因为发票界面中各个元素的位置固定且发票界面的尺寸相同，所以能够通过对发票界面中各个标识符的分析确定出与其对应的每条数据在发票界面中的坐标，以指示每条数据在发票界面中的位置。

这里需要说明的一点是：在将开票数据填充至发票界面中生成的发票不是最终用于进行抵税的凭证，即填充后开票数据生成的发票图像数据不是反馈给纳税方的发票，而是一个检查开票数据是否填写正确的发票。

206：目标第二服务器向打印机发送打印指令，打印指令指示打印机根据发票图像数据打印出发票图像数据对应的发票，得到纸质发票以通过纸质发票进行抵税。

从上述技术方案可知，第一终端获取待处理的开票数据后生成与开票数据对应的开票申请请求，并将开票申请请求发送至与第一终端建立通信连接的第一服务器，由第一服务器从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与目标税控盘通信的目标第二服务器，向目标第二服务器转发开票申请请求。目标第二服务器确定开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据开票数据中每条数据在发票界面中的位置，将开票数据中的每条数据填充至目标税控盘提供的发票界面中，得到发票图像数据，目标第二服务器向打印机发送打印指令以指示打印机根据发票图像数据打印出发票图像数据对应的发票，实现通过目标第二服务器自动填充开票数据以及自动指示打印机打印发票，完成从申请开票到打印发票的自动执行，从而降低开票成本以及提高开票效率。

请参阅图4，其示出了本申请实施例提供的另一种数据处理方法，可以包括以下步骤：

401：第一服务器接收各个第二终端发送的开票申请请求，第二终端发送的开票申请请求中携带有开票数据，其中第二终端也是由用户使用的终端，但是与第一终端的不同之处在于，使用第二终端的用户不具备审核开票数据的权利，因此第二终端的用户在希望开具发票的情况下需要向第一服务器发送开票申请请求，通过第一服务器将开票申请请求中的开票数据转发给第一终端，这样使用第一终端的用户就可以对开票数据进行审核。

402：第一服务器根据预设分配算法分配各个第二终端发送的开票申请请求给第一终端。在本实施例中第一服务器根据预设分配算法分配各个第二终端发送的开票申请请求给第一终端包括如下至少一种方式：

第一服务器随机分配各个第二终端发送的开票申请请求给第一终端。

第一服务器平均分配各个第二终端发送的开票申请请求给第一终端。

第一服务器根据第一终端对应的用户权重分配各个第二终端发送的开票申请请求给第一终端，例如权重越高分配的开票申请请求越多，权重越低分配的开票申请请求越少，从而实现根据权重分配开票申请请求，之所以这样分配是因为权重越高用户审核效率以及用户对政策的了解程度越高，为这些用户分配更多的开票申请请求也能够及时完成审核。

第一服务器将携带有相接近的开票数据的开票申请请求分配给同一个第一终端，其中相接近的开票数据用于表示开票数据中存在相同的数据，如收件地址和纳税人其中至少一种相同，则可以将具有相同数据的开票申请请求分配给同一个第一终端，从而将相同数据的开票申请请求分类至不同的第一终端，节省使用第一终端的用户对开票数据的再次分类，且相同数据的开票申请请求分配至同一个第一终端，对于这些相同数据的开票申请请求可以审核至少一次即可，节省时间。

虽然第一服务器能够通过上述至少一种方式分配开票申请请求，但是在分配过程中要尽可能平衡不同第一终端分配到的开票申请请求，以使得不同的第一终端要审核的开票数据相当，避免数据分配不均衡，并且多个第一终端分配到的开票数据可以由各自对应的用户同时审核，提高审核效率，不同的开票申请请求会分配到不同的第一终端，使得使用第一终端的用户审核的开票数据不会重复，解决了重复开具发票的问题。

403：第一终端从接收到的第二终端发送的开票申请请求中选取待处理的开票数据，生成与所选取开票数据对应的开票申请请求。

404：第一终端发送开票申请请求至与第一终端建立通信连接的第一服务器。

405：第一服务器从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与目标税控盘通信的目标第二服务器。

406：第一服务器向目标第二服务器转发开票申请请求。

407：目标第二服务器确定开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据开票数据中每条数据在发票界面中的位置，将开票数据中的每条数据填充至目标税控盘提供的发票界面中，得到发票图像数据。

408：目标第二服务器向打印机发送打印指令，打印指令指示打印机根据发票图像数据打印出发票图像数据对应的发票，得到纸质发票以通过纸质发票进行抵税。

在本实施例中，上述步骤403至步骤408：与上述步骤201至步骤206相同，对此本实施例不在阐述。

第一服务器可以同时接收到多个第一终端发送的开票申请请求，第一服务器可以同时为这些开票申请请求选择出匹配的目标税控盘和目标第二服务器，通过各自匹配的目标税控盘和目标第二服务器来并行开具发票，大大提高开票速度。

与上述方法实施例相对应，本申请实施例还提供一种数据处理系统，可以包括：第一终端、第一服务器、至少两个第二服务器和至少两个税控盘，第二服务器和税控盘为一对一通信，其连接关系可参照图1。

第一终端，用于获取待处理的开票数据，生成与开票数据对应的开票申请请求，发送开票申请请求至与第一终端建立通信连接的第一服务器。

第一服务器，用于从空闲的处于在线状态的税控盘中选择一个目标税控盘以及与目标税控盘通信的目标第二服务器，向目标第二服务器转发开票申请请求。若确定出当前没有处于在线状态的税控盘，第一服务器可以向第一终端发送提示信息，提示信息用于指示启动税控盘。

目标第二服务器，用于确定开票申请请求携带的开票数据中每条数据在发票界面中的位置，根据开票数据中每条数据在发票界面中的位置，将开票数据中的每条数据填充至目标税控盘提供的发票界面中，得到发票图像数据；以及目标第二服务器，还用于向打印机发送打印指令，打印指令指示打印机根据发票图像数据打印出发票图像数据对应的发票，实现通过目标第二服务器自动填充开票数据以及自动指示打印机打印发票，完成从申请开票到打印发票的自动执行，从而降低开票成本以及提高开票效率。

在本实施例中，处于在线状态的税控盘的确定过程如下：

第一终端向第一服务器发送税控盘状态查询请求；第一服务器向与第一服务器通信的各个第二服务器发送税控盘状态查询请求；各个第二服务器分别根据税控盘状态查询请求和建立通信连接的税控盘的标识信息，查询进程信息中是否运行有建立通信连接的税控盘的进程，若运行有建立通信连接的税控盘的进程，向第一服务器发送指示税控盘处于在线状态的查询结果，通过第一服务器将指示税控盘处于在线状态的查询结果发送给第一终端，以得到每个第二服务器连接的税控盘的状态。

此外，在本实施例中，第一服务器还用于接收各个第二终端发送的开票申请请求，第二终端发送的开票申请请求中携带有开票数据，其中第二终端也是由用户使用的终端，但是与第一终端的不同之处在于，使用第二终端的用户不具备审核开票数据的权利，因此第二终端的用户在希望开具发票的情况下需要向第一服务器发送开票申请请求，通过第一服务器将开票申请请求中的开票数据转发给第一终端，这样使用第一终端的用户就可以对开票数据进行审核。

第一服务器，还用于根据预设分配算法分配各个第二终端发送的开票申请请求给第一终端。例如通过如下至少一种分配各个第二终端发送的开票申请请求给第一终端：

第一服务器随机分配各个第二终端发送的开票申请请求给第一终端；第一服务器平均分配各个第二终端发送的开票申请请求给第一终端；第一服务器根据第一终端对应的用户权重分配各个第二终端发送的开票申请请求给第一终端；第一服务器将携带有相接近的开票数据的开票申请请求分配给同一个第一终端。

在第一终端接收到开票申请请求之后，第一终端从接收到的第二终端发送的开票申请请求中选取待处理的开票数据，生成与所选取开票数据对应的开票申请请求，触发开票流程。

上述第一终端、第一服务器、至少两个第二服务器和至少两个税控盘的执行过程的说明请参见方法实施例，对此本实施例不在阐述。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。