CN110880131A - 一种发票的生成方法及装置 - Google Patents

Abstract

本发明公开了一种发票的生成方法及装置，方法包括离线开票方法和实时开票方法，离线开票方法包括：发票系统接收离线开票请求，根据离线开票请求中第一交易流水数据的标识，从非关系型数据库中获取第一交易流水数据，对第一交易流水数据进行离线开票，将第一交易流水数据对应的发票数据存储至非关系型数据库，该技术方案用于提高发票系统查询交易流水数据的速度，保障开票效率。实时开票方法包括：发票系统通过消息中间件接收实时开票请求，对实时开票请求中第三交易流水数据进行实时开票，将第三交易流水数据对应的发票数据存储至非关系型数据库，该技术方案用以减少数据传输量，且实现异步进行开票处理和通知业务系统。

Description

一种发票的生成方法及装置

技术领域

本发明实施例涉及金融科技(Fintech)领域，尤其涉及一种发票的生成方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Finteh)转变，大数据技术也不例外，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。

现有技术中，业务系统将生成的交易流水数据存储在关系型数据库中，发票系统需要开发票时，从该关系型数据库中查询交易流水数据，并根据查询到的交易流水数据开发票。在关系型数据库中，一旦存储有亿级以上海量交易流水数据，则从关系型数据库中查询交易流水数据的速度变慢，开票效率低。

发明内容

本发明实施例提供一种发票的生成方法及装置，用以解决发票系统从关系型数据库中查询交易流水数据速度慢，导致开票效率低的问题。

本发明实施例提供的一种发票的生成方法，包括：

发票系统接收离线开票请求，所述离线开票请求中包括第一交易流水数据的标识；

所述发票系统根据所述第一交易流水数据的标识，从非关系型数据库中获取所述第一交易流水数据；所述第一交易流水数据是由业务系统生成并经所述发票系统进行批处理后存储至所述非关系型数据库中；

所述发票系统对所述第一交易流水数据进行离线开票，将生成的所述第一交易流水数据对应的发票数据存储至所述非关系型数据库中。

上述技术方案中，发票系统将接收到的交易流水数据存储在非关系数据库中，在需要对交易流水数据进行离线开票时，可以直接从非关系数据库中查询离线开票请求对应的交易流水数据，非关系数据库可以支持快速查找交易流水数据，在非关系数据库中存储有亿级以上的交易流水数据时，仍保持毫秒级的查询速度，保障开票效率。

可选的，还包括：

所述发票系统在确定批处理操作规则由第一规则变为第二规则后，若确定所述非关系型数据库中存在已完成所述第一规则的批处理但尚未开票的第二交易流水数据，则基于所述第二规则，对所述第二交易流水数据重新进行批处理；

所述发票系统将与所述第一规则批处理后的第二交易流水数据存在差异的所述第二规则批处理后的第二交易流水数据更新至所述非关系型数据库中。

上述技术方案中，基于重复批处理后差异化对比，实现在非关系型数据库中存储的批处理后的交易流水数据为符合最新批处理操作规则的数据，且在非关系数据库中只更新前后批处理后的差异化数据，可以提高非关系数据库中的更新效率。

可选的，所述非关系型数据库为Hbase；

交易流水数据的标识和交易流水数据构成Key-Value的键值对；其中，交易流水数据的标识包括客户标识号的后N位数+客户标识号+交易日期+交易流水号；N为正整数；

发票数据的编号和发票数据构成为Key-Value键值对。

上述技术方案中，通过交易流水数据的标识和交易流水数据构成的Key-Value的键值对形式，在开票查询时，客户标识号的后N位数用于进行前缀模糊查询，客户标识号作为第一查询条件，交易日期作为第二查询条件，交易流水号用于唯一确定第一交易流水数据，实现交易流水数据在Hbase中达到毫秒级查询的效率。通过发票数据的编号和发票数据构成的Key-Value的键值对形式，在发票数据查询时，同样可以实现在Hbase中达到毫秒级查询的效率。

可选的，还包括：

所述发票系统接收实时开票请求；所述实时开票请求中包括第三交易流水数据；所述实时开票请求是所述业务系统经消息中间件发送至所述发票系统的；

所述发票系统对所述第三交易流水数据进行实时开票，将生成的所述第三交易流水数据对应的发票数据存储至所述非关系型数据库中。

上述技术方案中，在业务系统请求发票系统进行实时开票时，采用消息中间件将业务系统和发票系统进行对接，相比于现有技术中发票系统采用WebService作为与业务系统对接的接口，无需采用XML格式封装数据，且无需传输标签，而是将实时开票请求转换成JSON字符串格式，传输数据量少，且可以通过消息中间件实现异步进行开票处理和通知业务系统，且消息中间件可以提供业务系统基于交易流水号随时可查询当前开票或者已开票未接收到的发票数据，支持高并发，高可靠性。

