一种信息交互方法及装置

本发明涉及互联网技术领域，具体涉及一种信息交互方法及装置。

发票是单位或个人在购销商品、提供或接受服务以及从事其他经营活动中所开具和收取的凭证。随着当前服务种类或商品类型的扩展，发票的开具需求日渐增多。

现有技术通常是采用线下模式开具发票，但这会给发票开具双方带来较高工作量，不仅加大了发票开具成本，同时也无法满足日益增长的发票开具需求。

有鉴于此,本发明实施例提供了一种信息交互方法及装置，以满足日益增长的发票开具需求。

第一方面，本发明实施例提供一种信息交互方法，所述方法包括：

获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态；

在发票管理页面中显示所述各账单信息，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求；

响应于接收到针对目标账单信息的开具请求，获取发票数据，所述发票数据用于表征开具请求方对于发票开具的需求信息；

根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态；

其中，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。

第二方面，本发明实施例提供一种信息交互装置，所述装置包括：

账单信息构建单元，用于获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态；

显示单元，用于在发票管理页面中显示所述各账单信息，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求；

获取单元，用于响应于接收到针对目标账单信息的开具请求，获取发票数据，所述发票数据用于表征开具请求方对于发票开具的需求信息；

发票开具单元，用于根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态；

其中，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。

第三方面，本发明实施例提供一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现如第一方面中任一项所述的方法。

第四方面，本发明实施例提供一种电子设备，所述设备包括：

存储器，用于存储一条或多条计算机程序指令；

处理器，所述一条或多条计算机程序指令被所述处理器执行以实现如第一方面中任一项所述的方法。

本发明实施例的信息交互方法在获取预设时间段内的订单信息后，会根据所述订单信息构建至少一个满足发票开具条件且处于待申请状态的账单信息，并在发票管理页面中显示所述各账单信息。响应于接收到针对目标账单信息的开具请求，获取发票数据，根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态。其中，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求，所述发票数据用于表征开具请求方对于发票开具的需求信息，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。通过所述方法可以满足日益增长的发票开具需求。

通过以下参照附图对本发明实施例的描述，本发明的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1为本发明实施例的应用系统示意图；

图2为本发明实施例的信息交互方法的流程图；

图3为本发明实施例的账单信息构建方法的流程图；

图4为本发明实施例的发票管理页面的示意图；

图5为本发明实施例的电子发票的发票申请页面示意图；

图6为本发明实施例的纸质发票的发票申请页面示意图；

图7为本发明实施例的发票审核流程图；

图8为本发明实施例在审核未通过情况下进行信息反馈的流程图；

图9为本发明实施例的目标账单信息状态调整的示意图；

图10为本发明实施例的发票记录页面的示意图；

图11为本发明实施例的取消发票开具请求的流程图；

图12为本发明实施例的退票操作的流程示意图；

图13为本发明实施例的应用系统的系统信令图；

图14为本发明实施例的信息交互装置的示意图；

图15是本发明实施例的电子设备的示意图。

以下基于实施例对本发明进行描述，但是本发明并不仅仅限于这些实施例。在下文对本发明的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本发明。为了避免混淆本发明的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。

此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。

除非上下文明确要求，否则在本申请的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

发票是单位或个人在购销商品、提供或接受服务以及从事其他经营活动中所开具和收取的凭证。随着当前服务种类或商品类型的扩展，发票的开具需求日渐增多。

以外卖行业为例，为了满足部分企业用户的订餐需求。外卖平台会向有订餐需求的企业提供企业订餐服务。在开通企业订餐服务后，企业可以通过公司账户向多个终端进行授权，而企业内部的员工则可以使用被授权的终端进行订餐。相应的，订餐服务中所产生的订餐费用和服务费用会从所述公司账户中扣除。

应当理解，所述授权方式可以是将多个终端的唯一标识，例如手机号与公司账户进行绑定，当使用被授权终端进行订餐时，外卖平台服务器会从与被授权终端绑定的公司账户中扣除订餐所产生的相关费用。

在企业需要开具订餐服务所产生相关费用的发票的时候，现有技术通常是由企业和外卖平台双方的财务人员进行对接来开具发票。但现有技术仅能满足部分简单情况下的发票开具需求。对于一些复杂情况下的发票开具需求，例如：所要开具的发票中涉及多条资金链路，又或者所要开具的发票涉及延迟结算或退单退款情况时，线下的发票开具模式会给双方财务人员带来较高工作量，加大发票开具的成本。

