CN112016980A

CN112016980A - 行程***的开具方法、装置、服务器及存储介质

Info

Publication number: CN112016980A
Application number: CN201910465484.XA
Authority: CN
Inventors: 谭名钧; 卓越强; 辛建华; 赵浩辰; 盛理; 冯明鹏; 张颖; 喻佼焱; 王跃; 肖洁欣; 梁伟强; 王萌; 张瑞; 李伟宗; 刘春燕; 徐长胜; 张磊; 张雅楠; 彭君航; 梁轲
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-05-30
Filing date: 2019-05-30
Publication date: 2020-12-01

Abstract

本申请是关于一种行程***的开具方法、装置、服务器及存储介质，该方法包括：接收用户终端发送的开票请求；开票请求中包含车辆司机对应的车辆标识，以及支付凭证对应的支付时刻；根据车辆标识和支付时刻获取目标行程，目标行程是支付凭证对应的行程；开具目标行程对应的行程***。由于本申请实施例提供的方案能够令终端在完成一次付款操作后，直接申请开具行程***，具体查找目标行程的过程由服务器自动完成。因此，本申请能够减少用户的操作，提高行程***开具的效率。

Description

行程***的开具方法、装置、服务器及存储介质

技术领域

本申请实施例涉及电子***技术领域，特别涉及一种行程***的开具方法、装置、服务器及存储介质。

背景技术

在现代社会经济活动中，***是用于证明交易的具有法律效力的凭证。

在相关技术中，在一些出租车开具行程***的场景中，当用户支付费用后，若需要开具行程***，则需要用户扫描出租车的车载终端上提供的行程二维码，之后用户终端向服务器发送包含行程信息的开票申请，从而获取行程***。

然而，相关技术所示的行程***开具过程操作较为繁琐，导致行程***的开具效率较低。

发明内容

本申请实施例提供了一种行程***的开具方法、装置、服务器及存储介质，可以解决相关技术中行程***开具过程操作较为繁琐的问题，技术方案如下：

一方面，提供了一种行程***的开具方法，所述方法由服务器执行，所述方法包括：

接收用户终端发送的开票请求；所述开票请求是所述用户终端在通过第一帐户向第二帐户支付成功后展示支付凭证，并接收到对所述支付凭证的触发操作时发送的请求，所述第二帐户是车辆司机的资金帐户；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

根据所述车辆标识和所述支付时刻获取目标行程，所述目标行程是所述支付凭证对应的行程；

开具所述目标行程对应的行程***。

又一方面，提供了一种行程***的开具方法，所述方法由用户终端执行，所述方法包括：

在通过第一帐户向第二帐户支付成功后，展示支付凭证；所述第二帐户是车辆司机的资金帐户；

接收到对所述支付凭证的触发操作时，生成开票请求；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

向服务器发送所述开票请求，所述开票请求用于指示所述服务器根据所述车辆标识和所述支付时刻获取目标行程，并开具所述目标行程对应的行程***；所述目标行程是所述支付凭证对应的行程。

在通过第一帐户向第二帐户支付成功后，在第一应用界面中展示包含开票提醒控件的支付凭证；所述第二帐户是车辆司机的资金帐户，所述第一应用界面是母应用程序的应用界面；

接收到对所述开票提醒控件的触发操作时，展示第二应用界面，所述第二应用界面是子应用程序的应用界面，所述子应用程序依赖所述母应用程序运行；

接收到对所述第二应用界面中的开票申请控件的触发操作后，展示行程***提醒，所述行程***提醒用于提醒服务器已开具所述支付凭证对应的目标行程的行程***。

又一方面，提供了一种行程***的开具装置，所述装置包括：

开票请求接收模块，用于接收用户终端发送的开票请求；所述开票请求是所述用户终端在通过第一帐户向第二帐户支付成功后展示支付凭证，并接收到对所述支付凭证的触发操作时发送的请求，所述第二帐户是车辆司机的资金帐户；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

行程获取模块，用于根据所述车辆标识和所述支付时刻获取目标行程，所述目标行程是所述支付凭证对应的行程；

***开具模块，用于开具所述目标行程对应的行程***。

又一方面，提供了一种行程***的开具装置，所述装置包括：

第一凭证展示模块，用于在通过第一帐户向第二帐户支付成功后，展示支付凭证；所述第二帐户是车辆司机的资金帐户；

开票请求生成模块，用于接收到对所述支付凭证的触发操作时，生成开票请求；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

开票请求发送模块，用于向服务器发送所述开票请求，所述开票请求用于指示所述服务器根据所述车辆标识和所述支付时刻获取目标行程，并开具所述目标行程对应的行程***；所述目标行程是所述支付凭证对应的行程。

又一方面，提供了一种行程***的开具装置，所述装置包括：

第二凭证展示模块，用于在通过第一帐户向第二帐户支付成功后，在第一应用界面中展示包含开票提醒控件的支付凭证；所述第二帐户是车辆司机的资金帐户，所述第一应用界面是母应用程序的应用界面；

界面展示模块，用于在接收到对所述开票提醒控件的触发操作时，展示第二应用界面，所述第二应用界面是子应用程序的应用界面，所述子应用程序依赖所述母应用程序运行；

提醒展示模块，用于在接收到对所述第二应用界面中的开票申请控件的触发操作后，展示行程***提醒，所述行程***提醒用于提醒服务器已开具所述支付凭证对应的目标行程的行程***。

又一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现本申请实施例提供的行程***的开具方法。