可选的，所述发票系统对所述第三交易流水数据进行实时开票之前，还包括：

所述发票系统通过关系型数据库确定所述第三交易流水数据的开票状态，并根据所述第三交易流水的开票状态确定对所述第三交易流水数据进行实时开票；所述关系型数据库中存储有交易流水数据的标识与开票状态的对应关系；

所述发票系统对所述第三交易流水数据进行实时开票之后，还包括：

所述发票系统在所述关系型数据库中更新所述第三交易流水数据的开票状态。

上述技术方案中，对交易流水数据的开票状态执行实时跟踪，即更新每次操作后的交易流水数据的开票状态，在发票系统对交易流水数据进行实时开票时，验证交易流水数据的开票状态，既保障与实时开票的数据不重复，与离线开票的数据不重复，又保障保证已红冲的数据能够重开。

可选的，所述发票系统对所述第一交易流水数据进行离线开票之前，还包括：

所述发票系统对所述第一交易流水数据加锁处理，用于防止所述发票系统对所述第一交易流水数据进行并发开票；

所述发票系统对所述第三交易流水数据进行实时开票之前，还包括：

所述发票系统对所述第三交易流水数据加锁处理，用于防止所述发票系统对所述第三交易流水数据进行并发开票。

上述技术方案中，对交易流水数据进行加锁处理以避免交易流水数据并发开票。

可选的，所述发票系统生成所述第一交易流水数据对应的发票数据之后，还包括：

所述发票系统调用第一任务将所述第一交易流水数据对应的发票数据发送至所述业务系统；

所述发票系统调用第二任务将所述第一交易流水数据对应的发票数据发送至生成服务器，以使所述生成服务器根据所述第一交易流水数据对应的发票数据生成所述第一交易流水数据对应的发票文件；

所述发票系统调用第三任务将所述第一交易流水数据对应的发票文件发送至签章系统，以使所述签章系统对所述第一交易流水数据对应的发票文件签章；

所述发票系统调用第四任务将已签章的所述第一交易流水数据对应的发票文件发送至客户邮箱。

上述技术方案中，调用多个任务实现异步处理，各任务之间不干扰。

相应的，本发明实施例还提供了一种发票的生成装置，包括：

接收单元、处理单元；

所述接收单元，用于接收离线开票请求，所述离线开票请求中包括第一交易流水数据的标识；

所述处理单元，用于根据所述第一交易流水数据的标识，从非关系型数据库中获取所述第一交易流水数据；所述第一交易流水数据是由业务系统生成并经所述发票系统进行批处理后存储至所述非关系型数据库中；

所述处理单元，还用于对所述第一交易流水数据进行离线开票，将生成的所述第一交易流水数据对应的发票数据存储至所述非关系型数据库中。

可选的，所述处理单元还用于：

在确定批处理操作规则由第一规则变为第二规则后，若确定所述非关系型数据库中存在已完成所述第一规则的批处理但尚未开票的第二交易流水数据，则基于所述第二规则，对所述第二交易流水数据重新进行批处理；

将与所述第一规则批处理后的第二交易流水数据存在差异的所述第二规则批处理后的第二交易流水数据更新至所述非关系型数据库中。

可选的，所述非关系型数据库为Hbase；

交易流水数据的标识和交易流水数据构成Key-Value的键值对；其中，交易流水数据的标识包括客户标识号的后N位数+客户标识号+交易日期+交易流水号；N为正整数；

发票数据的编号和发票数据构成为Key-Value键值对。

可选的，所述接收单元还用于接收实时开票请求；所述实时开票请求中包括第三交易流水数据；所述实时开票请求是所述业务系统经消息中间件发送至所述发票系统的；

所述处理单元还用于对所述第三交易流水数据进行实时开票，将生成的所述第三交易流水数据对应的发票数据存储至所述非关系型数据库中。

可选的，所述处理单元还用于对所述第三交易流水数据进行实时开票之前，通过关系型数据库确定所述第三交易流水数据的开票状态，并根据所述第三交易流水的开票状态确定对所述第三交易流水数据进行实时开票；所述关系型数据库中存储有交易流水数据的标识与开票状态的对应关系；

所述处理单元还用于对所述第三交易流水数据进行实时开票之后，在所述关系型数据库中更新所述第三交易流水数据的开票状态。

可选的，所述处理单元还用于对所述第一交易流水数据进行离线开票之前，对所述第一交易流水数据加锁处理，用于防止所述发票系统对所述第一交易流水数据进行并发开票；

所述处理单元还用于对所述第三交易流水数据进行实时开票之前，对所述第三交易流水数据加锁处理，用于防止所述发票系统对所述第三交易流水数据进行并发开票。

可选的，所述处理单元还用于：

生成所述第一交易流水数据对应的发票数据之后，调用第一任务将所述第一交易流水数据对应的发票数据发送至所述业务系统；

