CN110992116A - 基于etc系统的电子发票生成方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种基于ETC系统的电子发票生成方法、装置、设备及存储介质，涉及电子信息技术领域。该方法包括：根据用户发送的发票生成指令为待开发票订单生成发票记录，并将所述发票记录保存到发票特定表，异步调用发票平台接口向发票平台发送开发票请求，并接收所述发票平台执行所述开发票请求后发送的发票处理结果，开发票请求用于指示所述发票平台根据所述订单信息生成所述待开发票订单的发票；若所述发票处理结果为开票完成，则将从所述发票处理结果中提取到的发票代码加入到所述发票特定表上的发票记录中，并向用户推送开票完成信息。能够避免通过第三方工具生成电子发票的问题，进一步避免用户信息泄露。

Description

基于ETC系统的电子发票生成方法、装置、设备及存储介质

技术领域

本申请涉及电子信息技术领域，特别是一种基于ETC系统的电子发票生成方法、装置、设备及存储介质。

背景技术

目前的高速公路开具发票主要是人工开具纸质发票，也有开具电子发票，现有技术中的电子发票大多都是通过第三方工具或者通过指定的APP来得到高速通行收费之后的电子发票，一般地，将指定交易数据发送给ETC系统管理终端指定的APP，并向指定的APP提供用户信息，以便指定的APP根据交易数据以及用户信息生成电子发票。但是当海量的用户同时申请开具发票的时候，因为发票信息都是一次性生成会对服务器造成巨大的压力，导致开发票的时长变长。

发明内容

本申请实施例所要解决的技术问题是，提供一种基于ETC系统的电子发票生成方法、装置、设备及存储介质，能够避免一次性处理海量发票生成请求时造成的服务器拥堵的技术问题。

为了解决上述技术问题，本申请实施例所述的一种基于ETC系统的电子发票生成方法，采用了如下所述的技术方案：

根据用户发送的发票生成指令为待开发票订单生成发票记录，并将所述发票记录保存到发票特定表，其中，所述发票记录为所述待开发票订单的特征数据；

异步调用发票平台接口向发票平台发送开发票请求，并接收所述发票平台执行所述开发票请求后返回的发票处理结果，其中，所述开发票请求中包括所述待开发票订单的订单信息，所述开发票请求用于指示所述发票平台根据所述订单信息生成所述待开发票订单的发票；

对所述发票处理结果进行识别；

若所述发票处理结果为开票完成，则将从所述发票处理结果中提取到的发票代码加入到所述发票特定表上的发票记录中，并向用户推送开票完成信息。

一种基于ETC系统的电子发票生成装置，包括：

发票记录生成模块，用于根据用户发送的发票生成指令为待开发票订单生成发票记录，并将所述发票记录保存到发票特定表，其中，所述发票记录为与所述待开发票订单对应的维度特征；

发票生成模块，用于异步调用发票平台接口向发票平台发送开发票请求，并接收所述发票平台执行所述开发票请求后发送的发票处理结果，其中，所述开发票请求中包括所述待开发票订单的订单信息，所述开发票请求用于指示所述发票平台根据所述订单信息生成所述待开发票订单的发票；

结果解析模块，用于对所述发票处理结果进行识别；

记录更新模块，用于若所述发票处理结果为开票完成，则将从所述发票处理结果中提取到的发票代码加入到所述发票特定表上的发票记录中，并向用户推送开票完成信息。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，采用了如下所述的技术方案：

第三方面，本发明实施例提供一种计算机设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机可读指令，所述计算机可读指令被所述至少一个处理器执行时，使得所述至少一个处理器执行上述的基于ETC系统的电子发票生成方法。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，采用了如下所述的技术方案：

第四方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述任意一项技术方案所述的基于ETC系统的电子发票生成方法。

与现有技术相比，本申请实施例主要有以下有益效果：