对此，本发明实施例提供了一种信息交互方法及装置，以满足日益增长的发票开具需求。

图1为本发明实施例的应用系统示意图。如图1所示，所述应用系统包括企业员工终端11，企业财务终端12，外卖平台财务终端13以及外卖平台服务器14。

其中，所述企业员工终端11，企业财务终端12和外卖平台财务终端13可以是手机、电脑或平板电脑等终端设备。所述企业员工终端11，企业财务终端12，外卖平台财务终端13以及外卖平台服务器14之间通过网络连接以传递信息。

进一步地，所述企业员工终端11、企业财务终端12以及外卖平台财务终端13中分别安装有员工端应用程序、企业端应用程序和平台端应用程序。

其中，企业的员工可以通过所述员工端应用程序进行订餐操作。企业的财务人员可以在所述企业端应用程序中查看企业员工在订餐过程中所产生的账单信息并发出相应的发票开具请求。外卖平台的财务人员可以通过所述平台端应用程序查看企业财务人员所发出的发票开具请求并为其开具发票。

应当理解，图1的应用系统中所示的企业员工终端的数量仅仅是为了示意，在实际应用中其具体数量可以根据实际需求设置。

具体地，企业中的员工可以通过各自的企业员工终端订餐。而订餐过程中所生成的订单费用和相关服务费用会转化为订单信息存储在外卖平台服务器14中。外卖平台服务器14会每隔预定时间段，例如一个月将企业中各员工所产生的订单信息汇总为账单信息发送给企业财务终端12。企业的财务人员可以通过企业财务终端12查看所汇总的账单信息以及对账单信息发出发票开具请求。外卖平台的财务人员可以通过外卖平台财务终端13查看发票开具请求，并为企业开具发票。

图2为本发明实施例的信息交互方法的流程图。如图2所示，所述信息交互方法包括如下步骤：

S100、获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态。

其中，所述预设时间段为根据实际情况所设置的账单信息构建周期。所述订单信息为外卖平台服务器在预设时间段内所接收存储的订单信息。所述订单信息中具体包括订单的消费金额、消费时间、支付方式、支付方账户信息、收取方账户信息以及订单所属的费用类型等信息。所述待申请状态用于表征账单信息当前未处于发票开具的过程中。企业财务人员可以对待申请状态下的账单信息发出开具请求。

具体地，外卖平台服务器会获取预设时间段内所接收存储到的订单信息，并在所获取的订单信息中出与企业对应的满足发票开具条件的订单信息，以汇总成相应的账单信息。

应当理解，所述步骤S100也可以是由企业财务终端执行，也即，可以是由企业财务终端从外卖平台服务器获取相关的订单信息，再从所获取的订单信息中出满足发票开具条件的订单信息，以汇总成账单信息。

可选地，步骤S100中构建账单信息的方法具体可以通过如图3所示的各步骤实现。

具体地，图3为本发明实施例的账单信息构建方法的流程图。如图3所示，所述账单信息构建方法包括如下步骤：

S110、获取开具条件信息。

其中，所述开具条件信息为执行发票开具操作的订单信息所要满足的条件。所述开具条件信息可以包括订单信息所要满足的支付方账户信息、收取方账户信息以及费用类型信息等。

S120、将所述订单信息中符合所述开具条件信息的订单信息确定为目标订单信息。

具体地，在获取开具条件信息后，在所获取的订单信息中筛选出符合所述开具条件信息的订单信息，并将筛选出的订单信息确定为目标订单信息。其中，所述目标订单信息为能够进行发票开具操作的订单信息。

可选地，所述开具条件信息中的支付方账户信息和收取方账户信息具体可以分别为企业订餐服务中的对应企业和外卖平台的账户信息，所述费用类型信息可以包括企业订餐服务中所涉及到的费用类型，例如餐费、物流费或服务费等。

例如：订单信息A为对应企业中某一员工通过企业订餐服务购买餐品所产生的餐品费用信息和配送餐品所产生的物流费用信息，订单信息B为该员工在购买餐品时额外购买随单结算服务所产生的服务费用信息，订单信息C为另一员工通过企业订餐服务购买后结算服务所产生的服务费用信息。所述订单信息A、B和C均为满足开具条件的目标订单信息。