调用第二任务将所述第一交易流水数据对应的发票数据发送至生成服务器，以使所述生成服务器根据所述第一交易流水数据对应的发票数据生成所述第一交易流水数据对应的发票文件；

调用第三任务将所述第一交易流水数据对应的发票文件发送至签章系统，以使所述签章系统对所述第一交易流水数据对应的发票文件签章；

调用第四任务将已签章的所述第一交易流水数据对应的发票文件发送至客户邮箱。

相应的，本发明实施例还提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述发票的生成方法。

相应的，本发明实施例还提供了一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行上述发票的生成方法。

附图说明

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

图1为本发明实施例提供的一种系统架构的示意图；

图2为本发明实施例提供的一种离线发票的生成方法的流程示意图；

图3为本发明实施例提供的另一种离线发票的生成方法的流程示意图；

图4为本发明实施例提供的一种实时发票的生成方法的流程示意图；

图5为本发明实施例提供的另一种实时发票的生成方法的流程示意图；

图6为本发明实施例提供的一种发票的生成装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1示例性的示出了本发明实施例提供的一种发票的生成方法所适用的系统架构，该系统架构可以包括业务系统100、发票系统200、签章系统300、邮件发送系统400、生成服务器500。

业务系统100与发票系统200连接，发票系统200用于对业务系统100生成的交易流水数据开具发票，开票方式至少有两种，分别为离线开票和实时开票。离线开票指的是，业务系统100将交易流水数据批量发送至发票系统200，发票系统200对交易流水数据进行批处理后存储至数据库中，工作人员可以通过发票系统200提供的前端页面查询交易流水数据并连接税务系统进行开票。实时开票指的是，业务系统100向发票系统200发送实时开票请求，发票系统200基于实时开票请求中的交易流水数据连接税务系统进行开票。

发票系统200分别与签章系统300、邮件发送系统400、生成服务器500连接；发票系统200通过生成服务器500生成发票文件，如生成PDF格式的发票文件；发票系统200通过签章系统300对生成的发票文件进行签章；发票系统200通过邮件发送系统400将签章后的发票文件发送至客户邮箱。

税务系统可以是基于区块链技术构建的，本发明实施例中的发票系统200可以作为区块链发票系统连接税务系统，开具的发票具有流程完整追溯、信息不可篡改等特性，能够有效规避假发票，完善发票监管流程。

基于上述描述，图2示例性的示出了本发明实施例提供的一种发票的生成方法的流程，该流程可以由发票的生成装置执行。该流程的执行主体可以是发票系统。

如图2所示，该流程具体包括：

步骤201，发票系统接收离线开票请求。

离线开票请求中包括第一交易流水数据的标识，离线开票请求用于指示发票系统根据第一交易流水数据的标识确定出第一交易流水数据，并生成第一交易流水数据对应的发票。第一交易流水数据是由业务系统生成并经发票系统进行批处理后存储至非关系型数据库中的。

具体实现方式中，业务系统生成的交易流水数据中可以包括交易流水号、开票编码、客户信息、交易金额、免税标识等信息，其中，开票编码通过产品标识、部门标识、收入记账科目等多个纬度来唯一对应，开票编码可以用于数据权限的隔离，以保障数据的安全性。

业务系统将生成的交易流水数据组成交易流水信息表，并根据交易流水信息表中的接口表字段要求推送预设时段的交易流水数据至发票系统中，以使发票系统对接收到的交易流水数据进行处理。此处，业务系统可以在T日根据接口表字段要求推送T－1日的交易流水数据至发票系统。

发票系统在接收到业务系统生成并发送的交易流水数据后，对该交易流水数据进行批处理，并将批处理后的交易流水数据存储至非关系型数据库中。

本发明实施例中，发票系统可以对交易流水数据进行重复批处理操作，相当于发票系统可以对相同的交易流水数据进行多次批处理操作。发票系统在接收到交易流水数据后，会根据当前的批处理操作规则对交易流水数据进行批处理，生成批处理后的交易流水数据，但是，该批处理后的交易流水数据可能不会被及时开票，比如，可能是在对该交易流水数据批处理完成之后的几天、甚至一个月、几个月之后才会被开票，在此期间，若批处理操作规则发生变化(如税务政策发生变化、产品发生变化又或者系统发生变化)，都有可能需要对已经批处理后的交易流水数据重新进行批处理。一种实现方式中，可以是将发生变化前的批处理规则定义为第一规则，将发生变化后的批处理规则定义为第二规则，将非关系型数据库中存在的已完成第一规则的批处理但尚未开票的交易流水数据定义为第二交易流水数据，发票系统在确定批处理操作规则由第一规则变为第二规则后，若确定非关系型数据库中存在第二交易流水数据，则基于第二规则，对第二交易流水数据重新进行批处理，发票系统将与第一规则批处理后的第二交易流水数据存在差异的第二规则批处理后的第二交易流水数据更新至非关系型数据库中。基于重复批处理后差异化对比，实现在非关系型数据库中存储的批处理后的交易流水数据为符合最新批处理操作规则的数据，且在非关系数据库中只更新两次批处理后的差异化数据，可以提高非关系数据库中的更新效率。