本申请实施例公开了一种基于ETC系统的电子发票生成方法、装置、计算机设备及存储介质，本申请实施例所述的基于ETC系统的电子发票生成方法，通过在接收到用户发送的发票生成请求后便为待开发票订单生成一个发票记录，发票记录中记录有从待开发票订单中获取的订单信息和发明人填写用户信息等，又在完成开发票后将发票平台返回的发票代码加入到发票记录中，分批次完善发票记录用户后续查看。本申请通过分两次生成完整的发票记录，可以有效减缓服务端的压力，增加开发票的速度，提升用户体验。

附图说明

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

图1为本申请实施例可以应用于其中的示例性系统架构图；

图2为本申请实施例中所述基于ETC系统的电子发票生成方法的一个实施例的流程图；

图3是本申请图2中步骤202的流程图；

图4是本申请图2中步骤204的流程图；

图5为本申请实施例中所述基于ETC系统的电子发票生成装置的一个实施例的结构示意图；

图6为本申请实施例中计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”、“包含”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。在本申请的权利要求书、说明书以及说明书附图中的术语，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体/操作/对象与另一个实体/操作/对象区分开来，而不一定要求或者暗示这些实体/操作/对象之间存在任何这种实际的关系或者顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其他实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其他实施例相结合。

为了使本技术领域的人员更好地理解本申请的方案，下面将结合本申请实施例中的相关附图，对本申请实施例中的技术方案进行清楚、完整地描述。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的基于ETC系统的电子发票生成方法一般由服务器/终端设备执行，相应地，基于ETC系统的电子发票生成装置一般设置于服务器/终端设备中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了本申请实施例中所述基于ETC系统的电子发票生成方法的一个实施例的流程图。所述基于ETC系统的电子发票生成方法，包括以下步骤：

步骤202，根据用户发送的发票生成指令为待开发票订单生成发票记录，并将发票记录保存到发票特定表，其中，发票记录为待开发票订单的特征数据。

本实施例中，待开发票订单是用户执行开发票请求后的收费订单，收费订单是用户通过高速出口道闸，高速公路收费系统已完成对用户收费的订单。

道闸又称为挡车器，是专门用于道路上限制机动车行驶的通道出入口管理设备一般应用于公路收费站以及停车场系统管理车辆通道等，用于管理车辆的出入；所述道闸一般由减速箱、电机、传动机构、平衡装置、机箱、闸杆支架以及闸杆等部分组成。

收费订单是高速收费系统根据用户车辆的通行记录，对用户收费，用户缴费产生的订单，这种类型的订单一般包括支付已完成、支付等待中以及支付未完成等支付状态、用户的信息、订单开始和结束的时间、订单号、用户ID等等信息，可能还包括其他比如说收费方的信息，本实施例不做限定。

发票记录可以包括订单号、发票开票日期、开票方、付款方、开票金额、发票抬头以及发票代码等。

其中，发票抬头是付款方或者付款单位的名字，是用户预先通过小程序一类的工具发送到服务端的。本实施例中指用户的姓名。

可选地，根据待开发票订单生成发票记录包括：

根据待开发票订单开票并生成开票记录；

将开票记录储存到发票特定表中；

根据发票特定表中的开票记录生成发票记录。

本实施例中，用户每申请开票一次，便会产生有一条与费用订单相对应的开票记录，并保存到发票特定表中。

其中，开票记录包括开票日期、发票是否到账信息、单位名称、开票金额、开票票号以及简称等，然后将开票记录进行整合处理，比如结构化处理后作为发票记录保存，便于查看。

进一步地，根据数据库中的开票记录生成发票记录包括：

根据开票记录生成对应的发票记录。

示例性的，每开票一次生成一次开票记录，有一次开票记录对应的就有一次发票记录。

步骤204，异步调用发票平台接口向发票平台发送开发票请求，并接收发票平台执行开发票请求后发送的发票处理结果，其中，开发票请求中包括待开发票订单的订单信息，开发票请求用于指示发票平台根据订单信息生成待开发票订单的发票。