其中，所述随单结算服务是指外卖平台在员工购买餐品时向员工提供的可选购买服务，例如准时送达服务。所述后结算服务是指外卖平台为员工提供的先享受餐品再进行支付的服务。

应当理解，所述开具条件信息还可以根据实际情况进行设置。例如：所述开具条件信息还可以包括订单信息所要满足的目标金额，也即，只有订单金额小于所述目标金额的订单才具备执行发票开具操作的条件。

S130、根据预设分组规则，将所述各目标订单信息分为至少一个目标订单信息组。

具体地，在确定目标订单信息之后，还可以进一步将多个目标订单信息分为至少一个目标订单信息组。

可选地，所述预设分组规则的方式可以是按照订单信息的开具内容进行分组。

具体地，可以按照所述订单信息的开具内容，将所述各目标订单信息分为至少一个目标订单信息组。其中，所述开具内容具体为目标订单信息的服务类型，例如餐费、随单结算服务费以及后结算服务费。

例如：目标订单信息A可以分到餐费所对应的目标订单信息组，目标订单信息B可以分到随单结算服务费所对应的目标订单信息组，目标订单信息C可以分到后结算服务费所对应的目标订单信息组。

S140、根据所述各目标订单信息组，构建对应的账单信息。

其中，所述账单信息的可开具金额信息为对应目标订单信息组中各目标订单信息的金额信息汇总。所述可开具金额信息用于表征账单信息在构建完成时可以开具发票的金额信息。

具体地，在确定各目标订单信息组后，可以分别对各目标订单信息组中的目标订单信息的金额信息进行汇总，以构建对应的账单信息。

应当理解，所述账单信息可以为获得同一账户授权的不同终端所产生的订单信息汇总。其中，所述账户可以是公司账户，所述终端可以是获得公司账户授权的终端。

进一步地，在构建账单信息时，所述目标订单信息组中的目标订单信息可以分为正向目标订单信息和负向目标订单信息。其中，所述正向目标订单信息为由外卖平台正常收取费用的订单，所述负向目标订单信息为外卖平台退还费用的订单。所述可开具金额信息应为所述正向目标订单信息与所述负向目标订单信息的金额信息之差。

S200、在发票管理页面中显示所述各账单信息。

其中，所述发票管理页面可以为企业财务终端安装的企业端应用程序中的页面。所述发票管理页面用于展示可开具发票的账单信息。

图4为本发明实施例的发票管理页面的示意图。如图4所示，所述发票管理页面中包括最近一个预设时间段的账单信息41-43以及上一预设时间段的账单信息45。其中，所述账单信息41-43分别由不同服务类型，也即餐费、随单服务费和后结服务费的目标订单信息组中的目标订单信息汇总而成。

其中，所述各账单信息中均显示有可开具金额信息、已开具金额信息和待开具金额信息。所述可开具金额信息用于表征账单信息在构建完成时可以开具发票的金额信息。所述已开具金额信息用于表征账单信息中当前已经开具发票的金额信息。所述待开具金额信息用于表征账单信息当前剩余的可开具发票的金额信息。

进一步地，所述已开具金额信息为对应账单信息的历史开具金额之和，所述待开具金额信息为所述可开具金额信息与所述已开具金额信息之差。其中，所述历史开具金额具体为开具请求方发出开具申请且开具成功的金额。

进一步地，可开具金额信息大于0的账单信息中还包括申请控件，所述申请控件用于触发对应账单信息的开具请求。企业财务人员可以通过点击账单信息中的申请控件来发出针对目标账单信息的开具请求。如图4所示，企业财务人员可以通过点击申请开具控件44来发出针对账单信息41的开具请求。

S300、响应于接收到针对目标账单信息的开具请求，获取发票数据。

其中，所述发票数据用于表征开具请求方对于发票开具的需求信息。

具体地，在企业财务人员发出开具请求后，企业财务终端会显示与目标账单信息对应的发票申请页面。企业财务人员可以在所述发票申请页面中进一步填写所要开具的发票数据。在企业财务人员填写完发票数据后，企业财务终端会获取填写好的发票数据并发送到外卖平台财务终端来开具发票。

图5为本发明实施例的电子发票的发票申请页面示意图。如图5所示，所述发票申请页面包括发票构成、开具金额、发票开具方、发票类型、费用类型、发票材质、发票抬头、发票备注以及发票开具请求方的等信息。