举例来说，发票系统对交易流水数据N0进行第一次批处理，并将第一次批处理后的数据记为N1，将第一次批处理后的数据N1存储在非关系型数据库中且尚未开票，发票系统在确定批处理操作规则发生变化后，基于发生变化后的批处理操作规则对交易流水数据N0进行第二次批处理，并将第二次批处理后的数据记为N2，发票系统对比第一次批处理后的数据N1和第二次批处理后的数据N2，并将差异化的数据同步至非关系型数据库中，比如，确定差异化的数据为N2a，则将N2a更新至非关系型数据库中(替换第一次批处理后的数据N1中与N2a对应的数据)。同理，若第二次批处理后的数据N2仍未被开票，发票系统在确定批处理操作规则再次发生变化后，则基于再次发生变化后的批处理操作规则对交易流水数据N0进行第三次批处理，并将第三次批处理后的数据记为N3，发票系统对比第二次批处理后的数据N2和第三次批处理后的数据N3，将差异化的数据同步至非关系型数据库中。

具体实现中，业务系统可以将交易流水数据推送至Hive中，并发送通知信号至发票系统，发票系统在接收到通知信号后，从Hive中获取交易流水数据，将交易流水数据Sqoop至Oracle交易流水接口表，Oracle将交易流水数据加工处理成可正式开票的交易流水数据，发票系统在Oracle中将交易流水数据加工处理完成后，将处理后的交易流水数据Sqoop回Hive，通过BulkLoad的批量方式加载至Hbase。发票系统在确定批处理操作规则变化时，调用Oracle对交易流水数据重复加工，并将两次加工后的数据都同步至Oracle进行比对，并将差异的数据同步至Hbase中。

步骤202，发票系统根据第一交易流水数据的标识，从非关系型数据库中获取第一交易流水数据。

本发明实施例中，非关系型数据库可以是Hbase，Hbase中存储有的交易流水数据的标识和交易流水数据构成Key-Value的键值对，其中，交易流水数据的标识(即Key值)包括客户标识号(客户号、客户编号、客户号码)的后N位数+客户标识号+交易日期+交易流水号，其中，客户标识号的后N位数实现交易流水数据的离散性，交易流水号实现交易流水数据的唯一性；N为正整数，N的取值可以根据经验需求确定，N可以等于4。

通过该交易流水数据的标识和交易流水数据构成的Key-Value的键值对形式，在开票查询时，客户标识号的后N位数用于进行前缀模糊查询，客户标识号作为第一查询条件，交易日期作为第二查询条件，交易流水号用于唯一确定第一交易流水数据，实现交易流水数据在Hbase中达到毫秒级查询的效率。具体操作中，发票系统的工作人员在发票系统的前端界面输入具体的客户标识号和交易日期，则发票系统即可以返回从Hbase中查询到的所有未开发票的第一交易流水数据，考虑到发票系统的前端界面可以是Web页面，则业务系统在返回第一交易流水数据时，会先将第一交易流水数据缓存至内存，用Java进行分页处理后在Web页面上展示。

步骤203，发票系统对第一交易流水数据进行离线开票，将生成的第一交易流水数据对应的发票数据存储至非关系型数据库中。

本发明实施例中，Hbase中不仅存储有交易流水数据的标识和交易流水数据构成的Key-Value的键值对，还存储有发票数据的编号和发票数据构成的Key-Value键值对。发票系统在对第一交易流水数据对应的发票数据进行查询时，发票系统可以直接根据第一交易流水数据对应的发票数据对应的Key值从Hbase中查询该第一交易流水数据对应的发票数据。

此外，发票系统在对第一交易流水数据进行离线开票之前，可以对第一交易流水数据进行加锁处理，该加锁处理用于防止发票系统对第一交易流水数据进行并发开票，此处的并发开票可以理解为多用户同时离线开票或者实时开票。一种实现方式中，发票系统可以连接Redis集群，对第一交易流水数据进行Redis加锁处理，若成功获取锁，才会连接税务系统开票。此处，对交易流水数据进行加锁处理以避免交易流水数据并发开票的实现方式同样适用于实时开票情况。

举例来说，业务系统将前一天的交易流水数据提交至发票系统，发票系统将前一天的交易流水数据存储在Hbase中，工作人员在发票系统的前端界面查询该前一天的交易流水数据并开发票，比如，该前一天的交易流水数据中包括交易流水数据a；业务系统同时向发票系统发送实时开票请求，其中，该实时开票请求中包括交易流水数据a，则此时，就可能存在发票系统在离线开票和实时开票两种情况下同时对交易流水数据a开发票(并发开票)，所以，需要在发票系统确定对某个交易流水数据开发票时，先对该交易流水数据加锁，在加锁成功后，才会进一步开发票，以避免该交易流水数据出现并发开票的情况。