在生成发票记录的进程处理结束后，再创建新的用于向发票平台发送开发票请求的进程，这种异步处理的方式，可以避免在有大量开发票请求时避免数据处理拥堵的情况发生，增加数据处理的速度。

发票平台接口是用于与发票平台对接的API接口，用于处理与发票平台有关的指令或者请求，比如向发票平台发送开发票请求，接收发票平台返回的处理结果等等。

本实施例中的发票平台接口是应用程序接口中的一种接口，所述应用程序接口(Application Programming Interface，API)是一些预先定义的函数，根据这些函数可以进行网络应用程序的开发，不需要访问源码以及理解内部的工作机制细节。根据发票平台接口开具电子发票，在开具电子发票的过程中无需财务人员经手，提高了效率。

其中，待开发票订单的订单信息包括订单创建时间、结束时间、金额、订单号等等。当发票平台接收到服务端通过发票平台接口发送的开发票请求，则对开发票请求中的订单信息进行核查，核查通过则生成该待开发票订单的发票，并将该发票发送用户，最后向服务端发送已开发票的处理结果。服务端接收到已开发票的处理结果后根据处理结果做进一步地处理。

进一步地，开发票请求中还包括用户信息，开发票请求还用于指示发票平台在所述接收发票平台执行开发票请求后发送的发票处理结果之前，根据用户信息将生成的发票发送给用户。

用户信息可以是用户在服务端输入的邮箱地址或手机号码，随同开发票请求一起发送给发票平台，发票平台会根据开发票请求的指示将开好的发票直接发送到用户的邮箱或手机，而不是让其他平台获取，保护了用户信息的隐私。

进一步地，异步调用发票查询接口定时向发票平台发送发票查询请求，当接收到发票平台发送的查询响应为发票处理结果时，停止发送发票查询请求。

发票查询接口是用于主动向发票平台发送发票查询请求的接口，在向发票平台发送开发票请求后就会定时向发票平台发送根据发票记录和开发票请求生成的发票查询请求。发票平台接收到该发票查询请求后，若已生成发票，则会返回一个查询响应给发票查询接口。

本实施例中发票查询接口是API的一种，所述API(Application ProgrammingInterface,应用程序编程接口)，直接调用发票查询接口可以节省电脑的存储空间，提高效率。

步骤206，对发票处理结果进行识别。

服务端接收到发票平台返回的发票处理结果后会对发票处理结果进行识别。

本实施例中可以通过获取发票查询接口的状态信息判断发票处理结果是否为开票完成，当所述状态信息为预设状态时，则所述发票处理结果为开票完成。

比如，当状态信息为1时为未完成，即尚未接收到发票平台的查询响应或者接收到了响应信息但查询响应不是开票完成，则认为开票未完成；当状态信息为0时，则说明开票完成等情况。

本实施例的预设信息可以是0。

可选地，若发票查询接口的状态为成功：

file_get(“status”)；

result[‘return_code’]＝＝(“success”)

若所述查询接口的状态为失败：

file_get(“status”)；

result[‘return_code’]＝＝(“fail”)

预设信息根据状态信息的设置的改变而改变，本实施例不做限定。

步骤208，若发票处理结果为开票完成，则将从发票处理结果中提取到的发票代码加入到发票特定表上的发票记录中，并向用户推送开票完成信息。

发票平台处理完开发票请求后，会将生成的发票代码随发票处理结果一同发送给服务端，服务端便可以获取发票代码，并将发票代码加入到前面生成的发票记录中完善发票记录的信息，并向用户发送发票已经开好的信息，提醒用户的可以查看服务端上的发票记录，方便了用户获取发票信息。其中，向用户推送开票完成的信息可以是服务端主动向用户推送，比如可以通过直接更新微信小程序上的发票状态的通知用户，也可以是用户向服务端发送查看发票状态的指令，服务端再将该开票完成的信息更新给用户看，本实施例不做限定。