其中，所述发票构成为目标账单信息所属的服务类型，所述开具金额为开具请求方，也即企业财务人员所要开具的金额。所述费用类型为目标账单信息所属于的费用类型。应当理解，企业财务人员可以选择所要开具的开具金额，但所述开具金额不能超过目标账单信息的待开具金额。

可选地，所述发票数据中的一部分信息可以为不可更改的固定信息，例如发票构成、发票开具方、发票类型、费用类型和发票材质，所述固定信息与所选择的目标账单信息相对应。而另一部分信息则可以由企业的财务人员进行填写，例如开具金额、发票抬头、发票备注和发票开具请求方的信息等。

进一步地，为了简便操作流程，所述发票数据中的部分信息会将历史填写数据以可选择项的方式进行显示，以供企业财务人员进行选择。例如图5中的发票抬头信息51，所述发票抬头信息51为企业财务人员上一次所填写过的抬头信息，此时会以默认选项的方式显示在发票数据中。

进一步地，图6为本发明实施例的纸质发票的发票申请页面示意图。如图6所示，图6中的部分信息与图5类似，其具体内容在此不再赘述。相较于电子发票，纸质发票的发票申请页面中还包括收货地址信息61，企业财务人员可以填写企业所在的地址信息，以便开具出来的发票能够准确地寄送到企业。

S400、根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态。

具体地，外卖平台财务终端在接收到企业财务终端所发送的发票数据后，会根据所述发票数据调用发票开具接口开具发票并将目标账单信息的状态调整为开具成功状态。其中，所述发票开具接口与税务部门相关联，用于执行开具发票操作。

应当理解，外卖平台财务终端和企业财务终端会共享目标账单信息的状态，也即，当其中一方调整目标账单信息的状态时，另一方中对应的目标账单信息也会随之改变。

在通常情况下，外卖平台财务终端在接收到企业财务终端所发送的发票数据后，往往还需要先由外卖平台财务人员对发票数据进行审核，只有在审核成功后才会执行发票开具操作。若每个开具请求均需要外卖平台财务人员进行审核，会加大外卖平台财务人员的工作量。对此，还可以通过设置审核限制条件来筛选发票数据，以适当降低工作量，提升审核效率。

图7为本发明实施例的发票审核流程图。如图7所示，所述发票审核方法包括如下步骤：

S410、响应于所述目标账单信息的发票数据满足审核限制条件，将所述发票数据移入待审核列表，并将所述目标账单信息的状态调整为审核中状态。

其中，所述待审核列表中的发票数据在外卖平台财务终端未得到审核结果信息前，不会执行后续的开具发票操作。

具体地，所述审核限制条件可以为预设金额阈值，所述预设金额阈值具体为所设置的单次开具发票的金额上限。当发票数据中的开具金额大于预设金额阈值时，外卖平台财务终端会将所述发票数据移入待审核列表，并将目标账单信息的状态调整为审核中状态。

应当理解，所述审核限制条件并不仅限于预设金额阈值，其具体内容可以根据实际需求进行设置。例如所述审核限制条件也可以为时间阈值，在将审核限制条件设置为时间阈值后，只有在时间阈值内的发票数据才需要进行审核。或者所述审核限制条件也可以为发票开具方的账户信息、目标账单信息所属的服务类型或上述各内容的相互结合等，在此不再赘述。

S420、响应于接收到针对所述目标账单信息的审核成功信息，将所述目标账单信息的状态调整为开具中状态。

具体地，当外卖平台财务终端接收到针对目标账单信息的审核成功信息后，会开始执行发票开具操作并将目标账单信息的状态调整为开具中状态。

相应的，图8为本发明实施例在审核未通过情况下进行信息反馈的流程图。如图8所示，在审核未通过情况下进行信息反馈的方法包括如下步骤:

S420'、响应于接收到针对所述目标账单信息的审核失败信息，反馈所述审核失败信息。

具体地，在外卖平台财务终端接收到针对目标账单信息的审核失败信息后，会向企业财务终端反馈所述审核失败信息。其中，所述审核失败信息可以包括审核失败原因。

S430'、将所述目标账单信息的状态调整为审核失败状态，所述处于审核失败状态的目标账单信息将不再执行后续的开具发票操作。

具体地，外卖平台财务终端会将目标账单信息的状态调整为审核失败状态。所述审核失败状态的目标账单信息将不再执行后续开具发票操作。