发票系统在生成第一交易流水数据对应的发票数据之后，还可以调用任务集群异步处理以下步骤：

(1)调用第一任务将第一交易流水数据对应的发票数据发送至业务系统；

(2)调用第二任务将第一交易流水数据对应的发票数据发送至生成服务器，以使生成服务器根据第一交易流水数据对应的发票数据生成第一交易流水数据对应的发票文件；发票文件可以是PDF格式的发票文件；

(3)调用第三任务将第一交易流水数据对应的发票文件发送至签章系统，以使签章系统对第一交易流水数据对应的发票文件签章；

(4)调用第四任务将已签章的第一交易流水数据对应的发票文件发送至客户邮箱。

发票系统调用的各个任务可以是定时任务，每个任务定时执行，比如，第一任务定时扫描已开发票的发票数据，并将扫描到的发票数据发送至业务系统。各个定时任务对应的间隔时长可以相同也可以不同，比如，各定时任务都可以是每隔5min执行一次，也可以是第一定时任务每隔1min执行一次，第二定时任务每隔2min执行一次等。发票系统调用的各个任务也可以不是定时任务，比如，发票系统在接收到第一指令后调用第一任务，在接收到第二指令后调用第二任务等。

举例来说，发票系统基于Quartz实现分布式定时任务集群，发票系统的第一定时任务每隔5min会扫描已开发票的发票数据，并将扫描到的已开发票的发票数据广播通知至各个业务系统。发票系统的第二定时任务每隔5min开启一次批量处理已开发票但未生成PDF发票文件的数据来生成PDF发票文件，并上传至FPS文件服务器存储。发票系统的第三定时任务每隔5min调用打印签章的签章系统，为PDF发票文件打印上签章水印。发票系统的第四定时任务每隔5min发送一次发票文件至客户邮箱。每一步都是异步处理。

当然，上述实施例还可以采用同步机制，发票系统调用一个任务用于在将第一交易流水数据对应的发票数据发送至业务系统之后，将第一交易流水数据对应的发票数据发送至生成服务器，在生成服务器生成第一交易流水数据对应的发票文件之后，将第一交易流水数据对应的发票文件发送至签章系统，以及在签章系统对第一交易流水数据对应的发票文件签章之后，将已签章的第一交易流水数据对应的发票文件发送至客户邮箱。

为了更好的解释本发明实施例，下面将在具体的实施场景下描述该离线发票的生成流程，该流程图涉及业务系统、Hive、Hbase、发票系统。

如图3所示，具体如下：

步骤301，业务系统发送交易流水数据至Hive；

步骤302，业务系统发送通知信号至发票系统；

步骤303，发票系统向Hive发送批处理指令；

步骤304，Hive根据批处理操作规则对交易流水数据进行批处理；

步骤305，Hive将批处理后的交易流水数据加载至Hbase中；

步骤306，发票系统在确定批处理操作规则发生变化时，向Hive发送重新进行批处理的指令；

步骤307，Hive根据变化后的批处理操作规则对已经批处理完成但尚未开票的交易流水数据进行重新批处理，生成重新批处理后的交易流水数据；

步骤308，Hive比对两次批处理后的交易流水数据，确定差异数据；

步骤309，Hive将差异数据同步至Hbase中；

工作人员在发票系统的前端界面查询交易流水数据进行离线开票时，则有下述步骤：

步骤310，发票系统向Hbase发送查询指令；

步骤311，Hbase根据查询指令查询对应的交易流水数据；

步骤312，Hbase将查询指令对应的交易流水数据发送至发票系统；

步骤313，发票系统对交易流水数据进行Redis加锁处理；

步骤314，发票系统连接税务系统开票；

步骤315，发票系统将发票数据发送至业务系统；

步骤316，发票系统生成发票数据对应的发票文件，对发票文件打印签章，发送签章后的发票文件至客户邮箱。

上述实施例中，发票系统将接收到的交易流水数据存储在非关系数据库中，在需要对交易流水数据离线开票时，可以直接从非关系数据库中查询离线开票请求对应的交易流水数据，非关系数据库可以支持快速查找交易流水数据，在非关系数据库中存储有亿级以上的交易流水数据时，仍保持毫秒级的查询速度，保障开票效率。

上述实施例已经详细描述了发票系统在接收到离线开票请求后，进行离线开票的过程，本发明实施例中的发票系统还可以实现实时开票，具体流程可以如图4所示，该流程的执行主体仍是发票系统。

步骤401，发票系统接收实时开票请求。

本发明实施例中，业务系统可以通过消息中间件与发票系统连接，业务系统作为消息生产者向消息中间件中发送实时开票请求，发票系统作为消息消费者从消息中间件中获取实时开票请求并进行业务逻辑处理。实时开票请求中包括第三交易流水数据，用于指示发票系统根据第三交易流水数据进行实时开票。