本申请提供的技术方案可以包括以下有益效果：

本申请实施例提供的一种行程***的开具方法，能够在用户终端支付成功后，服务器根据车辆标识和支付时刻确定出目标行程，开具目标行程对应的行程***。由于本申请实施例提供的方案能够令终端在完成一次付款操作后，直接申请开具行程***，具体查找目标行程的过程由服务器自动完成。因此，本申请能够减少用户的操作，提高行程***开具的效率，并减少了车辆因等待开票在道路中停留的时间，从而减少了城市拥堵，提高了运营车辆的安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的一种行程***的开具***的框架图；

图2是本申请实施例提供的一种行程***的开具方法所涉及的场景示意图；

图3是本申请实施例提供的一种行程***的开具方法的流程图；

图4示出了本申请实施例提供的一种行程***的开具方法的方法流程图；

图5是基于图4所示的实施例提供的一种付款码展示页面的示意图；

图6是基于图4所示的实施例提供的一种付费页面的示意图；

图7是基于图4所示的实施例提供的一种支付凭证的示意图；

图8是基于图4所示的实施例提供的一种页面跳转的示意图；

图9是基于图4所示的实施例提供的一种第二应用界面的示意图；

图10是基于图4所示的实施例提供的一种开票处理进度查看界面；

图11是基于图4所示实施例提供的一种新到***通知的示意图；

图12是基于图4所示实施例提供的一种***详情的示意图；

图13是根据本申请实施例提供的一种行程***的开具方法的流程图；

图14示出了本申请实施例提供的一种行程***的开具方法的流程图；

图15是根据一示例性实施例示出的一种行程***的开具装置的结构方框图；

图16是根据一示例性实施例示出的一种行程***的开具装置的结构方框图；

图17是根据一示例性实施例示出的一种行程***的开具装置的结构方框图；

图18是根据一示例性实施例示出的一种服务器的结构示意图；

图19示出了本申请一个示例性实施例提供的用户终端1900的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

作为一种可能的实现方式，当用户终端执行本申请所介绍的行程***的开具方法时，用户终端能够通过预设应用实现该功能。可选地，该预设应用具备支付功能。在另一种可能的实现方式中，用户终端还可以通过预设应用中的小程序或者快应用实现本申请所介绍的行程***的开具方法，本申请对此不作限定。

请参考图1，图1是根据一示例性实施例示出的一种行程***的开具***的框架图。如图1所示，该行程***的开具***可以包括用户终端110和服务器120。可选地，该服务器120可以包括电子***服务器、车辆行程服务器、支付服务器和卡券服务器。可选地，该行程***的开具***还可以包括区块链***服务器和车载终端。

用户终端110可以是用户使用的移动终端，该移动终端能够通过无线网络与电子***服务器进行数据交换。可选地，该移动终端也能够通过无线网络与卡券服务器进行数据交换。在一种可能的实现方式中，用户终端110可以是手机、可穿戴智能设备或平板电脑等电子设备。

电子***服务器是云端设备。需要说明的是，电子***服务器既可以是一台服务器，也可以是多台服务器组成的服务器集群。当电子***服务器是一台服务器时，该服务器中也可以搭载其他软件***，本申请实施例对此不作限定。例如，在一种可能实现的方式中，电子***服务器可以同时搭载电子******和支付***。

车辆行程服务器是云端设备。该服务器用于接收位于运营车辆上的车载终端上传的运营数据，该运营数据用于指示每一笔订单的详细情况，以及，车辆的基本信息和司机的基本信息。在一种可能的场景中，该车辆行程服务器是由公共交通政务部门管理的***，用于对运营车辆的客观数据进行收集和处理。

车载终端是安装在运营车辆上的电子设备，该设备具备计价器的功能。车载终端能够在计费按钮被触发时，开始记录行驶距离和等待时长。同时，车载终端能够在计费按钮再次被触发时，确认本次行程结束，根据累计的行驶距离和累计的等待时长计算营运金额，并在车载终端的显示屏中显示该营运金额。可选地，车载终端还提供有纸质***的打印功能。也即，车载终端能够打印营运金额对应的纸质***。

支付服务器用于接收用户终端110发送的支付请求。支付服务器能够将登陆在用户终端110中的用户账户中支付金额的资金转入司机账户。需要说明的是，司机可以在运营车辆中张贴预先打印纸质版的付款图形码。在用户终端110扫描该付款图形码时，该用户终端110将向支付服务器发送支付请求。可选地，上述付款图形码也可以显示在车载终端的显示屏中，本申请实施例对付款图形码具体的显示位置不作限定。

区块链***服务器用于接收电子***服务器发送的区块链***生成请求，通过区块链技术生成防篡改可信任的行程***。区块链***服务器在根据电子***服务器提供的***抬头信息和支付金额开具行程***后，将该行程***发送至电子***服务器。

可选地，本申请提供的***中还包括卡券服务器。电子***服务器能够在开具行程***后，将该行程***发送至卡券服务器，由卡券服务器管理，并将该行程***发送至用户终端110中。

请参考图2，图2是本申请实施例提供的一种行程***的开具方法所涉及的场景示意图。在图2中，当用户210乘坐出租车到达目的地后，通过用户终端211扫描了出租车中张贴的司机收款图形码，并支付了乘车费用61元后，即可下车。支付服务器220接收用户终端211发送的支付请求，将乘车费用61元从用户终端211中登陆的用户账户中转账至司机收款图形码对应的司机账户中，并向电子***服务器发送该笔交易的信息，包括付款方的账号、收款方的账号、支付时刻和支付金额。