进一步地，若发票处理结果为开票失败，则服务端也会相应的从发票平台接收到开票失败的具体原因，比如用户的纳税人识别号填写错误、未填写、发票平台服务器无响应、服务器压力过大等情况。

如果发生这种情况用户可以重新发起生成发票请求，服务端会重新向发票平台发起开发票请求，直到完成开发票。

可选地，若发票处理结果为未完成，则未完成就继续等待，则继续发送请求，直到接收到开票成功的发票处理结果。若有外界原因导致开发票失败，则返回开发票失败的异常给用户，让用户重新提起开发票请求。

本实施例通过在接收到用户发送的发票生成请求后便为待开发票订单生成一个发票记录，发票记录中记录有从待开发票订单中获取的订单信息和发明人填写用户信息等，又在完成开发票后将发票平台返回的发票代码加入到发票记录中，分批次完善发票记录用户后续查看。本申请通过分两次生成完整的发票记录，可以有效减缓服务端的压力，增加开发票的速度，提升用户体验。

在一个实施例中，如图3所示，步骤202，包括：

步骤302，接收发票生成指令，并根据预设读取条件读取待开发票订单的订单信息。

预设读取条件是读取待开发票订单上的订单信息的条件，比如读取金额、商品信息、订单上用户的身份信息以及用户填写的企业纳税号等等。在一种情况下，有时候无需获取用户的纳税号，只是需要用户的个人信息，则不需要读取这一部分的信息。这根据具体情况而定，本实施例不做限定。

步骤304，将读取到的订单信息保存为结构化数据，作为发票记录写入发票特定表中。一般通过正则表达式对读取到的订单信息进行结构化处理，生成属性和数值一一对应的结构化数据，便于后续的读取和识别。

本实施例通过将读取到的数据进行结构化处理，提高了数据的读取和识别效率。

在一个实施例中，如图4所示，步骤204，包括：

步骤402，获取发票记录的存放地址接口。

步骤404，从存放地址接口链接到发票特定表得到发票记录，并根据发票记录调用发票平台接口向发票平台发送开发票请求。

具体地，获取到发票存放地址接口可以是http://apis.juhe.cn/ip/ip2addr。进一步地，步骤204还包括：开发票请求还用于指示发票平台根据用户信息将开好的发票发送给用户。

具体地，该用户信息可以是用户的电子邮箱。电子邮箱是在网络中，可以自动接收网络任何电子邮箱所发的电子邮件，并能存储规定大小的多种格式的电子邮件。用户可以在任何时间、任何地点收发电子邮件，解决了时空的限制，提高了效率。电子邮箱可以包括网易电子邮箱、雅虎电子邮箱、搜狐电子邮箱、谷歌电子邮箱、新浪电子邮箱、QQ电子邮箱以及Hotmail电子邮箱等。

进一步地，将已经开好的电子发票发送至用户的电子邮箱包括：

获取电子发票图片；

根据电子发票图片得到电子发票图片的PDF文件；

将PDF文件发送至用户的电子邮箱。

具体的，PDF是Portable Document Format的简称，意为“便携式文档格式”；PDF的具体内容：完整的发票电子版，即纸质发票的电子图片。

进一步地，根据电子发票图片得到电子发票图片的PDF文件包括：直接将图片格式的电子发票转换成PDF格式。转换的凡事有多种比如是发票平台自定义转换、或者通过第三方工具进行转换等等，此处不做赘述。

示例性的，将电子发票图片存储在Word中，将含有电子发票图片的Word文件导出为PDF文件。

可选地，在生成电子发票之后还包括：

定时查询电子发票的生成结果。

定时查询是根据每隔

一段时间去调用发票的查询接口获取结果，预设时间可以为2-5分钟查询一次。

本实施例中，生成电子发票以及将电子发票发送到用户邮箱的时间可以是随机的也可以是按照规定时间的。