具体实现中，业务系统根据发票唯一标识、交易流水号、客户信息、开票编码、交易金额、免税标识等信息生成用于请求实时开票的JSON字符串，并基于消息中间件模式，向发票系统请求实时开票。

采用消息中间件接收业务系统的实时发票请求，并通过队列机制可以异步进行开票处理和通知业务系统，且消息中间件可以提供业务系统基于交易流水号随时可查询当前开票或者已开票未接收到的发票数据，支持高并发，高可靠性。

步骤402，发票系统对第三交易流水数据进行实时开票，将生成的第三交易流水数据对应的发票数据存储至非关系型数据库中。

发票系统在对第三交易流水数据进行实时开票之前，可以对第三交易流水数据进行加锁处理，该加锁处理用于防止发票系统对第三交易流水数据进行并发开票，此处的并发开票可以理解为多用户同时实时开票或者离线开票。一种实现方式中，发票系统可以连接Redis集群，对第三交易流水数据进行Redis加锁处理，若成功获取锁，则连接税务系统开票，否则直接返回处理失败。

发票系统对第三交易流水数据进行实时开票之前会先对第三交易流水数据进行验证，在验证通过后，才会对第三交易流水数据进行实时开票。一种验证方式，可以是对第三交易流水数据中的一些基本信息的进行验证，如验证第三交易流水数据中的开票金额是否超出最大单张发票开票限额，是否超出指定行，金额是否合法，第三交易流水数据中的信息是否完整等。

另一种校验方式，可以是对第三交易流水数据的开票状态进行验证，具体的，发票系统通过关系型数据库确定第三交易流水数据的开票状态，并根据第三交易流水的开票状态确定是否对第三交易流水数据进行实时开票。关系型数据库中存储有交易流水数据的标识与开票状态的对应关系，开票状态可以有多种，分别是未开票、开票中、已开票、红冲中、已红冲、开票失败，其中，未开票指示尚未对交易流水数据进行开发票的操作，可以进行实时开票；开票中、已开票、红冲中指示不能对交易流水数据进行实时开票；已红冲和开票失败指示可以对交易流水数据进行实时开票。基于该校验方式，发票系统在对第三交易流水数据进行实时开票之后，同样需要在关系型数据库中更新第三交易流水数据的开票状态。

上述实施例中，对交易流水数据的开票状态执行实时跟踪，即更新每次操作后的交易流水数据的开票状态，在发票系统对交易流水数据进行实时开票时，验证交易流水数据的开票状态，既保障与实时开票的数据不重复，与离线开票的数据不重复，又保障保证已红冲的数据能够重开。

发票系统可以对第三交易流水数据执行上述两种验证中的任一个，也可以同时执行上述两种验证。在验证通过后，发票系统将第三交易流水数据存储至关系数据库，并将关系数据库作为队列提供存储机制，将发票唯一标识、创建时间、更新时间、队列数据处理状态存储至队列表，同步通知业务系统已接收处理中。此处的关系数据库可以是MySQL数据库，根据队列的先进先出原则，对处理队列中的交易流水数据依次处理，而且为了避免集群并发处理同一数据的问题，加入了乐观锁机制来提高可靠性，任务每30s启动一次，以创建时间字段为标识获取最早时间的交易流水数据，以更新时间作为Version字段值，若更新成功，则请求税务系统进行开票处理，更新失败则不做任何处理。此外，本发明实施例中，还可以用悲观锁来替代乐观锁，实现对交易流水数据的加锁；可以采用Kafka队列替代MySQL队列，以存储交易流水数据。

具体实现中，MySQL数据库用于存储交易流水数据、队列数据及开票记录等，Oracle数据库用于存储客户信息、配置表信息、流水处理状态表信息等，发票系统根据第三交易流水数据的标识从MySQL数据库、Oracle数据库中获取用于开票的信息进行开票，并将开票后的信息同步提交至MySQL数据库和Oracle数据库中，此操作过程可以是采用druid+Atomikos来保证事务处理的一致性。

发票系统在生成第三交易流水数据对应的发票数据之后，还可以调用任务集群，异步处理以下步骤：调用第一任务将第三交易流水数据对应的发票数据发送至业务系统；调用第二任务将第三交易流水数据对应的发票数据发送至生成服务器，以使生成服务器根据第三交易流水数据对应的发票数据生成第三交易流水数据对应的发票文件；调用第三任务将第三交易流水数据对应的发票文件发送至签章系统，以使签章系统对第三交易流水数据对应的发票文件签章；调用第四任务将已签章的第三交易流水数据对应的发票文件发送至客户邮箱。该具体实现方式与上述发票系统在生成第一交易流水数据对应的发票数据之后，执行的异步处理相似，再次不再赘述。

为了更好的解释本发明实施例，下面将在具体的实施场景下描述该发票的生成流程，该流程图涉及业务系统、消息中间件、发票系统、关系型数据库。

