一种延迟开票请求处理方法、装置及设备与流程

文档序号:31330869发布日期:2022-08-31 06:59阅读:152来源:国知局
一种延迟开票请求处理方法、装置及设备与流程

1.本技术涉及发票技术领域,尤其涉及一种延迟开票请求处理方法、装置及设备。


背景技术:

2.随着互联网技术的不断进步,电子商务得到了迅速发展。人们逐渐开始在因特网开放的网络环境下,去基于交易应用与支付应用进行各种商贸活动,以实现消费者与商户之间的交易活动。目前,消费者与商户之间在完成交易后,消费者还可以通过交易应用或支付应用向商户请求提供相应发票信息。若商户未按期提供发票信息,则交易应用或支付应用的服务商可以对商户进行处理,以保障消费者的权益。但目前,商户可能存在因不可抗力因素而无法按期提供发票信息的情况,从而使得商户需要及时与消费者去协商延迟开具发票的事情。
3.基于此,如何及时且高效的针对商户的延迟开票请求进行处理,成为了亟待解决的技术问题。


技术实现要素:

4.本说明书实施例提供的一种延迟开票请求处理方法、装置及设备,可以及时且高效的针对商户的延迟开票请求进行处理。
5.为解决上述技术问题,本说明书实施例是这样实现的:
6.本说明书实施例提供的一种延迟开票请求处理方法,包括:
7.获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供与所述目标交易对应的发票信息;
8.响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备;
9.接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息;
10.若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
11.本说明书实施例提供的一种延迟开票请求处理方法,包括:
12.获取目标交易的第一参与方针对所述目标交易的延迟开票操作;
13.响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息;
14.接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。
15.本说明书实施例提供的一种延迟开票请求处理装置,包括:
16.获取模块,用于获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供与所述目标交易对应的发票信
息;
17.第一发送模块,用于响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备;
18.接收模块,用于接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息;
19.时限确定模块,用于若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
20.本说明书实施例提供的一种延迟开票请求处理装置,包括:
21.第一获取模块,用于获取目标交易的第一参与方针对所述目标交易的延迟开票操作;
22.发送模块,用于响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息;
23.第一接收模块,用于接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。
24.本说明书实施例提供的一种延迟开票请求处理设备,包括:
25.至少一个处理器;以及,
26.与所述至少一个处理器通信连接的存储器;其中,
27.所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:
28.获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供与所述目标交易对应的发票信息;
29.响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备;
30.接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息;
31.若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
32.本说明书实施例提供的一种延迟开票请求处理设备,包括:
33.至少一个处理器;以及,
34.与所述至少一个处理器通信连接的存储器;其中,
35.所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:
36.获取目标交易的第一参与方针对所述目标交易的延迟开票操作;
37.响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息;
38.接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。
39.本说明书中提供的至少一个实施例能够实现以下有益效果:
40.在获取到目标交易的第一参与方的延迟开票请求消息后,发送延迟开票申请信息至目标交易的第二参与方的设备,若第二参与方反馈的操作信息指示允许延迟提供与所述目标交易对应的发票信息,则对所述发票信息的预设发票开具时限进行延迟。通过及时并高效地对第一参与方的延迟开票请求进行响应,使得商户可以及时与消费者协商延迟开具发票事项,不仅能够保障第二参与方的意愿及权益,同时,也有利于保障第一参与方的权益,以提升第一参与方与第二参与方的体验。
附图说明
41.为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本技术中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
42.图1为本说明书实施例提供的一种延迟开票请求处理方法的流程示意图;
43.图2为本说明书实施例提供的第一应用的一种应用界面的示意图;
44.图3为本说明书实施例提供的第一应用的另一应用界面的示意图;
45.图4为本说明书实施例提供的另一种延迟开票请求处理方法的流程示意图;
46.图5为本说明书实施例提供的对应于图1及图4中的延迟开票请求处理方法的泳道流程示意图;
47.图6为本说明书实施例提供的对应于图1的一种延迟开票请求处理装置的结构示意图;
48.图7为本说明书实施例提供的对应于图4的一种延迟开票请求处理装置的结构示意图;
49.图8为本说明书实施例提供的对应于图1的一种延迟开票请求处理设备的结构示意图;
50.图9为本说明书实施例提供的对应于图4的一种延迟开票请求处理设备的结构示意图。
具体实施方式
51.为使本说明书一个或多个实施例的目的、技术方案和优点更加清楚,下面将结合本说明书具体实施例及相应的附图对本说明书一个或多个实施例的技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本说明书的一部分实施例,而不是全部的实施例。基于本说明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本说明书一个或多个实施例保护的范围。
52.以下结合附图,详细说明本说明书各实施例提供的技术方案。
53.现有技术中,消费者与商户可以基于交易应用及支付应用开展交易,消费者还可以利用交易应用或支付应用处的通信功能与商户针对发票开具事项进行沟通,从而约定商户所需提供的发票信息及发票提供期限。若商户未按照约定期限提供发票,则交易应用或支付应用的服务器可以对商户进行处理,以提保障消费者的权益。但目前,商户在运营过程
中存在因自然灾害、本月发票额度耗尽等不可抗力因素,导致的无法按期提供发票的情况,从而使得商户需要及时与消费者去协商延迟开具发票的事情。基于此,如何在保证消费者的权益的基础上,及时且高效的针对商户的延迟开票请求进行处理,成为了急需解决的问题。
54.为了解决现有技术中的缺陷,本方案给出了以下实施例:
55.图1为本说明书实施例提供的一种延迟开票请求处理方法的流程示意图。从程序角度而言,该流程的执行主体可以为目标服务器,或者,目标服务器处搭载的应用程序。其中,所述目标服务器可以为第二参与方针对目标交易进行付款所使用的支付应用的服务端,或者,第二参与方执行目标交易所使用的交易应用的服务端。如图1所示,该流程可以包括以下步骤:
56.步骤102:获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供与所述目标交易对应的发票信息。
57.本说明书实施例中,第一参与方通常为商户,第二参与方通常为消费者。其中,第二参与方通常可以使用第二应用去执行目标交易,并管理目标交易的发票开具事项,所述第二应用可以包括:第二参与方针对目标交易进行付款所使用的支付应用,或者,第二参与方执行目标交易所使用的交易应用。
58.而第一参与方通常可以使用第一应用去管理目标交易及相应的发票开具事项。其中,第一应用既可以是交易应用的服务商提供给第一参与方使用的应用程序(例如,交易应用的商户客户端),也可以是第二参与方针对目标交易进行付款所使用的支付应用,或者,第一应用也可以是第一参与方自行开发、部署的应用程序或小程序;在实际应用中,小程序形式的第一应用可以搭载于所述交易应用或所述支付应用中。
59.基于此,当第一参与方需要延长提供目标交易对应的发票信息时,第一参与方可以通过对第一应用执行相应操作,以令该第一应用可以向目标服务器发送针对目标交易的延迟开票请求消息。对应的,目标服务器则可以获取到针对目标交易的延迟开票请求消息。
60.步骤104:响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备。
61.本说明书实施例中,第二参与方可以在其设备中搭载所述第二应用(例如,交易应用和/或支付应用),并在该第二应用处登录个人的已注册账户,以基于该第二应用去管理目标交易及发票开具事项。
62.基于此,当第一参与方请求延迟提供目标交易对应的发票信息时,目标服务器可以向第二参与方的设备处的第二应用发送延迟开票申请信息。该延迟开票申请信息可以反映第一参与方请求延迟提供目标交易对应的发票信息。在实际应用中,该延迟开票申请信息还可以反映第一参与方延迟提供发票信息的理由和/或预计延期时长等信息。例如,该延迟开票申请信息可以为:“商户因自然灾害因素发起了延迟开票申请,请指示是否同意。若同意,则对预设发票开具时限延迟15天”等。通过在第二参与方的设备处的第二应用处展示该延迟开票申请信息,以令第二参与方知晓第一参与方需要延迟提供发票的事项。
63.步骤106:接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息。
64.本说明书实施例中,在第二参与方的第二应用处展示该延迟开票申请信息后,第二参与方还可以对该第二应用执行操作,以令该第二应用可以发送其针对该延迟开票申请
信息反馈的操作信息至目标服务器。
65.其中,所述操作信息可以反映第二参与方对于延迟开具发票事项的个人意愿。具体的,若第二参与方允许延迟提供发票信息,则该操作信息通常是基于第二参与方的指示允许延迟提供发票的操作而生成的,从而使得该操作信息可以指示允许延迟提供所述发票信息。否则,第二参与方可以执行指示不允许延迟提供发票的操作,以使得该操作信息可以指示不允许延迟提供所述发票信息。
66.步骤108:若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
67.本说明书实施例中,目标服务器需要根据第二参与方反馈的操作信息,去确定是否对目标交易对应的预设发票开具时限进行延迟,以保障第二参与方的发票开具意愿及权益。
68.具体的,若第二参与方反馈的操作信息指示允许延迟提供目标交易对应的发票信息,则可以表示第一参与方与第二参与方均具有允许延迟提供发票的意愿,从而可以对目标交易对应的预设发票开具时限进行延迟。其中,预设发票开具时限可以为第一参与方提供目标交易对应的发票信息而不会受到处理的最晚时刻,若第一参与方未在预设发票开具时限之前提供目标交易对应的发票信息,则目标服务器通常会对第一参与方进行惩罚性质的处理。从而促使第一参与方按期向第二参与方提供发票,以提升第一参与方对于发票请求的处理效率,以保障第二参与方的权益。
69.图1中的方法,响应于目标交易的第一参与方的延迟开票请求消息,发送延迟开票申请信息至目标交易的第二参与方的设备,若第二参与方反馈的操作信息指示允许延迟提供与所述目标交易对应的发票信息,则对所述发票信息的预设发票开具时限进行延迟。通过及时并高效地对第一参与方的延迟开票请求进行响应,使得商户可以及时与消费者协商延迟开具发票事项,不仅能够保障第二参与方的意愿及权益,同时,也有利于保障第一参与方的权益,以提升第一参与方与第二参与方的体验。
70.基于图1中的方法,本说明书实施例还提供了该方法的一些具体实施方案,下面进行说明。
71.本说明书实施例中,给出了令第一参与方基于第一应用,生成并发送延迟开票请求消息至目标服务器的实现方式。
72.具体的,步骤102:获取目标交易的第一参与方的延迟开票请求消息之前还可以包括:
73.发送所述目标交易的发票订单信息至第一设备;所述第一设备用于在第一应用处展示所述发票订单信息,所述发票订单信息包括所述目标交易的交易标识信息及所述预设发票开具时限。
74.对应的,步骤102:获取目标交易的第一参与方的延迟开票请求消息,具体可以包括:
75.获取所述第一参与方在预设发票开具时限内发送的延迟开票请求消息;所述延迟开票请求消息是基于所述第一参与方对于所述第一应用处的与所述发票订单信息对应的延迟开票控件进行触发而生成的。
76.本说明书实施例中,第二参与方与第一参与方在进行目标交易后,通常需要主动
执行请求开具目标交易对应的发票信息的操作,以令目标服务器可以生成并发送目标交易的发票订单信息至第一参与方的第一设备。第一设备会在其搭载的第一应用处展示该发票订单信息,以令第一参与方知晓其需要向第二参与方提供目标交易对应的发票信息。
77.在实际应用中,第二参与方与第一参与方之间执行目标交易的方式有多种,使得第二参与方可以采用多种方式去请求开具目标交易对应的发票信息。为便于理解,对此进行解释说明。
78.交易方式一
79.目标交易可以是第二参与方利用交易应用发起的与第一参与方之间的交易。具体的,第二参与方可以基于交易应用调用支付应用,以利用个人在所述支付应用处的资源,针对所述目标交易进行付款。其中,所述交易应用可以包括:电子商务平台以及第一参与方在支付应用处部署的小程序。
80.针对上述交易方式,第二参与方的交易应用处的商品展示页面、交易信息展示页面以及支付应用处的账单信息展示页面中,均可以设置有与目标交易对应的开票控件,使得第二参与方可以通过触发该开票控件,以执行请求开具目标交易对应的发票信息的操作,从而令目标服务器可以生成并发送目标交易的发票订单信息至第一参与方的第一设备。此时,第二参与方触发的开票控件所属的应用程序即为第二应用。
81.交易方式二
82.目标交易可以是线下交易。具体的,可以利用支付应用生成第二参与方的付款码图像,并将所述付款码图像展示给第一参与方,以针对目标交易进行付款。
83.在实际应用中,第二参与方可以在支付应用处生成利用该第二参与方的个人支付账户中的资源进行付款的第一付款码图像,以针对目标交易进行付款。
84.或者,若第二用户取得了针对第一用户在支付应用处的支付账户中的资源的使用权限,则第二用户可以在该支付应用处生成利用第一用户的支付账户中的资源进行付款的第二付款码图像,以针对目标交易进行付款。例如,第一用户可以为第二用户所在的企业,若目标交易为第二用户因公执行的交易,且可以向该第一用户申请报销时,第二用户可以使用基于该第一用户的支付账户中的资源进行付款的第二付款码图像,去针对目标交易进行付款,以简化报销流程。此时,第一用户与第二用户均可以作为第二参与方。
85.针对这种交易方式,各个第二参与方的支付应用处的账单信息展示页面中,均可以设置有与目标交易对应的开票控件,各个第二参与方均可以通过触发该开票控件,以执行请求开具目标交易对应的发票信息的操作,从而令目标服务器可以生成并发送目标交易的发票订单信息至第一参与方的第一设备。此时,第二参与方触发的开票控件所属的应用程序即为第二应用。
86.在实际应用中,所述发票订单信息可以包括:目标交易的交易标识信息及预设发票开具时限。其中,目标交易的交易标识信息可以为目标交易的订单编号等唯一标识该笔交易的信息。而预设发票开具时限可以反映第一参与方应提供目标交易对应的发票信息的最晚时间。
87.具体的,预设发票开具时限可以根据开票申请时间、预设开票时长及当前时刻而确定。例如,若预设发票开具时限为固定值形式,则预设发票开具时限可以为开票申请时间之后间隔预设开票时长的时刻。或者,若预设发票开具时限为可变值形式(例如,倒计时形
式),则预设发票开具时限可以为开票申请时间之后且间隔预设开票时长的时刻同当前时刻之间的时间差。
88.在实际应用中,若第二参与方在目标交易处于未完成状态时(即未将目标交易的交易金额支付给第一参与方时)执行了请求开具发票的操作,则开票申请时间可以为目标交易变更为已完成状态的时间。若第二参与方在目标交易处于已完成状态后(即已将目标交易的交易金额支付给第一参与方后)执行的请求开具发票的操作,则开票申请时间可以为该操作的发起时间。
89.为便于理解,对于目标交易对应的预设发票开具时限进行举例说明。假定,开票申请时间为2022年4月1日13时整,当前时刻为2022年4月1日16时整,预设开票时长5天,则预设发票开具时限可以为2022年4月6日13时整,或者,若预设发票开具时限为倒计时形式,则预设发票开具时限可以为4天21小时00分00秒。
90.除此之外,所述发票订单信息还可以包括:所需开具的发票类型信息,发票抬头信息,发票金额信息等,以便于第一参与方获知待开具的发票的相关信息。
91.图2为本说明书实施例提供的第一应用的一种应用界面的示意图。如图2所示,若第一参与方在第一应用处登录了其已注册账户,则第一应用的应用界面中可以展示第一参与方的企业名称以及发票列表,该发票列表中可以展示有第一参与方的各个交易的发票订单信息。同时,结合前面的实施例内容,可知,订单编号为123的发票订单信息可以为目标交易的发票订单信息。
92.在实际应用中,不同交易的发票订单所处的状态可能不同,例如,部分交易的发票订单可能处于等待开票状态、请求延迟开票状态、已开发票状态等中的任意一种状态,因此,可以根据各个交易的发票订单当前所处的状态进行分别展示(图2中未示出),以便于第一参与方对各个发票订单进行管理。
93.在实际应用中,发票列表中还可以展示有与各个发票订单信息对应的延迟开票控件(图2未示出),以便于第一参与方触发该延迟开票控件去请求延迟提供相应发票信息。
94.当然,由于发票列表的展示空间有限,可能存在部分相关发票信息未完全展示的情况,因此,第一参与方还可以去查看更为详细完整的发票订单信息。基于此,图3为本说明书实施例提供的第一应用的另一应用界面的示意图。
95.如图3所示,第一参与方可以触发目标交易的发票订单信息,以在第一应用的应用界面中展示目标交易的发票详细信息,该应用界面中还可以展示有延迟开票控件,以便于第一参与方触发该延迟开票控件去请求延迟提供相应发票信息。
96.该应用界面中还可以展示有同意开票控件、修改发票详情控件、拒绝开票控件等。第一参与方可以通过触发同意开票控件,以利用第一应用的自动开具发票功能,去自动开具目标交易对应的发票信息。第一参与方也可以通过触发修改发票详情控件去直接修改发票详细信息中的部分信息。第一参与方还可以通过触发拒绝开票控件去拒绝生成目标交易对应的发票信息,并令第二参与方去修改发相关发票信息,以在第二参与方提供了正确的相关发票信息后,再开具目标交易对应的发票信息。
97.在实际应用中,第一参与方可能还需要提供延迟开具发票的理由,因此,第一应用的应用界面中还可以提供输入延迟开具发票的理由的控件(图2及图3中未示出),从而使得第一参与方在触发该延迟开票控件后,可以生成并发送携带有延迟开票理由的延迟开票请
求消息至目标服务器。当然,也可以预先设置多个延迟开具发票的理由选项以供第一参与方选择,有利于提升第一参与方的操作便捷性。
98.在实际应用中,第一参与方通常需要在到达目标交易对应的预设发票开具时限之前去发起延迟开票请求消息,才会执行本说明书实施例中的延迟开票请求处理方法。而若第一参与方在到达目标交易对应的预设发票开具时限之后才发起延迟开票请求消息,则可以拒绝处理该延迟开票请求消息,从而有利于保证第二参与方的权益。
99.本说明书实施例中,还给出了令第二参与方反馈针对所述延迟开票申请信息的操作信息的实现方式。
100.具体的,步骤104:响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备之后,可以将该延迟开票申请信息展示于所述第二参与方的第二设备中的第二应用处,基于此,第二应用处还可以展示与该延迟开票申请信息对应的延迟开票审批控件。
101.则步骤106:接收所第二参与方针对所述延迟开票申请信息反馈的操作信息,具体可以包括:
102.接收第二参与方在预设操作时限内针对所述延迟开票审批控件的触发操作信息;或者,
103.若在预设操作时限内未获取到第二参与方针对所述延迟开票审批控件的触发操作信息,则将预设操作信息确定为所述第二参与方针对所述延迟开票申请信息反馈的操作信息;所述预设操作信息用于指示允许延迟提供所述发票信息,或者,所述预设操作信息用于指示不允许延迟提供所述发票信息。
104.本说明书实施例中,所述第二应用可以包括:所述第二参与方针对所述目标交易进行付款所使用的支付应用,或者,所述第二参与方执行所述目标交易所使用的交易应用。通过在第二应用处展示延迟开票审批控件,从而令第二用户可以通过触发该延迟开票审批控件,以生成针对延迟开票申请信息的操作信息,有利于提升第二用户反馈个人针对延迟开票事项的意愿时的操作便捷性。
105.本说明书实施例中,为避免第二参与方长时间不反馈针对延迟开票申请信息的操作信息,而影响发票开具业务的正常运行,可以预先设置预设操作时限。若第二参与方在该预设操作时限之内反馈了针对延迟开票申请信息的操作信息,则以第二参与方反馈的操作信息为准。而若第二参与方在该预设操作时限内未反馈针对延迟开票申请信息的操作信息,则可以将预设操作信息作为第二参与方反馈的操作信息,以保障延迟开票请求处理方法的正常运行。
106.在实际应用中,不同第二参与方对应的预设操作信息可以相同,也可以不同,对此不作具体限定。例如,可以预先根据第二参与方的设置指令,确定其对应的预设操作信息,或者,也可以第二参与方的相关用户数据,自动确定其对应的预设操作信息,此时,不同第二参与方对应的预设操作信息可以不相同。或者,将各个第二参与方对应的预设操作信息均设置为执行不允许延迟提供发票信息,则不同第二参与方对应的预设操作信息可以均相同。
107.本说明书实施例中,对预设发票开具时限进行延迟的实现方式有多种,不同实现方式下所延迟的时长存在差异性。在实际应用中,可以根据实际需求,选择任意一种实现方
式去延迟预设发票开具时限。为便于理解,对此进行解释说明。
108.实现方式一,第二参与方针对延迟开票申请信息反馈操作信息的耗时,不会对预设发票开具时限的延迟时长造成影响。
109.具体的,步骤108:若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟,可以包括:
110.若所述操作信息指示允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟预设时长,得到目标发票开具时限。
111.对应的,步骤106:接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息之后,还可以包括:
112.若所述操作信息指示不允许延迟提供所述发票信息,则禁止延迟所述发票信息的预设发票开具时限,得到目标发票开具时限。即将预设发票开具时限作为目标发票开具时限。
113.本实现方式中,第二参与方针对延迟开票申请信息反馈操作信息的耗时,通常不会影响针对预设发票开具时限的延迟结果,从而有利于保障第二参与方的发票开具意愿及权益。例如,无论第二参与方是在获取到延迟开票申请信息之后间隔一天后,亦或是间隔两天后,才针对延迟开票申请信息反馈操作信息,只要所述操作信息指示允许延迟提供所述发票信息,则得到的目标发票开具时限是相同的;或者,只要所述操作信息指示不允许延迟提供所述发票信息,则均会保持预设发票开具时限不变。
114.在实际应用中,针对预设发票开具时限延迟的预设时长可以根据需求进行灵活设置,例如,5天、15天等,对此不作具体限定。
115.实现方式二,第二参与方针对延迟开票申请信息反馈操作信息的耗时,会对预设发票开具时限的延迟时长造成影响。
116.具体的,步骤108:若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟,可以包括:
117.若所述操作信息指示允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟目标时长,得到目标发票开具时限;目标时长为预设时长与暂停计时时长之和;所述暂停计时时长为所述操作信息的发起时间与所述延迟开票请求消息的发起时间之差。
118.对应的,步骤106:接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息之后,还可以包括:
119.若所述操作信息指示不允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟所述暂停计时时长,得到目标发票开具时限。
120.本实现方式中,由于第一参与方在等待第二参与方反馈针对延迟开票申请信息的操作信息的过程中,通常会中止对于目标交易的发票信息的处理,因此,在对预设发票开具时限进行延迟时,可以考虑第二参与方针对延迟开票申请信息反馈操作信息的耗时,从而有利于保障第一参与方的权益。
121.在实际应用中,可以将第二参与方针对延迟开票申请信息反馈操作信息的耗时作为暂停计时时长,且无论所述操作信息是否指示允许延迟提供所述发票信息,均至少对所述发票信息的预设发票开具时限延迟所述暂停计时时长。其中,所述暂停计时时长可以为
第二参与方的操作信息的发起时间与所述延迟开票请求消息的发起时间之差,即所述暂停计时时长可以为第一参与方发起延迟开票请求的时刻与第二参与方反馈操作信息的时刻之间的时长。由于所述暂停计时时长需要根据实际情况确定,因此并非是固定值。
122.在实际应用中,若所述操作信息指示允许延迟提供所述发票信息,则不仅需要将预设发票开具时限延迟所述暂停计时时长,还需要再延迟预设时长,从而满足第一参与方请求延迟提供发票的需求。其中,预设时长可以根据实际需求设置,例如,5天、15天等。
123.本说明书实施例中,在第一参与方发起延迟开票请求消息之后,且在根据第二参与方反馈的操作信息确定目标发票开具时限之前,第一参与方还可以需要取消延迟开票请求。
124.基于此,步骤108:对所述发票信息的预设发票开具时限进行延迟之前,还可以包括:
125.获取目标交易的第一参与方的取消延迟开票请求消息;所述取消延迟开票请求消息用于取消延迟向目标交易的第二参与方提供与目标交易对应的发票信息。所述取消延迟开票请求消息可以是第一参与方通过触发第一应用处的与目标交易对应的取消延迟开票控件而生成的。
126.响应于所述取消延迟开票请求消息,可以将所述发票信息的预设发票开具时限作为目标发票开具时限。或者,可以将所述发票信息的预设发票开具时限延迟指定时长,得到目标发票开具时限;所述指定时长为步骤102中的所述延迟开票请求消息的发起时间与所述取消延迟开票请求消息的发起时间之差。
127.以及,响应于取消延迟开票请求消息,取消在第二参与方的第二应用处展示目标交易对应的延迟开票申请信息,以避免对第二参与方造成打扰。
128.在实际应用中,无论第一参与方是否请求延迟提供目标交易对应的发票信息,在第二参与方针对目标交易进行部分退款及修改相关发票信息后,都可以视为第二参与方重新针对目标交易发起的开票请求,因此,可以将目标交易对应的开票申请时间变更为针对目标交易完成部分退款的时间或者针对相关发票信息的修改操作的发起时间,从而需要重新确定目标交易对应的预设发票开具时限。此时,既可以在重新确定预设发票开具时限之后,令第一参与方重新发起延迟开票请求消息。或者,也可以在重新确定的预设发票开具时限的基础上,继续处理步骤102中发起的延迟开票请求消息,即在重新确定的预设发票开具时限上进行时长延迟操作,对此不作具体限定。
129.本说明书实施例中,在根据第二参与方针对延迟开票申请信息反馈的操作信息,重新确定目标交易对应的目标发票开具时限后,还需要将该目标发票开具时限反馈给第一参与方,以便于第一参与方知晓其延迟开票请求消息的处理结果。
130.基于此,得到目标发票开具时限之后,还可以包括:
131.发送所述目标发票开具时限至所述第一参与方的第一设备;所述第一设备用于在第一应用处展示所述目标发票开具时限。
132.本说明书实施例中,第一参与方在利用第一应用发送延迟开票请求消息之后,还能够基于该第一应用接收针对该延迟开票请求消息处理得到的目标发票开具时限,方便快捷。
133.在实际应用中,由于第一应用处展示的目标交易的发票订单信息可以包括预设发
票开具时限,因此,在获取到目标发票开具时限后,可以利用该目标发票开具时限替换该发票订单信息中的预设发票开具时限,从而便于第一参与方基于该发票订单信息管理目标交易的发票开具事项。
134.本说明书实施例中,在基于第一参与方的延迟开票请求消息,重新确定出目标交易对应的目标发票开具时限后,目标服务器还可以判断第一参与方是否按时提供了目标交易对应的发票信息,若否,则需要对第一参与方进行处理。
135.具体的,得到目标发票开具时限之后,还可以包括:
136.判断是否所述第一参与方在所述目标发票开具时限内向所述第二参与方提供了所述发票信息,得到判断结果。
137.若所述判断结果表示所述第一参与方在所述目标发票开具时限内向所述第二参与方提供所述发票信息,则可以表示第一参与方按时提供了目标交易对应的发票信息,从而可以跳转至结束。
138.若所述判断结果表示所述第一参与方未在所述目标发票开具时限内向所述第二参与方提供所述发票信息,则可以表示第一参与方未按时提供目标交易对应的发票信息,从而可以根据所述目标交易的交易信息,确定待转移资源量。
139.从所述第一参与方的资源池中,扣除所述待转移资源量的资源。
140.发放所述资源至所述第二参与方的账户。
141.发送反映所述资源的转移情况的资源转移提示信息至所述第一参与方的第一设备;所述第一设备用于在第一应用处展示所述资源转移提示信息。
142.本说明书实施例中,若第一参与方开具了电子发票、录入了纸质发票的发票代码、录入了纸质发票的物流信息或者提交了其他表明发票已提供的文件信息,则可以确定第一参与方向第二参与方提供了目标交易对应的发票信息。
143.本说明书实施例中,第一参与方通常需要向目标服务器预先转移一定数量的资源,以生成第一参与方的资源池,第一参与方还可以预先授权目标服务器对于该资源池中的资源的转移权限,从而在确定第一参与方未按期提供发票后,可以将第一参与方的待转移资源量的资源转移至第二参与方的账户,方便快捷。
144.在实际应用中,待转移资源量可以为预设比例的目标交易的交易额,例如,假定,目标交易的交易额为10元,预设比例为10%,则待转移资源量可以为10元。或者,待转移资源量可以为目标交易的交易额落入的数值区间对应的指定数值,例如,若所述目标交易的交易额落入(0,100],则待转移资源量可以为10元,而若所述目标交易的交易额落入(100,1000],则待转移资源量可以为20元。或者,待转移资源量也可以为指定数值,例如,无论目标交易的交易额是多少,待转移资源量可以均为10元。本说明书实施例中,待转移资源量的计算方法可以根据实际需求设置,对此不作具体限定。
145.在实际应用中,在发放所述待转移资源量的资源至第二参与方的账户时,既可以将所述待转移资源量的资金发放至第二参与方在支付应用处的支付账户。或者,也可以采用积分形式,将所述待转移资源量的积分发放至第二参与方在交易应用处的已注册账户,以令第二参与方可以基于交易应用处的已注册账户中的积分购买商品或者享受其他权益,对此不作具体限定。
146.在实际应用中,若在达到目标发票开具时限之前,第二参与方取消了开票申请或
者目标交易已经全部退款成功等,则也可以无需对第一参与方进行资源扣除处理,同时,也无需对第二参与方进行资源补偿处理,从而有利于保证第一参与方的体验及权益。
147.本说明书实施例中,对于商户因客观因素无法在开票周期内,按时交付发票给到消费者的情形,令商户可以主动发起延迟开票的申请,并基于双方意愿确定目标交易的目标发票开具时限。同时,若第一参与方未在目标发票开具时限内向第二参与方提供目标交易对应的发票,则利用第一参与方的资源去对第二参与方进行补偿,从而可以在保证第一参与方的权益的基础上,减少第一参与方推延提供发票的情况,以保障令第二参与方对于发票的权益。
148.基于与图1中所示的方案同样的思路,本说明书实施例还提供了另一种延迟开票请求处理方法。图4为本说明书实施例提供的另一种延迟开票请求处理方法的流程示意图。该流程的执行主体可以为第一参与方的设备,或者,该设备处搭载的目标应用(即第一应用)的应用程序。如图4所示,该流程可以包括:
149.步骤402:获取目标交易的第一参与方针对所述目标交易的延迟开票操作。
150.本说明书实施例中,参考图1中方案的实施例公开的内容,可知,第二参与方在执行请求开具目标交易对应的发票信息的操作后,目标服务器可以发送目标交易的发票订单信息至第一参与方的设备,通过在该设备处搭载的目标应用(即第一应用)处展示该发票订单信息,以令第一参与方基于该发票订单信息管理发票开具事项。该目标应用处还可以展示与目标交易的发票订单信息对应的延迟开票控件,以便于第一参与方通过触发该延迟开票控件,以执行针对所述目标交易的延迟开票操作。
151.即步骤402:获取目标交易的第一参与方针对所述目标交易的延迟开票操作之前,还可以包括:
152.获取服务器发送的目标交易(即第一应用)的发票订单信息;所述发票订单信息包括所述目标交易的交易标识信息及所述预设发票开具时限。在目标应用处展示所述发票订单信息以及与所述发票订单信息对应的延迟开票控件。
153.对应的,步骤402:获取目标交易的第一参与方针对所述目标交易的延迟开票操作,具体可以包括:
154.获取所述目标交易的第一参与方针对所述延迟开票控件的触发操作。
155.步骤404:响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息。
156.本说明书实施例中,步骤404发送至服务器的延迟开票请求消息,即为步骤102中目标服务器获取到的延迟开票请求消息,对此不作赘述。
157.步骤406:接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。
158.本说明书实施例中,由于第二参与方也能指示不允许延迟提供所述发票信息的操作信息,因此,所述目标发票开具时限还可以包括:所述服务器根据所述第二参与方的指示不允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行更新得到的时限。此时,目标发票开具时限既可以是预设发票开具时限,也可以是对目标发票开
具时限延迟暂停计时时长等到的;所述暂停计时时长为第二参与方的所述操作信息的发起时间与所述延迟开票请求消息的发起时间之差。
159.在实际应用中,由于第一参与方可以利用目标应用管理目标交易的相关事项,且目标应用处可以展示有目标交易的发票订单信息,因此,步骤406:接收所述服务器反馈的目标发票开具时限之后,还可以包括:在所述目标应用处展示所述目标发票开具时限。具体的,由于该发票订单信息中可以包含预设发票开具时限,因此,可以利用所述目标发票开具时限替换该发票订单信息中的预设发票开具时限,以便于第一参与方管理发票开具事项。
160.图4中的方法,通过令第一参与方可以基于其设备中搭载的应用程序,自行针对目标交易发起延迟开票请求消息,并能够在第二参与方允许延迟提供发票时,获取到延迟后的目标交易的目标发票开具时限,从而在保障第一参与方及第二参与方的开票意愿的基础上,令第一参与方可以及时、便捷地延迟开票期限。有利于提升第一参与方的体验与权益。
161.本说明书实施例中,若第一参与方未按时提供相应发票信息,则目标服务器可以将第一参与方的部分资源转移至第二参与方,基于此,步骤406:接收所述服务器反馈的目标发票开具时限之后,还可以包括:
162.接收所述服务器发送的资源转移提示信息;所述资源转移提示信息用于反映目标资源的转移情况,所述目标资源是在确定所述第一参与方未在所述目标发票开具时限内向所述第二参与方提供所述发票信息后,需要从所述第一参与方的资源池中转移至所述第二参与方的账户的资源。
163.在所述目标应用处展示所述资源转移提示信息,以便于第一参与方知悉资源转移情况。
164.图5为本说明书实施例提供的对应于图1及图4中的延迟开票请求处理方法的泳道流程示意图。如图5所示,该延迟开票请求处理流程可以涉及目标服务器、第一参与方、第二参与方等执行主体。
165.在延迟开票请求处理阶段,第一参与方可以针对第一应用处的与目标交易的发票订单信息对应的延迟开票控件进行触发,生成并发送延迟开票请求消息至目标服务器。目标服务器响应于所述延迟开票请求消息,可以发送延迟开票申请信息至第二参与方的设备。
166.第二参与方在预设操作时限内,可以针对第二应用处的与所述延迟开票申请信息对应的延迟开票审批控件进行触发,以将其生成的触发操作信息发送至目标服务器。对应的,目标服务器则可以接收到第二参与方针对所述延迟开票申请信息反馈的操作信息。或者,若目标服务器在预设操作时限内未获取到第二参与方针对延迟开票审批控件的触发操作信息,则可以将预设操作信息确定为第二参与方针对延迟开票申请信息反馈的操作信息。
167.若所述操作信息指示允许延迟提供所述发票信息,则目标服务器可以按照预设时长对所述发票信息的预设发票开具时限进行延迟,得到目标发票开具时限。当然,若所述操作信息指示不允许延迟提供所述发票信息,目标服务器也需要确定所述发票信息对应的目标发票开具时限,只是此时该目标发票开具时限并非是按照预设时长对预设发票开具时限进行延迟得到的。
168.在资源转移阶段,目标服务器可以判断第一参与方是否在目标发票开具时限内向
第二参与方提供了目标交易对应的发票信息,若是,则可以跳转至结束。否则,可以从第一参与方的资源池中,扣除待转移资源量的资源;发放所述资源至第二参与方的账户;以及,发送反映所述资源的转移情况的资源转移提示信息至第一参与方的设备。对应的,第一参与方的设备所搭载的第一应用处可以展示该资源转移提示信息,以便于第一参与方知悉资源转移情况。
169.基于同样的思路,本说明书实施例还提供了上述方法对应的装置。图6为本说明书实施例提供的对应于图1的一种延迟开票请求处理装置的结构示意图。如图6所示,该装置可以包括:
170.获取模块602,用于获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向目标交易的第二参与方提供与所述目标交易对应的发票信息。
171.第一发送模块604,用于响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备。
172.接收模块606,用于接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息;
173.时限确定模块608,用于若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
174.基于图6的装置,本说明书实施例还提供了该装置的一些具体实施方案,下面进行说明。
175.可选的,所述时限确定模块608,具体可以用于:
176.若所述操作信息指示允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟预设时长,得到目标发票开具时限。
177.所述时限确定模块608,还可以用于:
178.若所述操作信息指示不允许延迟提供所述发票信息,则禁止延迟所述发票信息的预设发票开具时限,得到目标发票开具时限。
179.可选的,图6中的装置,还可以包括:
180.暂停计时模块,用于暂停针对所述发票信息的提供耗时的计时;
181.所述时限确定模块608,具体可以用于:
182.若所述操作信息指示允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟目标时长,得到目标发票开具时限;所述目标时长为预设时长与暂停计时时长之和;暂停计时时长为所述操作信息的发起时间与所述延迟开票请求消息的发起时间之差。
183.所述时限确定模块608,还可以用于:
184.若所述操作信息指示不允许延迟提供所述发票信息,则将所述发票信息的预设发票开具时限延迟所述暂停计时时长,得到目标发票开具时限。
185.可选的,图6中的装置,还可以包括:
186.第二发送模块,用于发送所述目标发票开具时限至所述第一参与方的第一设备;所述第一设备用于在第一应用处展示所述目标发票开具时限。
187.可选的,图6中的装置,还可以包括:
188.第三发送模块,用于发送所述目标交易的发票订单信息至所述第一设备;所述第
一设备用于在所述第一应用处展示所述发票订单信息,所述发票订单信息包括所述目标交易的交易标识信息及所述预设发票开具时限。
189.所述获取模块602,具体可以用于:
190.获取所述第一参与方在所述预设发票开具时限内发送的延迟开票请求消息;所述延迟开票请求消息是基于所述第一参与方对于所述第一应用处的与所述发票订单信息对应的延迟开票控件进行触发而生成的。
191.可选的,图6中的装置,还可以包括:
192.判断模块,用于判断是否所述第一参与方在所述目标发票开具时限内向所述第二参与方提供了所述发票信息,得到判断结果。
193.资源量确定模块,用于若所述判断结果表示所述第一参与方未在所述目标发票开具时限内向所述第二参与方提供所述发票信息,则根据所述目标交易的交易信息,确定待转移资源量。
194.资源扣除模块,用于从所述第一参与方的资源池中,扣除所述待转移资源量的资源;
195.资源发放模块,用于发放所述资源至所述第二参与方的账户。
196.第四发送模块,用于发送反映所述资源的转移情况的资源转移提示信息至所述第一参与方的第一设备;所述第一设备用于在第一应用处展示所述资源转移提示信息。
197.可选的,所述延迟开票申请信息展示于所述第二参与方的第二设备中的第二应用处,所述第二应用处还展示有与所述延迟开票申请信息对应的延迟开票审批控件。所述第二应用可以包括:所述第二参与方针对所述目标交易进行付款所使用的支付应用,或者,所述第二参与方执行所述目标交易所使用的交易应用。
198.所述接收模块,具体用于接收所述第二参与方在预设操作时限内针对所述延迟开票审批控件的触发操作信息;或者,
199.若在预设操作时限内未获取到所述第二参与方针对所述延迟开票审批控件的触发操作信息,则将预设操作信息确定为所述第二参与方针对所述延迟开票申请信息反馈的操作信息;所述预设操作信息用于指示允许延迟提供所述发票信息,或者,所述预设操作信息用于指示不允许延迟提供所述发票信息。
200.基于同样的思路,本说明书实施例还提供了上述方法对应的装置。图7为本说明书实施例提供的对应于图4的一种延迟开票请求处理装置的结构示意图。如图7所示,该装置可以包括:
201.第一获取模块702,用于获取目标交易的第一参与方针对所述目标交易的延迟开票操作。
202.发送模块704,用于响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息。
203.第一接收模块706,用于接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。所述目标发票开具时限还包括:所述服务器根据所述第二参与方的指示不允许延迟提供所述发票信息的操作信息,对所述
发票信息的预设发票开具时限进行更新得到的时限。
204.基于图7的装置,本说明书实施例还提供了该装置的一些具体实施方案,下面进行说明。
205.可选的,图7的装置还可以包括:
206.第二获取模块,用于获取服务器发送的目标交易的发票订单信息;所述发票订单信息包括所述目标交易的交易标识信息及所述预设发票开具时限。
207.第一展示模块,用于在目标应用处展示所述发票订单信息以及与所述发票订单信息对应的延迟开票控件。
208.所述第一获取模块,具体用于获取所述目标交易的第一参与方针对所述延迟开票控件的触发操作。
209.可选的,图7的装置还可以包括:
210.第二接收模块,用于接收所述服务器发送的资源转移提示信息;所述资源转移提示信息用于反映目标资源的转移情况,所述目标资源是在确定所述第一参与方未在所述目标发票开具时限内向所述第二参与方提供所述发票信息后,需要从所述第一参与方的资源池中转移至所述第二参与方的账户的资源。
211.第三展示模块,用于在所述目标应用处展示所述资源转移提示信息。
212.基于同样的思路,本说明书实施例还提供了上述方法对应的设备。
213.图8为本说明书实施例提供的对应于图1的一种延迟开票请求处理设备的结构示意图。如图8所示,设备800可以包括:
214.至少一个处理器810;以及,
215.与所述至少一个处理器通信连接的存储器830;其中,
216.所述存储器830存储有可被所述至少一个处理器810执行的指令820,所述指令被所述至少一个处理器810执行,以使所述至少一个处理器810能够:
217.获取目标交易的第一参与方的延迟开票请求消息;所述延迟开票请求消息用于请求延迟向所述目标交易的第二参与方提供与所述目标交易对应的发票信息。
218.响应于所述延迟开票请求消息,发送延迟开票申请信息至所述第二参与方的设备。
219.接收所述第二参与方针对所述延迟开票申请信息反馈的操作信息。
220.若所述操作信息指示允许延迟提供所述发票信息,则对所述发票信息的预设发票开具时限进行延迟。
221.基于同样的思路,本说明书实施例还提供了上述方法对应的设备。
222.图9为本说明书实施例提供的对应于图4的一种延迟开票请求处理设备的结构示意图。如图9所示,设备900可以包括:
223.至少一个处理器910;以及,
224.与所述至少一个处理器通信连接的存储器930;其中,
225.所述存储器930存储有可被所述至少一个处理器910执行的指令920,所述指令被所述至少一个处理器910执行,以使所述至少一个处理器910能够:
226.获取目标交易的第一参与方针对所述目标交易的延迟开票操作。
227.响应于所述延迟开票操作,向服务器发送延迟开票请求消息;所述延迟开票请求
消息用于请求延迟向所述目标交易的第二参与方提供所述目标交易对应的发票信息。
228.接收所述服务器反馈的目标发票开具时限;所述目标发票开具时限是所述服务器根据所述第二参与方的指示允许延迟提供所述发票信息的操作信息,对所述发票信息的预设发票开具时限进行延迟得到的。
229.本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于图8及图9所示的设备而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
230.在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array,fpga))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字符系统“集成”在一片pld上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(hardware description language,hdl),而hdl也并非仅有一种,而是有许多种,如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等,目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
231.控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit,asic)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:arc 625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
232.上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,
或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字符助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
233.为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本技术时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
234.本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
235.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
236.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
237.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
238.在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
239.内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
240.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字符多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
241.还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的
包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个
……”
限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
242.本领域技术人员应明白,本技术的实施例可提供为方法、系统或计算机程序产品。因此,本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
243.本技术可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本技术,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
244.以上所述仅为本技术的实施例而已,并不用于限制本技术。对于本领域技术人员来说,本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本技术的权利要求范围之内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1