电子***服务器230根据上述交易中收款方的账号，查询预先从车辆行程服务器中备份的数据，获取到司机标识和司机标识对应的车牌号。需要说明的是，司机标识包括但不限于身份证号、驾驶证号、从业资格证号或身份标识号中至少一种。司机标识对应的车牌号指该司机标识当前驾驶的车牌号。可选地，当司机开始驾驶出租车时，将通过签到的方式，将自己的司机标识和车牌号在车辆行程服务器中进行绑定。电子***服务器230能够同步上述绑定后的信息。

电子***服务器230还能够根据车牌号获取支付时刻前指定时长内的行程信息。例如，电子***服务器230获取支付时刻前3分钟内的行程信息。在一种可能的方式中，当该3分钟内的行程信息是1条时，电子***服务器230将该行程信息对应的行程确认为目标行程。当目标行程的运营金额，即，车载终端显示的金额，与用户210支付的支付金额的差值属于预设金额区间时，电子***服务器230根据用户210提供的***抬头信息开具支付金额对应的电子***。

需要说明的是，预设金额区间是技术人员根据出租车所在地区的过路费用预先设定的区间。例如，在城市S中，过路费用最高设置为30元，并且司机收费抹零头上限设置为4元，则预设金额区间为[4,-30]。相应的，当车载终端显示的金额，与用户210支付的支付金额的差值不属于预设金额区间时，电子***服务器230将向用户终端210返回错误信息。例如，“***开具失败，如有问题，请联系人工客服”。

在另一个可能实现的场景中，在图2所示的行程***开具场景中，以支付时刻和支付金额为变量，对本方案是否开具行程***进行介绍。请参见表一，其中行程结束时刻和支付时刻均是2018年5月29日内的一个时刻，具体的时刻值请参见表格中的数值。

表一

需要说明的是，表一示出了4组用户支付乘车费用的场景。表一所示的行程结束时刻均是10时32分3秒，运营金额是43元。在序号1所示的数据中，用户实际的支付金额是40元，运营金额和支付金额的差值是3，3属于预设金额区间为[4,-30]，且行程结束时刻处于支付时刻的前3分钟内的时段中。因此，序号1所示的数据，符合行程***的开具条件，电子******将开具行程***。

在序号2所示的数据中，用户实际的支付金额是43元，电子******获取的支付时刻的前3分钟内的时段中，不存在行程。因此，序号2所示的数据，不符合行程***的开具条件，电子******将不开具行程***。

在序号3所示的数据中，用户实际的支付金额是61元，运营金额和支付金额的差值是-18，属于预设金额区间为[4,-30]，且行程结束时刻处于支付时刻的前3分钟内的时段中。因此，序号3所示的数据，符合行程***的开具条件，电子******将开具行程***。

在序号4所示的数据中，用户实际的支付金额是80元，运营金额和支付金额的差值是-37。由于-37不属于预设金额区间为[4,-30]。因此，序号4所示的数据，不符合行程***的开具条件，电子******不开具行程***。

需要说明的是，上述序号为1的数据的一种可能产生的场景，是出租车司机对乘客进行减免零头费用的操作。上述序号为4的数据的一种可能产生的场景，是用户多向司机支付了小费，或者，是司机接收了其它付款方转账的钱款。针对序号为4的数据，用户终端中可以显示错误信息，并提供申诉接口，以供用户向客服人员申诉，获取应当开具的行程***。

可选地，在上述场景中，行程结束时刻可以是处于计费状态的车载终端中计费按钮被触发的时刻。可选地，该行程结束时刻可以是车载终端停止计费的时刻。可选地，运营金额是车载终端中显示的费用金额。

请参考图3，图3是本申请实施例提供的一种行程***的开具方法的流程图。在图3所示的方法中，服务器和用户终端配合完成行程***的开具方法的流程，该方法包括：

步骤310，在通过第一帐户向第二帐户支付成功后，用户终端展示支付凭证。

其中，第二帐户是车辆司机的资金帐户。

步骤320，接收到对支付凭证的触发操作时，用户终端生成开票请求。

其中，开票请求中包含车辆司机对应的车辆标识，以及支付凭证对应的支付时刻。

步骤330，用户终端向服务器发送开票请求。

其中，开票请求用于指示服务器根据车辆标识和支付时刻获取目标行程，并开具目标行程对应的行程***；目标行程是支付凭证对应的行程。

相应的，服务器接收用户终端发送的开票请求。

其中，开票请求是用户终端在通过第一帐户向第二帐户支付成功后展示支付凭证，并接收到对支付凭证的触发操作时发送的请求，第二帐户是车辆司机的资金帐户；开票请求中包含车辆司机对应的车辆标识，以及支付凭证对应的支付时刻。

步骤340，服务器根据车辆标识和支付时刻获取目标行程，目标行程是支付凭证对应的行程。

步骤350，服务器开具目标行程对应的行程***。

在一种可能的实现方式中，服务器还可以将开具的行程***发送给用户终端。

综上，本申请实施例提供的一种行程***的开具方法，能够在用户终端支付成功后，服务器根据车辆标识和支付时刻确定出目标行程，开具目标行程对应的行程***。由于本申请实施例提供的方案能够令终端在完成一次付款操作后，直接申请开具行程***，具体查找目标行程的过程由服务器自动完成。因此，本申请能够减少用户的操作，提高行程***开具的效率，并减少了车辆因等待开票在道路中停留的时间，从而减少了城市拥堵，提高了运营车辆的安全性。