进一步地，响应于所述目标账单信息的发票数据不满足审核限制条件，将所述目标账单信息的状态调整为开具中状态。

具体地，若发票数据不满足审核限制条件，外卖平台财务终端会跳过审核步骤直接执行开具发票操作，以降低审核压力，提高审核效率。

图9为本发明实施例的目标账单信息状态调整的示意图。所述目标账单信息包括如图9中所示的各状态。

其中，所述待申请状态91用于表征目标账单信息当前未处于发票开具的过程中，企业财务人员可以发出开具请求。

当接收到针对目标账单信息的开具请求时，判断目标账单信息所对应的发票数据是否满足审核限制条件。若不满足审核限制条件时，会将目标账单信息的状态由待申请状态91调整为开具中状态92。若满足审核限制条件时，则会将目标账单信息的状态由待申请状态91调整为审核中状态93。

其中，所述审核中状态93用于表征目标账单信息当前处于等待审核的过程。若发票数据通过审核，则会将目标账单信息的状态调整为开具中状态92。若发票数据未通过审核，则会将目标账单信息的状态调整为审核失败状态94。

可选地，当目标账单信息处于审核中状态93时，企业财务人员可以发出取消请求，来将目标账单信息的状态调整为取消状态94，以停止执行后续审核操作和开具发票操作。

所述开具中状态92用于表征账单信息当前处于调用发票开具接口执行开具发票操作的过程中。若执行开具发票操作成功，则将目标账单信息的状态调整为开具成功状态96。若执行开具发票操作失败，则将目标账单信息的状态调整为开具失败状态97。

其中，企业财务人员可以对处于开具失败状态97的目标账单信息重新发出开具请求。

进一步地，企业财务人员可以对处于开具中状态92和开具成功状态96的目标账单信息发出退票请求，来将目标账单信息的状态调整为退票中状态97。

所述退票中状态97用于表征目标账单信息处于退票操作过程中。若执行退票操作成功，则将目标账单信息的状态调整为退票成功状态99。若执行退票操作失败，则将目标账单信息的状态调整为退票失败状态910。

进一步地，所述目标账单信息的各状态用于指示对应账单信息在发票记录页面中的显示状态。

其中，所述发票记录页面用于展示所申请开具发票的账单信息所处的状态，以及用于对处于不同状态下的账单信息执行相应的操作。

图10为本发明实施例的发票记录页面的示意图。如图10所示，所述发票记录页面中显示有不同状态的账单信息。所述账单信息中包括发票数据信息，以便企业财务人员进行查看。

进一步地，处于审核中状态的账单信息中还包括取消控件101，所述取消控件101用于触发对应账单信息的取消请求。

图11为本发明实施例的取消发票开具请求的流程图。如图11所示，所述取消发票开具请求的方法包括如下步骤：

S510、响应于接收到所述取消请求，停止执行后续的开具发票操作。

S520、将所述目标账单信息的状态调整为取消状态。

具体地，在接收到取消请求，停止取消请求所对应的账单信息的后续审核操作和开具发票操作，并将账单信息的状态调整为取消状态。

进一步地，处于开具失败状态的账单信息中还包括重新申请控件102，所述重新申请控件102用于重新请求开具发票。

可选地，在某些场景中，企业财务人员在完成开具发票操作后，可能会有退票需求。

图12为本发明实施例的退票操作的流程示意图。如图12所示，所述退票操作包括如下步骤：

S610、响应于接收到退票请求，执行退票操作。

S620、将所述目标账单信息的状态调整为退票中状态。

具体地，在接收到退票请求后，执行相应的退票操作并将目标账单信息的状态调整为退票中状态。

进一步地，响应于执行所述退票操作失败，将所述目标账单信息的状态调整为退票失败状态；或者

响应于执行所述退票操作成功，将所述目标账单信息的状态调整为退票成功状态。

具体地，在执行退票操作成功或失败时，需要对应调整目标账单信息的所处状态。

本发明实施例的信息交互方法在获取预设时间段内的订单信息后，会根据所述订单信息构建至少一个满足发票开具条件且处于待申请状态的账单信息，并在发票管理页面中显示所述各账单信息。响应于接收到针对目标账单信息的开具请求，获取发票数据，根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态。其中，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求，所述发票数据用于表征开具请求方对于发票开具的需求信息，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。通过所述方法可以满足日益增长的发票开具需求。