如图5所示，具体如下：

步骤501，业务系统向消息中间件发送实时开票请求；

步骤502，发票系统从消息中间件中获取实时开票请求；

步骤503，发票系统对交易流水数据进行Redis加锁处理；

步骤504，发票系统对交易流水数据验证后确定开票；

步骤505，发票系统将交易流水数据加入至关系数据库队列中等待处理；

步骤506，发票系统发送开票响应至消息中间件；

步骤507，业务系统从消息中间件中获取开票响应；

步骤508，发票系统通过乐观锁获取关系数据库队列中交易流水数据；

步骤509，发票系统连接税务系统开票；

步骤510，发票系统将发票数据发送至业务系统；

步骤511，发票系统生成发票数据对应的发票文件，对发票文件打印签章，发送签章后的发票文件至客户邮箱。

上述实施例中，在业务系统请求发票系统进行实时开票时，采用消息中间件将业务系统和发票系统进行对接，相比于现有技术中发票系统采用WebService作为与业务系统对接的接口，无需采用XML格式封装数据，且无需传输标签，而是将实时开票请求转换成JSON字符串格式，传输数据量少，且可以通过消息中间件实现异步进行开票处理和通知业务系统，且消息中间件可以提供业务系统基于交易流水号随时可查询当前开票或者已开票未接收到的发票数据，支持高并发，高可靠性。

本发明实施例中，发票系统可以对应多个业务系统，每个业务系统都可以向发票系统发送与该业务系统对应的开票请求(包括离线开票请求或者实时开票请求)，发票系统在针对每个业务系统发送的开票请求开票后，会将开票后的发票数据定向返回至请求方，也即定向返回至请求开票的业务系统，比如，业务系统A向发票系统请求交易流水数据a的开票，则发票系统生成与交易流水数据a相对应的发票数据后，会将该发票数据定向返回至业务系统A，而不会返回至业务系统B或业务系统C等，通过该方式，可以保障业务系统的数据的安全性。

基于同一发明构思，图6示例性的示出了本发明实施例提供的一种发票的生成装置的结构，该装置可以执行发票的生成方法的流程。

该装置包括：

接收单元601、处理单元602；

所述接收单元601，用于接收离线开票请求，所述离线开票请求中包括第一交易流水数据的标识；

所述处理单元602，用于根据所述第一交易流水数据的标识，从非关系型数据库中获取所述第一交易流水数据；所述第一交易流水数据是由业务系统生成并经所述发票系统进行批处理后存储至所述非关系型数据库中；

所述处理单元602，还用于对所述第一交易流水数据进行离线开票，将生成的所述第一交易流水数据对应的发票数据存储至所述非关系型数据库中。

可选的，所述处理单元602还用于：

在确定批处理操作规则由第一规则变为第二规则后，若确定所述非关系型数据库中存在已完成所述第一规则的批处理但尚未开票的第二交易流水数据，则基于所述第二规则，对所述第二交易流水数据重新进行批处理；

将与所述第一规则批处理后的第二交易流水数据存在差异的所述第二规则批处理后的第二交易流水数据更新至所述非关系型数据库中。

可选的，所述非关系型数据库为Hbase；

交易流水数据的标识和交易流水数据构成Key-Value的键值对；其中，交易流水数据的标识包括客户标识号的后N位数+客户标识号+交易日期+交易流水号；N为正整数；

发票数据的编号和发票数据构成为Key-Value键值对。

可选的，所述接收单元601还用于接收实时开票请求；所述实时开票请求中包括第三交易流水数据；所述实时开票请求是所述业务系统经消息中间件发送至所述发票系统的；

所述处理单元602还用于对所述第三交易流水数据进行实时开票，将生成的所述第三交易流水数据对应的发票数据存储至所述非关系型数据库中。

可选的，所述处理单元602还用于对所述第三交易流水数据进行实时开票之前，通过关系型数据库确定所述第三交易流水数据的开票状态，并根据所述第三交易流水的开票状态确定对所述第三交易流水数据进行实时开票；所述关系型数据库中存储有交易流水数据的标识与开票状态的对应关系；

所述处理单元602还用于对所述第三交易流水数据进行实时开票之后，在所述关系型数据库中更新所述第三交易流水数据的开票状态。

可选的，所述处理单元602还用于对所述第一交易流水数据进行离线开票之前，对所述第一交易流水数据加锁处理，用于防止所述发票系统对所述第一交易流水数据进行并发开票；

所述处理单元602还用于对所述第三交易流水数据进行实时开票之前，对所述第三交易流水数据加锁处理，用于防止所述发票系统对所述第三交易流水数据进行并发开票。

可选的，所述处理单元602还用于：

生成所述第一交易流水数据对应的发票数据之后，调用第一任务将所述第一交易流水数据对应的发票数据发送至所述业务系统；