请参见图4，图4示出了本申请实施例提供的一种行程***的开具方法的方法流程图。在图4所示的方法中，服务器和用户终端配合完成行程***的开具方法的流程，该方法包括：

步骤411，服务器向用户终端发送支付凭证。

在本申请实施例中，支付凭证中包含开票提醒控件，开票提醒控件用于在触发时生成开票请求。

可选地，在本申请实施例中，用户能够在完成打车服务后，使用用户终端扫描付款二维码。需要说明的是，用户付款使用的是属于自己的第一帐户，付款二维码对应的是第二帐户，第二帐户是车辆司机的资金帐户。

请参考图5，其是基于图4所示的实施例提供的一种付款码展示页面的示意图。其中，付款二维码510是第二帐户的收款码，该界面中包括司机的主管部门标识520和司机的名字530。

在图5中，该付款二维码510可以是在A应用中展示的。司机的主管部门是S城市交通管理部门，司机的姓名是杰克。

步骤412，在通过第一帐户向第二帐户支付成功后，用户终端展示支付凭证。

在本申请实施例中，当用户扫描付款二维码成功后，用户终端将显示付款界面，将乘车费用转至第二帐户。当该支付成功后，服务器将向用户终端发送含有开票提醒控件的支付凭证。

请参考图6，图6是基于图4所示的实施例提供的一种付费页面的示意图。在图6中，包括乘车费用输入框610、付款控件620和备注控件630。用户能够在乘车费用输入框610中输入需要支付的乘车费用，能够通过触发付款控件620确认付款，能够通过触发备注控件630对该付款的订单添加备注。

请参考图7，图7是基于图4所示的实施例提供的一种支付凭证的示意图。在图7中，开票提醒控件710位于支付凭证700的最下方，详情控件720被点击时，将展示该支付凭证的详细信息。可选地，支付凭证700还包括支付金额、优惠信息、收款方、出租车辆的车牌信息和交易状态。

在另一种可能的实现方式中，终端能够获取车辆标识对应的签到状态标识。当车辆标识对应的车辆的签到状态标识。该签到状态标识用于指示对应的车辆最近一次签到签退操作具体的内容。

在一种可能的场景中，若用0表示最近一次的操作是签到，用1表示最近一次的操作是签退，则当服务器获取到签到状态标识是0时，该签到状态标识用于指示对应的车辆的司机处于在岗状态。在此场景中，说明司机标识对应的司机处于在岗状态。

当签到状态标识指示车辆司机在岗时，向用户终端发送支付凭证。

步骤413，用户终端接收到对支付凭证的触发操作时，生成开票请求。

在本申请实施例中，步骤413的执行方式与步骤320的执行方式相同，该执行方式可参考步骤320的执行方式。

在一种可能的实现方式中，触发操作可以是点击操作、双击操作或长按操作等触摸操作中的至少一种，本申请实施例对此不作限定。

需要说明的是，用户终端生成的开票请求中包括车辆司机对应的车辆标识，以及支付凭证对应的支付时刻。可选地，由于支付凭证中携带有车牌号，开票请求中可以直接将车牌号作为车辆司机对应的车辆标识。

在一种可能的实现方式中，车辆标识可以是车票号码、行驶证号、运营证号、发动机号或车架号中任意一种能够唯一表示车辆的标识，本申请实施例对此不作限定。

需要说明的是，作为一种细化的方案。在本申请的一种可能的实现方式中，步骤412所示的功能能够被用户终端通过执行步骤(10)和步骤(20)来实现。

步骤(10)，在通过第一帐户向第二帐户支付成功后，接收服务器发送的支付凭证。

步骤(20)，展示包含开票提醒控件的支付凭证，开票提醒控件用于在触发时生成开票请求。

在本申请的一种可能的实现方式中，步骤(20)所示的功能能够被用户终端通过执行步骤(21)来实现。同时，步骤413所示的功能能够被用户终端通过执行步骤(22)和步骤(23)来实现。

步骤(21)，用户终端在第一应用界面中展示支付凭证。

在本申请实施例中，第一应用界面是母应用程序的应用界面。需要说明的是，在一种可能的实现方式中，母应用程序是能够运行子应用程序的应用。在一种实现方式中，母应用程序可以是安卓操作***或苹果操作***中由安装包安装的应用程序，子应用程序可以是小程序。

在本实施例中，用户终端能够在第一应用界面中展示支付凭证。

步骤(22)，接收到对开票提醒控件的触发操作时，用户终端展示第二应用界面。

在本申请实施例中，第二应用界面是子应用程序的应用界面，子应用程序依赖母应用程序运行。

需要说明的是，在一种可能的实现方式中，当用户终端接收到对开票提醒控件的触发操作时，将从母应用程序程序的用户界面跳转到子应用程序的应用界面，实现启动子应用程序的功能。

步骤(23)，根据在第二应用界面中设置的开票信息生成开票请求。

在本申请实施例中，开票信息包括开票金额、开票类型以及***抬头中的至少一种。

请参考图8，图8是基于图4所示的实施例提供的一种页面跳转的示意图。在图8中的第一应用界面810中，显示有开票提醒控件811，当该开票提醒控件811被触发时，用户终端显示第二应用界面820，第二应用界面820中显示有开票金额输入框821、开票类型设置控件822和***抬头设置控件823中至少一种。需要说明的是，开票金额、开票类型以及***抬头中的信息可以是默认的信息，当开票提醒控件811被触发，直接根据默认的信息生成开票请求。