图13为本发明实施例的应用系统的系统信令图。如图13所示，所述应用系统包括外卖平台服务器131、企业财务终端132和外卖平台财务终端133。

步骤S100'、获取订单信息并根据所述订单信息构建至少一个满足发票开具条件的账单信息。

具体地，由外卖平台服务器131获取预设时间段内的订单信息并根据所述订单信息构建至少一个满足发票开具条件的账单信息。其中，所构建的各账单信息处于待申请状态。

步骤S200'、发送所述各账单信息。

具体地，外卖平台服务器131将构建好的账单信息发送给企业财务终端132。

步骤S300'、在发票管理页面中显示所述各账单信息。

具体地，企业财务终端132在接收到账单信息后，会将所述各账单信息显示在发票管理页面中，以便企业财务人员可以在所述发票管理页面中查看当前所能够开具发票的账单信息。其中，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求。

步骤S400'、响应于接收到针对目标账单信息的开具请求，获取发票数据。

具体地，当企业财务终端132接收到针对目标账单信息的开具请求后，可以显示与目标账单信息对应的发票申请页面，由企业财务人员在所述发票申请页面中填写发票数据。在填写完成后，企业财务终端132会获取填写好的发票数据。其中，所述发票数据用于表征发票开具请求方，也即企业财务人员对于发票开具的需求信息。

步骤S500'、发送发票数据。

具体地，在企业财务终端132获取到发票数据后，将所获取发票数据发送给外卖平台财务终端133，以进行后续发票开具操作。

步骤S600'、根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态。

具体地，外卖平台财务终端133接收到发票数据后，可以调用相应的发票开具接口来为企业财务人员开具发票。

图14为本发明实施例的信息交互装置的示意图。如图14所示，本发明实施例的页面显示装置包括账单信息构建单元141、显示单元142、获取单元143和发票开具单元144。

具体地，账单信息构建单元141，用于获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态；

显示单元142，用于在发票管理页面中显示所述各账单信息，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求；

获取单元143，用于响应于接收到针对目标账单信息的开具请求，获取发票数据，所述发票数据用于表征开具请求方对于发票开具的需求信息；

发票开具单元144，用于根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态；

其中，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。

本发明实施例的信息交互装置在获取预设时间段内的订单信息后，会根据所述订单信息构建至少一个满足发票开具条件且处于待申请状态的账单信息，并在发票管理页面中显示所述各账单信息。响应于接收到针对目标账单信息的开具请求，获取发票数据，根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态。其中，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求，所述发票数据用于表征开具请求方对于发票开具的需求信息，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。通过所述装置可以满足日益增长的发票开具需求。

图15是本发明实施例的电子设备的示意图。在本实施例中，电子设备包括服务器、终端等。如图15所示，该电子设备：至少包括一个处理器151；以及，与至少一个处理器151通信连接的存储器152；以及，与扫描装置通信连接的通信组件153，通信组件153在处理器151的控制下接收和发送数据；其中，存储器152存储有可被至少一个处理器151执行的指令，指令被至少一个处理器151执行以实现上述信息交互方法。

具体地，该电子设备包括：一个或多个处理器151以及存储器152，图15中以一个处理器151为例。处理器151、存储器152可以通过总线或者其他方式连接，图15中以通过总线连接为例。存储器152作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。处理器151通过运行存储在存储器152中的非易失性软件程序、指令以及模块，从而执行设备的各种功能应用以及信息交互，即实现上述信息交互方法。

存储器152可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储选项列表等。此外，存储器152可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器152可选包括相对于处理器151远程设置的存储器，这些远程存储器可以通过网络连接至外接设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

一个或者多个模块存储在存储器152中，当被一个或者多个处理器151执行时，执行上述任意方法实施例中的信息交互方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果，未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本发明的另一个实施例涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-On lyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明实施例公开了A1、一种信息交互方法，所述方法包括：

获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态；

在发票管理页面中显示所述各账单信息，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求；

响应于接收到针对目标账单信息的开具请求，获取发票数据，所述发票数据用于表征开具请求方对于发票开具的需求信息；

根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态；

其中，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。

A2、根据A1所述的方法，所述账单信息为获得同一账户授权的不同终端所产生的订单信息汇总。

A3、根据A1所述的方法，在根据所述发票数据调用发票开具接口以开具发票之前，所述方法还包括：