本申请实施例通过获取已完成的支付订单；根据所述订单生成发票记录；根据发票记录调用发票平台接口；根据发票平台接口生成电子发票。并且电子发票通过发票平台开具，用户确定发票抬头，通过发票平台接口就可以接收电子发票的税号等信息，然后通过预先填入的用户信息接收发票平台发送的电子发票，该电子发票可以是以PDF格式的形式发送到用户的邮箱。用户直接接收电子发票，而不用经由第三方平台处理电子发票，第三方平台上只保留已开发票订单的发票记录以供用户查询，且分两次完善发票记录中的数据，不仅可以减少隐私泄露的风险，也减少了生成发票后一次性生成所有发票记录中的数据造成的服务器压力过大的技术问题。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解的是，虽然图2-图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-图4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。在一个实施例中，如图5所示，提供一种基于ETC系统的电子发票生成装置，该装置与上述实施例中基于ETC系统的电子发票生成方法一一对应。该基于ETC系统的电子发票生成装置包括：

发票记录生成模块502，用于根据用户发送的发票生成指令为待开发票订单生成发票记录，并将发票记录保存到发票特定表，其中，发票记录为与待开发票订单对应的维度特征。

发票生成模块504，用于异步调用发票平台接口向发票平台发送开发票请求，并接收发票平台执行开发票请求后发送的发票处理结果，其中，开发票请求中包括待开发票订单的订单信息，开发票请求用于指示发票平台根据订单信息生成待开发票订单的发票。

结果解析模块506，用于对发票处理结果进行识别。

记录更新模块508，用于若发票处理结果为开票完成，则将从发票处理结果中提取到的发票代码加入到发票特定表上的发票记录中，并向用户推送开票完成信息。

进一步地，发票生成模块504，包括：

接口获取子模块，用于获取发票记录的存放地址接口。

请求发送子模块，用于从存放地址接口链接到发票特定表得到发票记录，并根据发票记录调用发票平台接口向发票平台发送开发票请求。

进一步地，请求发送子模块中，开发票请求中还包括用户信息，开发票请求还用于指示发票平台在接收发票平台执行开发票请求后的发票处理结果之前，根据用户信息将生成的发票发送给用户。

进一步地，发票生成模块504，还包括：

开票查询子模块，用于异步调用发票查询接口定时向发票平台发送发票查询请求，当接收到发票平台发送的查询响应为发票处理结果时，停止发送发票查询请求。

进一步地，发票记录生成模块502，包括：

信息读取子模块，用于接收发票生成指令，并根据预设读取条件读取待开发票订单的订单信息。

记录生成子模块，用于将读取到的订单信息保存为结构化数据，作为发票记录写入发票特定表中。

进一步地，发票生成模块504，包括：

状态判断子模块，用于获取发票查询接口的状态信息，根据所述状态信息判断所述发票处理结果的状态。具体地，当状态信息为预设状态时，则发票处理结果为开票完成。

本申请实施例所述的基于ETC系统的电子发票生成装置，通过在接收到用户发送的发票生成请求后便为待开发票订单生成一个发票记录，发票记录中记录有从待开发票订单中获取的订单信息和发明人填写用户信息等，又在完成开发票后将发票平台返回的发票代码加入到发票记录中，分批次完善发票记录用户后续查看。本申请通过分两次生成完整的发票记录，可以有效减缓服务端的压力，增加开发票的速度，提升用户体验。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储用户订单数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于ETC系统的电子发票生成方法。

其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例中基于ETC系统的电子发票生成方法的步骤，例如图2所示的步骤202至步骤208，或者，处理器执行计算机程序时实现上述实施例中基于ETC系统的电子发票生成装置的各模块/单元的功能，例如图5所示模块502至模块508的功能。为避免重复，此处不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述实施例中基于ETC系统的电子发票生成方法的步骤，例如图2所示的步骤202至步骤208，或者，处理器执行计算机程序时实现上述实施例中基于ETC系统的电子发票生成装置的各模块/单元的功能，例如图5所示模块502至模块508的功能。为避免重复，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形、改进或者对部分技术特征进行等同替换，而这些修改或者替换，并不使相同技术方案的本质脱离本发明个实施例技术方案地精神和范畴，都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于ETC系统的电子发票生成方法，其特征在于，包括：