例如，开票金额的默认值可以是支付凭证中对应数值。开票类型可以是用户事先预设的类型。***抬头也可以是用户事先预设的抬头信息。在此基础上，用户终端可以在第二应用界面中提供上述信息的设置控件，也可以不提供，采用默认值。

在一种可能的实现方式中，用户终端通过两个第二应用界面设置开票信息。该两个第二应用界面分别是第一子界面和第二子界面。

请参照图9，图9是基于图4所示的实施例提供的一种第二应用界面的示意图。在图9的第一应用界面910中，显示有开票提醒控件911，当该开票提醒控件911被触发时，用户终端显示第一子界面920。在第一子界面920中，显示有子应用程序“出租车助手”提供的行程信息。在第一子界面920中，开票金额已被默认设置为支付凭证中对应数值61元。可选地，第一子界面920中还显示有点赞按钮921，当点赞按钮921被触发时，司机将获得好评。第一子界面920中还显示有开票申请按钮922，当开票申请按钮922被触发时，用户终端显示第二子界面930。在第二子界面930中，包括***类型选择控件931和***抬头选择控件932。需要说明的是，在一种可能的方式中，***抬头包括抬头名称和税号。在第二子界面930中，还显示有提交按钮933，当提交按钮933被触发后，用户终端将生成开票请求。

步骤414，用户终端向服务器发送开票请求。

相应的，服务器接收用户终端发送的开票请求。

请参见图10，图10是基于图4所示的实施例提供的一种开票处理进度查看界面。在图10中，显示有三个阶段信息，分别是“提交申请”阶段1001、“交委平台审核”阶段1002和“开票完成”阶段1003。每一个阶段左侧对应一个进度标识，该标识用于指示当前阶段是否已被执行。在图10中，“提交申请”阶段1001左侧的进度标识1004被点亮，说明“提交申请”阶段1001已被执行。“交委平台审核”阶段1002左侧的进度标识1005没有被点亮，且，“开票完成”阶段1003左侧的进度标识1006也没有被点亮，说明“交委平台审核”阶段1002和“开票完成”阶段1003都没有被执行。完成按钮1007被触发时，关闭该进度查看界面1000。

步骤415，服务器将指定时段内的行程获取为候选行程。

步骤416，在候选行程中确定目标行程。

在本申请实施例中，目标行程是行程结束时刻与支付时刻之间的时长最短的候选行程。需要说明的是，服务器还可以查询目标行程对应的车载***开票状态，当目标行程对应的纸质***已经开具时，终端将不再执行后续开具行程***的步骤。

在本申请实施例中，指定时段是以支付时刻为开始时刻的指定时长的时间段。例如，支付时刻是2018年5月29日13时22分30秒，且指定时长是3分钟，则指定时段是开始时刻是2018年5月29日13时22分30秒，结束时刻是2018年5月29日13时25分30秒的时段。

在一种可能的实现方式中，当候选行程的数量是1个时，服务器直接将该候选行程确定为目标行程。

在另一种可能的实现方式中，当候选行程的数量是至少2个时，服务器将比较至少2个候选行程各自的行程结束时刻距支付时刻的时长，电子***服务器将行程结束时刻距支付时刻最近的候选行程确定为目标行程。

例如，当开始时刻是2018年5月29日13时22分30秒，结束时刻是2018年5月29日13时25分30秒的时段的指定时段中存在2个候选行程。候选行程A的行程结束时刻是2018年5月29日13时22分37秒，候选行程B的行程结束时刻是2018年5月29日13时25分15秒。则候选行程A的行程结束时刻距离支付时刻较近，候选行程A被确定为目标行程。

步骤417，当支付凭证对应的支付金额符合预设条件时，开具目标行程对应的行程***。

在本申请实施例中，预设条件包括支付金额与行程金额的差值属于预设金额区间，行程金额是目标行程对应的金额。

例如，在城市S中，过路费用最高设置为30元，并且司机收费抹零头上限设置为4元，则预设金额区间为[-4,30]。需要说明的是，行程金额是车载终端或者计价器中显示的金额。当支付金额与行程金额的差值属于预设金额区间为[-4,30]，则服务器开具目标行程对应的行程***。

在另一种可能实现的方式中，服务器能够通过执行步骤(31)和步骤(32)以实现开具目标行程对应的行程***的功能。

步骤(31)，向区块链服务器发送区块链开票请求。

步骤(32)，接收区块链服务器发送的行程***，行程***是区块链服务器基于区块链技术开具的行程***。

需要说明的是，该开具的行程***是基于区块链开具的，具有防篡改，且真实可信的特点。

在服务器开具行程***后，服务器可以将该行程***发送至用户终端。

在一种可能的方式中，电子***服务器将行程***发送至卡券服务器，卡券服务器将记录该行程***，并将行程***的数据提供给用户终端。

在一种可能的方式中，当行程***开具完毕后，用户终端将显示新到***通知，当详情控件被触发时，将显示***详情页面。

请参见图11，其是基于图4所示实施例提供的一种新到***通知的示意图。在图11中，新到***通知的用户界面中显示有收款方1110、付款方1120、开票金额1130、开票时间1140、备注1150和详情控件1160。