响应于所述目标账单信息的发票数据满足审核限制条件，将所述发票数据移入待审核列表，并将所述目标账单信息的状态调整为审核中状态；

响应于接收到针对所述目标账单信息的审核成功信息，将所述目标账单信息的状态调整为开具中状态。

A4、根据A3所述的方法，所述方法还包括：

响应于接收到针对所述目标账单信息的审核失败信息，反馈所述审核失败信息；

将所述目标账单信息的状态调整为审核失败状态，所述处于审核失败状态的目标账单信息将不再执行后续的开具发票操作。

A5、根据A1所述的方法，在根据所述发票数据调用发票开具接口以开具发票之前，所述方法还包括：

响应于所述目标账单信息的发票数据不满足审核限制条件，将所述目标账单信息的状态调整为开具中状态。

A6、根据A3或5所述的方法，所述目标账单信息的发票数据满足审核限制条件包括：

所述目标账单信息的发票数据中的开具金额大于预设金额阈值。

A7、根据A3所述的方法，所述处于审核中状态的目标账单信息在所述发票记录页面中包括取消申请控件，所述取消申请控件用于触发取消请求；

在根据所述发票数据调用发票开具接口以开具发票之前，所述方法还包括：

响应于接收到所述取消请求，停止执行后续的开具发票操作；

将所述目标账单信息的状态调整为取消状态。

A8、根据A3所述的方法，所述方法还包括：

响应于执行所述开具发票操作失败，将所述目标账单信息的状态调整为开具失败状态。

A9、根据A8所述的方法，所述处于开具失败状态的目标账单信息在所述发票记录页面中包括重新申请控件，所述重新申请控件用于重新请求开具发票。

A10、根据A3所述的方法，在根据所述发票数据调用发票开具接口以开具发票之后，所述方法还包括：

响应于接收到退票请求，执行退票操作；

将所述目标账单信息的状态调整为退票中状态。

A11、根据A10所述的方法，所述方法还包括：

响应于执行所述退票操作失败，将所述目标账单信息的状态调整为退票失败状态；或者

响应于执行所述退票操作成功，将所述目标账单信息的状态调整为退票成功状态。

A12、根据A1所述的方法，所述根据所述订单信息构建至少一个满足发票开具条件的账单信息包括：

获取开具条件信息；

将所述订单信息中符合所述开具条件信息的订单信息确定为目标订单信息；

根据预设分组规则，将所述各目标订单信息分为至少一个目标订单信息组；

根据所述各目标订单信息组，构建对应的账单信息，其中，所述账单信息的可开具金额信息为对应目标订单信息组中各目标订单信息的金额信息汇总。

A13、根据A12所述的方法，所述根据预设分组规则，将所述各目标订单信息分为至少一个目标订单信息组包括：

按照所述订单信息的开具内容，将所述各目标订单信息分为至少一个目标订单信息组。

A14、根据A12所述的方法，所述发票管理页面中显示的账单信息中包括可开具金额信息、已开具金额信息以及待开具金额信息；

其中，所述已开具金额信息为对应账单信息的历史开具金额之和，所述待开具金额信息为所述可开具金额信息与所述已开具金额信息之差。

本发明实施例公开了B1、一种信息交互装置，所述装置包括：

账单信息构建单元，用于获取预设时间段内的订单信息，根据所述订单信息构建至少一个满足发票开具条件的账单信息，所述各账单信息处于待申请状态；

显示单元，用于在发票管理页面中显示所述各账单信息，所述各账单信息中包括申请控件，所述申请控件用于触发开具请求；

获取单元，用于响应于接收到针对目标账单信息的开具请求，获取发票数据，所述发票数据用于表征开具请求方对于发票开具的需求信息；

发票开具单元，用于根据所述发票数据调用发票开具接口以开具发票，并将所述目标账单信息的状态调整为开具成功状态；

其中，所述各状态用于指示对应账单信息在发票记录页面中的显示状态。

本发明实施例公开了C1、一种计算机可读存储介质，其上存储计算机程序指令，所述计算机程序指令在被处理器执行时实现如A1-14中任一项所述的方法。

本发明实施例公开了D1、一种电子设备，所述设备包括：

存储器，用于存储一条或多条计算机程序指令；

处理器，所述一条或多条计算机程序指令被所述处理器执行以实现如A1-14中任一项所述的方法。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。