根据用户发送的发票生成指令为待开发票订单生成发票记录，并将所述发票记录保存到发票特定表，其中，所述发票记录为所述待开发票订单的特征数据；

异步调用发票平台接口向发票平台发送开发票请求，并接收所述发票平台执行所述开发票请求后返回的发票处理结果，其中，所述开发票请求中包括所述待开发票订单的订单信息，所述开发票请求用于指示所述发票平台根据所述订单信息生成所述待开发票订单的发票；

对所述发票处理结果进行识别；

若所述发票处理结果为开票完成，则将从所述发票处理结果中提取到的发票代码加入到所述发票特定表上的发票记录中，并向用户推送开票完成信息。

2.根据权利要求1所述的方法，其特征在于，所述开发票请求中还包括用户信息，所述开发票请求还用于指示所述发票平台在所述接收所述发票平台执行所述开发票请求后发送的发票处理结果之前，根据所述用户信息将生成的所述发票发送给用户。

3.根据权利要求1所述的方法，其特征在于，所述根据用户发送的发票生成指令为待开发票订单生成发票记录，包括：

接收所述发票生成指令，并根据预设读取条件读取所述待开发票订单的订单信息；

将读取到的所述订单信息保存为结构化数据，作为所述发票记录写入所述发票特定表中。

4.根据权利要求1所述的方法，其特征在于，所述异步调用发票平台接口向发票平台发送开发票请求，包括：

获取所述发票记录的存放地址接口；

从所述存放地址接口链接到所述发票特定表得到所述发票记录，并根据所述发票记录调用发票平台接口向所述发票平台发送开发票请求。

5.根据权利要求1所述的方法，其特征在于，所述接收所述发票平台执行所述开发票请求后发送的发票处理结果，包括：

异步调用发票查询接口定时向所述发票平台发送发票查询请求；

当接收到所述发票平台返回的查询响应为发票处理结果，停止发送所述发票查询请求。

6.根据权利要求4所述的方法，其特征在于，所述对所述发票处理结果进行识别，包括：

获取发票查询接口的状态信息，根据所述状态信息判断所述发票处理结果是否为开票完成；

当所述状态信息为预设状态时，则确认所述发票处理结果为开票完成。

7.一种基于ETC系统的电子发票生成装置，其特征在于，包括：

发票记录生成模块，用于根据用户发送的发票生成指令为待开发票订单生成发票记录，并将所述发票记录保存到发票特定表，其中，所述发票记录为与所述待开发票订单对应的维度特征；

发票生成模块，用于异步调用发票平台接口向发票平台发送开发票请求，并接收所述发票平台执行所述开发票请求后发送的发票处理结果，其中，所述开发票请求中包括所述待开发票订单的订单信息，所述开发票请求用于指示所述发票平台根据所述订单信息生成所述待开发票订单的发票；

结果解析模块，用于对所述发票处理结果进行识别；

记录更新模块，用于若所述发票处理结果为开票完成，则将从所述发票处理结果中提取到的发票代码加入到所述发票特定表上的发票记录中，并向用户推送开票完成信息。

8.根据权利要求7所述的装置，其特征在于，所述发票生成模块，包括：

接口获取子模块，用于获取所述发票记录的存放地址接口；

请求发送子模块，用于从所述存放地址接口链接到所述发票特定表得到所述发票记录，并根据所述发票记录调用发票平台接口向所述发票平台发送开发票请求。

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

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机可读指令，所述计算机可读指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1至6中任一项所述的基于ETC系统的电子发票生成方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-6中任意一项所述的基于ETC系统的电子发票生成方法。

Images