请参见图12，其是基于图4所示实施例提供的一种***详情的示意图。当详情控件1160被触发时，用户终端显示***详情页面1200，在图12中，显示有收款方1210、付款方1220、开票金额1230、开票时间1240、项目1250、抽奖控件1260、转发邮箱控件1270、分享朋友控件1280和公众号跳转控件1290。

综上所述，本申请实施例能够通过获取车辆标识对应的签到状态标识确定车辆司机是否在岗，从而能够在用户实际支付费用时及时显示开票提醒控件，便于用于及时申请开具行程***。

另外，用户终端还能够在母程序界面中激发子程序的界面显示，通过子程序的界面显示提供开票信息的修改，提高了填写***信息的效率。

另外，服务器还能够通过区块链服务器开具行程***，使得行程***能够防篡改，提高了行程***的安全性。

请参考图13，图13是根据本申请实施例提供的一种行程***的开具方法的流程图。该方法应用在用户终端中，在图13中，该方法包括：

步骤1310，在通过第一帐户向第二帐户支付成功后，在第一应用界面中展示包含开票提醒控件的支付凭证。

在本申请实施例中，第二帐户是车辆司机的资金帐户，第一应用界面是母应用程序的应用界面；

步骤1320，接收到对开票提醒控件的触发操作时，展示第二应用界面。

在本申请实施例中，第二应用界面是子应用程序的应用界面，子应用程序依赖母应用程序运行；

步骤1330，接收到对第二应用界面中的开票申请控件的触发操作后，展示行程***提醒。

在本申请实施例中，行程***提醒用于提醒服务器已开具支付凭证对应的目标行程的行程***。

需要说明的是，请参见图11，图11所示的界面是一种行程***提醒的形式。

综上所述，用户终端能够在通过第一帐户向第二帐户支付成功后，在母应用程序的应用界面中显示包含开票提醒控件的支付凭证，在接收到对开票提醒控件的触发操作时，展示依赖母应用程序的子应用程序的应用界面，在接收到针对子应用程序的应用界面中的开票申请控件的触发操作后，展示行程***提醒，该行程用于提醒服务器已开具支付凭证对应的目标行程的行程***。由于行程***能够在用户终端触发一次开票提醒控件时，即可开具，节省了用户开具行程***的步骤，提高了行程***的开具效率。

请参考图14，图14示出了本申请实施例提供的一种行程***的开具方法的流程图。图14所示的方法由用户终端、电子***服务器、车辆行程服务器、支付服务器、卡券服务器、区块链***服务器和车载终端配合完成。

步骤1401，电子***服务器向车辆行程服务器查询新增司机注册记录。

步骤1402，电子***服务器记录新增司机的注册信息。

步骤1403，车载终端接收司机的签到操作。

步骤1404，车载终端向车辆行程服务器发送司机的签到信息。

步骤1405，当乘客开始乘车时，车载终端开始计费。

步骤1406，当目标行程结束时，车载终端停止计费。

步骤1407，车载终端向车辆行程服务器发送目标行程的信息。

步骤1408，用户终端向支付服务器发送支付请求。

步骤1409，支付服务器按照支付请求，完成用户终端通过第一帐户向车辆司机的第二帐户付款的操作。

步骤1410，支付服务器向电子***服务器同步目标行程的支付信息。

步骤1411，电子***服务器向车辆行程服务器核实司机的在岗情况。

步骤1412，当司机在岗时，电子***服务器向用户终端发送出租车行程服务通知。

步骤1413，用户终端向电子***服务器发送开票请求。

步骤1414，电子***服务器根据开票请求从车辆行程服务器中匹配目标行程。

步骤1415，当电子***服务器匹配到目标行程时，向区块链***服务器发出开票请求。

步骤1416，区块链***服务器根据开票请求开具行程***。

步骤1417，区块链***服务器向电子***服务器发送行程***。

步骤1418，电子***服务器将行程******卡券服务器中。

步骤1419，电子***服务器向用户终端发送开票结果通知。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图15是根据一示例性实施例示出的一种行程***的开具装置的结构方框图。该行程***的开具装置可以用于服务器中，以执行图3或图4所示实施例中，由服务器执行的全部或者部分步骤。该行程***的开具装置可以包括：

开票请求接收模块1510，用于接收用户终端发送的开票请求；所述开票请求是所述用户终端在通过第一帐户向第二帐户支付成功后展示支付凭证，并接收到对所述支付凭证的触发操作时发送的请求，所述第二帐户是车辆司机的资金帐户；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

行程获取模块1520，用于根据所述车辆标识和所述支付时刻获取目标行程，所述目标行程是所述支付凭证对应的行程；

***开具模块1530，用于开具所述目标行程对应的行程***。

可选地，在所述接收用户终端发送的开票请求之前，所述装置还包括：凭证发送模块；

所述凭证发送模块，用于向所述用户终端发送所述支付凭证，所述支付凭证中包含开票提醒控件，所述开票提醒控件用于在触发时生成所述开票请求。

可选地，所述装置还包括：签到标识获取模块；

所述签到标识获取模块，用于获取所述车辆标识对应的签到状态标识；

所述凭证发送模块，用于当所述签到状态标识指示所述车辆司机在岗时，向所述用户终端发送所述支付凭证。

可选地，行程获取模块1520，用于：

将指定时段内的行程获取为候选行程，所述指定时段是以所述支付时刻为开始时刻的指定时长的时间段；

在所述候选行程中确定所述目标行程，所述目标行程是行程结束时刻与所述支付时刻之间的时长最短的所述候选行程。