调用第二任务将所述第一交易流水数据对应的发票数据发送至生成服务器，以使所述生成服务器根据所述第一交易流水数据对应的发票数据生成所述第一交易流水数据对应的发票文件；

调用第三任务将所述第一交易流水数据对应的发票文件发送至签章系统，以使所述签章系统对所述第一交易流水数据对应的发票文件签章；

调用第四任务将已签章的所述第一交易流水数据对应的发票文件发送至客户邮箱。

基于同一发明构思，本发明实施例还提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述发票的生成方法。

基于同一发明构思，本发明实施例还提供了一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行上述发票的生成方法。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种发票的生成方法，其特征在于，所述方法包括：

发票系统接收离线开票请求，所述离线开票请求中包括第一交易流水数据的标识；

所述发票系统根据所述第一交易流水数据的标识，从非关系型数据库中获取所述第一交易流水数据；所述第一交易流水数据是由业务系统生成并经所述发票系统进行批处理后存储至所述非关系型数据库中；

所述发票系统对所述第一交易流水数据进行离线开票，将生成的所述第一交易流水数据对应的发票数据存储至所述非关系型数据库中。

2.如权利要求1所述的方法，其特征在于，还包括：

所述发票系统在确定批处理操作规则由第一规则变为第二规则后，若确定所述非关系型数据库中存在已完成所述第一规则的批处理但尚未开票的第二交易流水数据，则基于所述第二规则，对所述第二交易流水数据重新进行批处理；

所述发票系统将与所述第一规则批处理后的第二交易流水数据存在差异的所述第二规则批处理后的第二交易流水数据更新至所述非关系型数据库中。

3.如权利要求1所述的方法，其特征在于，所述非关系型数据库为Hbase；

交易流水数据的标识和交易流水数据构成Key-Value的键值对；其中，交易流水数据的标识包括客户标识号的后N位数+客户标识号+交易日期+交易流水号；N为正整数；

发票数据的编号和发票数据构成为Key-Value键值对。

4.如权利要求1所述的方法，其特征在于，还包括：

所述发票系统接收实时开票请求；所述实时开票请求中包括第三交易流水数据；所述实时开票请求是所述业务系统经消息中间件发送至所述发票系统的；

所述发票系统对所述第三交易流水数据进行实时开票，将生成的所述第三交易流水数据对应的发票数据存储至所述非关系型数据库中。

5.如权利要求4所述的方法，其特征在于，所述发票系统对所述第三交易流水数据进行实时开票之前，还包括：

所述发票系统通过关系型数据库确定所述第三交易流水数据的开票状态，并根据所述第三交易流水的开票状态确定对所述第三交易流水数据进行实时开票；所述关系型数据库中存储有交易流水数据的标识与开票状态的对应关系；

所述发票系统对所述第三交易流水数据进行实时开票之后，还包括：

所述发票系统在所述关系型数据库中更新所述第三交易流水数据的开票状态。

6.如权利要求4所述的方法，其特征在于，所述发票系统对所述第一交易流水数据进行离线开票之前，还包括：

所述发票系统对所述第一交易流水数据加锁处理，用于防止所述发票系统对所述第一交易流水数据进行并发开票；

所述发票系统对所述第三交易流水数据进行实时开票之前，还包括：

所述发票系统对所述第三交易流水数据加锁处理，用于防止所述发票系统对所述第三交易流水数据进行并发开票。

7.如权利要求1至6任一项所述的方法，其特征在于，所述发票系统生成所述第一交易流水数据对应的发票数据之后，还包括：

所述发票系统调用第一任务将所述第一交易流水数据对应的发票数据发送至所述业务系统；

所述发票系统调用第二任务将所述第一交易流水数据对应的发票数据发送至生成服务器，以使所述生成服务器根据所述第一交易流水数据对应的发票数据生成所述第一交易流水数据对应的发票文件；

所述发票系统调用第三任务将所述第一交易流水数据对应的发票文件发送至签章系统，以使所述签章系统对所述第一交易流水数据对应的发票文件签章；

所述发票系统调用第四任务将已签章的所述第一交易流水数据对应的发票文件发送至客户邮箱。

8.一种发票的生成装置，其特征在于，包括：

接收单元、处理单元；

所述接收单元，用于接收离线开票请求，所述离线开票请求中包括第一交易流水数据的标识；

所述处理单元，用于根据所述第一交易流水数据的标识，从非关系型数据库中获取所述第一交易流水数据；所述第一交易流水数据是由业务系统生成并经所述发票系统进行批处理后存储至所述非关系型数据库中；

所述处理单元，还用于对所述第一交易流水数据进行离线开票，将生成的所述第一交易流水数据对应的发票数据存储至所述非关系型数据库中。

9.一种计算设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1至7任一项所述的方法。

10.一种计算机可读非易失性存储介质，其特征在于，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行如权利要求1至7任一项所述的方法。

Images