可选地，***开具模块1530，用于：

当支付凭证对应的支付金额符合预设条件时，开具所述目标行程对应的所述行程***，所述预设条件包括所述支付金额与行程金额的差值属于预设金额区间，所述行程金额是所述目标行程对应的金额。

可选地，***开具模块1530，用于：

向区块链服务器发送区块链开票请求；

接收所述区块链服务器发送的所述行程***，所述行程***是所述区块链服务器基于区块链技术开具的所述行程***。

图16是根据一示例性实施例示出的一种行程***的开具装置的结构方框图。该行程***的开具装置可以用于用户终端中，以执行图3或图4所示实施例中，由用户终端执行的全部或者部分步骤。该行程***的开具装置可以包括：

第一凭证展示模块1610，用于在通过第一帐户向第二帐户支付成功后，展示支付凭证；所述第二帐户是车辆司机的资金帐户；

开票请求生成模块1620，用于接收到对所述支付凭证的触发操作时，生成开票请求；所述开票请求中包含所述车辆司机对应的车辆标识，以及所述支付凭证对应的支付时刻；

开票请求发送模块1630，用于向服务器发送所述开票请求，所述开票请求用于指示所述服务器根据所述车辆标识和所述支付时刻获取目标行程，并开具所述目标行程对应的行程***；所述目标行程是所述支付凭证对应的行程。

可选地，所述在通过第一帐户向第二帐户支付成功后，第一凭证展示模块1610，用于：

在通过所述第一帐户向所述第二帐户支付成功后，接收所述服务器发送的所述支付凭证；

展示包含开票提醒控件的所述支付凭证，所述开票提醒控件用于在触发时生成所述开票请求。

可选地，第一凭证展示模块1610，用于：

在第一应用界面中展示所述支付凭证，所述第一应用界面是母应用程序的应用界面；

开票请求生成模块1620，用于

根据在所述第二应用界面中设置的开票信息生成所述开票请求；所述开票信息包括开票金额、开票类型以及***抬头中的至少一种。

图17是根据一示例性实施例示出的一种行程***的开具装置的结构方框图。该行程***的开具装置可以用于用户终端中，以执行图3或图4所示实施例中，由用户终端执行的全部或者部分步骤。该行程***的开具装置可以包括：

第二凭证展示模块1710，用于在通过第一帐户向第二帐户支付成功后，在第一应用界面中展示包含开票提醒控件的支付凭证；所述第二帐户是车辆司机的资金帐户，所述第一应用界面是母应用程序的应用界面；

界面展示模块1720，用于在接收到对所述开票提醒控件的触发操作时，展示第二应用界面，所述第二应用界面是子应用程序的应用界面，所述子应用程序依赖所述母应用程序运行；

提醒展示模块1730，用于在接收到对所述第二应用界面中的开票申请控件的触发操作后，展示行程***提醒，所述行程***提醒用于提醒服务器已开具所述支付凭证对应的目标行程的行程***。

图18是根据一示例性实施例示出的一种计算机设备的结构示意图。所述计算机设备1800包括中央处理单元(CPU)1801、包括随机存取存储器(RAM)1802和只读存储器(ROM)1803的***存储器1804，以及连接***存储器1804和中央处理单元1801的***总线1805。所述计算机设备1800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出***(I/O***)1806，和用于存储操作***1813、应用程序1814和其他程序模块1815的大容量存储设备1807。

所述基本输入/输出***1806包括有用于显示信息的显示器1808和用于用户输入信息的诸如鼠标、键盘之类的输入设备1809。其中所述显示器1808和输入设备1809都通过连接到***总线1805的输入输出控制器1810连接到中央处理单元1801。所述基本输入/输出***1806还可以包括输入输出控制器1810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1810还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备1807通过连接到***总线1805的大容量存储控制器(未示出)连接到中央处理单元1801。所述大容量存储设备1807及其相关联的计算机可读介质为计算机设备1800提供非易失性存储。也就是说，所述大容量存储设备1807可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的***存储器1804和大容量存储设备1807可以统称为存储器。

计算机设备1800可以通过连接在所述***总线1805上的网络接口单元1811连接到互联网或者其它网络设备。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，中央处理器1801通过执行该一个或一个以上程序来实现图3或图4所示的方法中，由服务器执行的全部或者部分步骤。

图19示出了本申请一个示例性实施例提供的用户终端1900的结构框图。该终端1900可以是：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1900还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1900包括有：处理器1901和存储器1902。

处理器1901可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1901可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1901也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1901可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1901还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1902可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1902还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1902中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1901所执行以实现上述图3或图4所示的方法实施例中，由终端执行的全部或者部分步骤。

在一些实施例中，终端1900还可选包括有：***设备接口1903和至少一个***设备。处理器1901、存储器1902和***设备接口1903之间可以通过总线或信号线相连。各个***设备可以通过总线、信号线或电路板与***设备接口1903相连。具体地，***设备包括：射频电路1904、触摸显示屏1905、摄像头1906、音频电路1907、定位组件1908和电源1909中的至少一种。

***设备接口1903可被用于将I/O(Input/Output，输入/输出)相关的至少一个***设备连接到处理器1901和存储器1902。在一些实施例中，处理器1901、存储器1902和***设备接口1903被集成在同一芯片或电路板上；在一些其他实施例中，处理器1901、存储器1902和***设备接口1903中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1904用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1904通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1904将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1904包括：天线***、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1904可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1904还可以包括NFC(Near FieldCommunication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1905用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1905是触摸显示屏时，显示屏1905还具有采集在显示屏1905的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1901进行处理。此时，显示屏1905还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1905可以为一个，设置终端1900的前面板；在另一些实施例中，显示屏1905可以为至少两个，分别设置在终端1900的不同表面或呈折叠设计；在再一些实施例中，显示屏1905可以是柔性显示屏，设置在终端1900的弯曲表面上或折叠面上。甚至，显示屏1905还可以设置成非矩形的不规则图形，也即异形屏。显示屏1905可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件1906用于采集图像或视频。可选地，摄像头组件1906包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1906还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1907可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1901进行处理，或者输入至射频电路1904以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端1900的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1901或射频电路1904的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1907还可以包括耳机插孔。

定位组件1908用于定位终端1900的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件1908可以是基于美国的GPS(GlobalPositioning System，全球定位***)、中国的北斗***或俄罗斯的伽利略***的定位组件。

电源1909用于为终端1900中的各个组件进行供电。电源1909可以是交流电、直流电、一次性电池或可充电电池。当电源1909包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端1900还包括有一个或多个传感器1910。该一个或多个传感器1910包括但不限于：加速度传感器1911、陀螺仪传感器1912、压力传感器1913、指纹传感器1914、光学传感器1915以及接近传感器1916。

加速度传感器1911可以检测以终端1900建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1911可以用于检测重力加速度在三个坐标轴上的分量。处理器1901可以根据加速度传感器1911采集的重力加速度信号，控制触摸显示屏1905以横向视图或纵向视图进行用户界面的显示。加速度传感器1911还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1912可以检测终端1900的机体方向及转动角度，陀螺仪传感器1912可以与加速度传感器1911协同采集用户对终端1900的3D动作。处理器1901根据陀螺仪传感器1912采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1913可以设置在终端1900的侧边框和/或触摸显示屏1905的下层。当压力传感器1913设置在终端1900的侧边框时，可以检测用户对终端1900的握持信号，由处理器1901根据压力传感器1913采集的握持信号进行左右手识别或快捷操作。当压力传感器1913设置在触摸显示屏1905的下层时，由处理器1901根据用户对触摸显示屏1905的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1914用于采集用户的指纹，由处理器1901根据指纹传感器1914采集到的指纹识别用户的身份，或者，由指纹传感器1914根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1901授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1914可以被设置终端1900的正面、背面或侧面。当终端1900上设置有物理按键或厂商Logo时，指纹传感器1914可以与物理按键或厂商Logo集成在一起。

光学传感器1915用于采集环境光强度。在一个实施例中，处理器1901可以根据光学传感器1915采集的环境光强度，控制触摸显示屏1905的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏1905的显示亮度；当环境光强度较低时，调低触摸显示屏1905的显示亮度。在另一个实施例中，处理器1901还可以根据光学传感器1915采集的环境光强度，动态调整摄像头组件1906的拍摄参数。

接近传感器1916，也称距离传感器，通常设置在终端1900的前面板。接近传感器1916用于采集用户与终端1900的正面之间的距离。在一个实施例中，当接近传感器1916检测到用户与终端1900的正面之间的距离逐渐变小时，由处理器1901控制触摸显示屏1905从亮屏状态切换为息屏状态；当接近传感器1916检测到用户与终端1900的正面之间的距离逐渐变大时，由处理器1901控制触摸显示屏1905从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图19中示出的结构并不构成对终端1900的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括计算机程序(指令)的存储器，上述程序(指令)可由计算机设备的处理器执行以完成本申请各个实施例所示的方法的全部或者部分步骤。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims

1.一种行程***的开具方法，其特征在于，所述方法由服务器执行，所述方法包括：

开具所述目标行程对应的行程***。

2.根据权利要求1所述的方法，其特征在于，在所述接收用户终端发送的开票请求之前，所述方法还包括：

向所述用户终端发送所述支付凭证，所述支付凭证中包含开票提醒控件，所述开票提醒控件用于在触发时生成所述开票请求。

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

获取所述车辆标识对应的签到状态标识；

当所述签到状态标识指示所述车辆司机在岗时，向所述用户终端发送所述支付凭证。

4.根据权利要求1所述的方法，其特征在于，所述根据所述车辆标识和所述支付时刻获取目标行程，包括：

5.根据权利要求1所述的方法，其特征在于，所述开具所述目标行程对应的行程***，包括：

6.根据权利要求1所述的方法，其特征在于，所述开具所述目标行程对应的行程***，包括：

向区块链服务器发送区块链开票请求；

7.一种行程***的开具方法，其特征在于，所述方法由用户终端执行，所述方法包括：

8.根据权利要求7所述的方法，其特征在于，所述在通过第一帐户向第二帐户支付成功后，展示支付凭证，包括：

9.根据权利要求8所述的方法，其特征在于，所述展示包含开票提醒控件的所述支付凭证，包括：

所述接收到对所述支付凭证的触发操作时，生成开票请求，包括：

10.一种行程***的开具方法，其特征在于，所述方法由用户终端执行，所述方法包括：

11.一种行程***的开具装置，其特征在于，所述装置包括：

***开具模块，用于开具所述目标行程对应的行程***。

12.一种行程***的开具装置，其特征在于，所述装置包括：

13.一种行程***的开具装置，其特征在于，所述装置包括：

14.一种计算机设备，其特征在于，所述计算机设备包含处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至10任一所述的方法。

15.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至10任一所述的方法。