网约车结算及报销的方法、系统及存储介质
本申请以2017年11月23日提交的申请号为201711177717.3,名称为“网约车结算及报销的方法、系统及存储介质”的中国发明专利申请为基础,并要求其优先权。
技术领域
本申请属于通信技术领域,尤其涉及一种网约车结算及报销的方法、系统及存储介质。
背景技术
对于出差用车,乘客可以通过现金或者非现金的方式进行结算,如果需要向公司或单位报销,则需要在到达目的地后要求司机线下开具纸质发票,然后在规定的时间之前交到财务部门进行审批,审批通过才可以领取报销款,过程繁琐,限制条件多,不熟悉流程的企业员工甚至无法顺利完成申报;由于结算的方式和报销的方式是相互独立的,报销过程自动化程度低,效率低;甚至可能存在恶意报销的情况,而公司或单位对此的风险管理欠佳。
发明内容
本申请实施例提供了一种网约车结算及报销的方法、系统及存储介质,以解决现有企业内部的用车报销过程繁琐、自动化程度低、效率低的问题,提高企业对用车报销的风险管理。
本申请实施例提供了一种网约车结算及报销的方法,所述方法包括:
获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫;
当完成网络约车时,生成待交易订单;
从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单;
当获取到前台终端发送的交易订单的报销请求时,生成审批请求;
基于该审批请求完成对所述交易订单的签报审批流程,并根据所述签报审批流程的结果生成报销执行指令;若所述报销执行指令为执行报销支付,从企业交易账号中划出该交易订单对应的消费金额存入所述用户交易账号。
进一步地,所述方法还包括:
将所述交易订单与用户帐号关联存储。
进一步地,所述当获取到前台终端发送的交易订单的报销请求时,生成审批请求包括:
当获取到前台终端发送的包含用户帐号及日期信息的查看请求时,查询与所述用户帐号关联的交易订单,然后从所述关联的交易订单中筛选出该日期信息之前的交易订单作为可报销订单;
向所述前台终端返回所述可报销订单,以使得前台终端展示所述可报销订单;
当获取到前台终端发送的报销请求时,通过报销接口获取所述报销请求对应的可报销订单,并发起所述可报销订单的签报审批流程。
进一步地,所述获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫包括:
获取前台终端发送的乘车起点位置和终点位置,调用GPS定位接口计算所述乘车起点位置和终点位置之间的行程距离;
调用至少一个网约车平台提供的呼叫接口,将所述乘车起点位置、终点位置以及行程距离发送至所述网约车平台,以请求预估价格;
接收所述网约车平台返回的预估价格,通过所述前台终端展示所述预估价格供用户选择使用的网约车平台;
通过所述前台终端获取用户选择的网约车平台,生成呼叫指令,并将所述呼叫指令发送至所述网约车平台提供的呼叫接口进行车辆呼叫。
进一步地,在获取前台终端发送的乘车起点位置、终点位置之前,所述方法还包括:
当获取到前台终端发送的用车指令时,调用GPS定位接口获取前台终端当前的位置信息;
向所述前台终端返回所述位置信息对应的地图数据以及网约车链接,以使得所述前台终端根据所述网约车链接加载包括地图数据的呼叫界面。
本申请实施例还提供了一种网约车结算及报销的系统,所述系统包括:
后台服务器,用于获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫;
所述网约车平台,用于当完成网络约车时,生成待交易订单;
所述支付服务器,用于从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单;
所述后台服务器还用于,当获取到前台终端发送的交易订单的报销请求时,生成审批请求;
所述签报服务器,用于基于该审批请求完成对所述交易订单的签报审批流程,并根据所述签报审批流程的结果生成报销执行指令;
所述支付服务器还用于,若所述报销执行指令为执行报销支付,从企业交易账号中划出该交易订单对应的消费金额存入所述用户交易账号。
进一步地,所述后台服务器还用于:
将所述交易订单与用户帐号关联存储。
进一步地,所述后台服务器还用于:
当获取到前台终端发送的包含用户帐号及日期信息的查看请求时,查询与所述用户帐号关联的交易订单,然后从所述关联的交易订单中筛选出该日期信息之前的交易订单作为可报销订单;
向所述前台终端返回所述可报销订单,以使得前台终端展示所述可报销订单;
当获取到前台终端发送的报销请求时,通过报销接口获取所述报销请求对应的可报销订单,并发起所述可报销订单的签报审批流程。
进一步地,所述后台服务器还用于:
获取前台终端发送的乘车起点位置和终点位置,调用GPS定位接口计算所述乘车起点位置和终点位置之间的行程距离;
调用至少一个网约车平台提供的呼叫接口,将所述乘车起点位置、终点位置以及行程距离发送至所述网约车平台,以请求预估价格;
接收所述网约车平台返回的预估价格,通过所述前台终端展示所述预估价格供用户选择使用的网约车平台;
通过所述前台终端获取用户选择的网约车平台,生成呼叫指令,并将所述呼叫指令发送至所述网约车平台提供的呼叫接口进行车辆呼叫。
本申请实施例还提供了一个或多个存储有计算机可读指令的非易失性可读存储介质,所述计算机可读指令被一个或多个处理器执行时,使得所述一个或多个处理器执行如下步骤:
获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫;
当完成网络约车时,生成待交易订单;
从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单;
当获取到前台终端发送的交易订单的报销请求时,生成审批请求;
基于该审批请求完成对所述交易订单的签报审批流程,并根据所述签报审批流程的结果生成报销执行指令;
若所述报销执行指令为执行报销支付,从企业交易账号中划出该交易订单对应的消费金额存入所述用户交易账号。
本申请的一个或多个实施例的细节在下面的附图及描述中提出。本申请的其他特征和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他附图。
图1是本申请实施例提供的网约车结算及报销的方法的第一实现流程图;
图2是本申请实施例提供的网约车结算及报销的方法的第二实现流程图;
图3是本申请实施例提供的网约车结算及报销的方法的第三实现流程图;
图4是本申请实施例提供的网约车结算及报销的方法的第四实现流程图;
图5是本申请实施例提供的网约车结算及报销的系统的组成结构图;
图6是本申请实施例提供的终端的示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
在现有的用车报销方式中,支付方式和报销流程并没有通过互联网关联起来,是两个独立的步骤,这种制约下企业员工只能通过线下的方式收集发票,无法进行线上报销,报销的过程繁琐、自动化程度低,进而降低了报销的效率;且存在恶意收集用车发票、胡乱报销的风险。为了解决上述技术问题,本申请实施例构建了用于网络约车及报销的指定APP,通过所述指定APP将用车后的支付方式和报销流程关联起来,实现线上结算及报销,保证了每一个申请报销的交易订单都有依有据。在这里,所述指定APP涉及到服务器与前台终端,所述服务器与所述前台终端连接通信,所述前台终端用于与用户进行交互,所述服务器用于 关联存储用户的每一笔交易订单。进一步地,所述服务器还用于完成网络约车的操作、执行网络约车用车后的支付操作以及执行报销金额的转入操作,从而实现网络约车的在线结算和在线报销,有效地解决了现有企业内部的用车报销过程繁琐、自动化程度低、效率低的问题。
实施例1
图1示出了本申请实施例提供的网约车结算及报销的方法的第一实现流程。
在本申请实施例中,所述网约车结算及报销的方法应用于由服务器、前台终端组成的系统,所述前台终端用于安装及运行该用于网络约车及报销的指定APP,所述服务器用于存储用户登录所述指定APP的用户帐号信息、交易订单、响应消息以及推送通知。可选地,所述前台终端包括但不限于智能手机、平板电脑、学习机等。参阅图1,所述网约车结算及报销的方法包括:
在步骤S101中,获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫。
在这里,所述前台终端上安装有用于网络约车及报销的指定APP,前台终端通过所述指定APP与用户交互,获取用户输入的操作信息,比如登录操作、触发操作、预订操作等,将这些操作信息发送至服务器拉取相应的数据进行展示或者完成指定的功能。在进行网络约车时,所述前台终端通过所述指定APP获取用户输入的乘车起点位置、终点位置,将所述乘车起点位置、终点位置发送至服务器,由服务器生成呼叫指令,并发起车辆呼叫进行派车操作。
在步骤S102中,当完成网络约车时,生成待交易订单。
在本申请实施例中,完成网络约车是指网约车司机将叫车人送达目的地。本申请实施例由服务器来统一完成对待交易订单的结算,以将结算过程和报销过程连接起来。在完成网络约车后,生成本次网络约车的待交易订单,并将所述待交易订单分别发送至前台终端。前台终端根据所述待交易订单展示结算界面,以提示用户在所述结算界面上选择结算方式,输入交易密码。服务器则根据所述待交易订单以及交易密码完成支付操作。
可选地,所述待交易订单中包括但不限于帐号信息、车辆信息、网约车司机信息、交易信息。所述帐号信息应当理解为用户登录所述指定APP的用户帐号及密码。
在步骤S103中,从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单。
在这里,所述服务器上维护着用户的帐号信息与用户的交易账号。所述交易账号为用户 在所述服务器上备案的银行卡账号,或者交易账号为用户在服务器上备案的微信钱包账号或支付宝账号等其他任意第三方支付平台对应的账号。服务器生成所述待交易订单的交易链接,将所述交易链接发送至前台终端,以提示用户输入交易密码完成支付校验。若接收到交易密码时,所述服务器校验所述交易密码是否正确,并在正确的情况下从所述待交易订单对应的用户交易账号中扣除本次待交易订单对应的消费金额,以完成支付操作。在支付完成后,所述服务器在待交易订单上添加已结算金额、结算方式,生成对应的交易订单。在这里,与待交易订单相似,所述交易订单还包括帐号信息、车辆信息、网约车司机信息、交易信息。所述车辆信息包括但不限于车辆品牌、车辆级别、车辆类型;所述网约车司机信息包括但不限于驾照号码、姓名、联系电话;所述交易信息包括但不限于叫车日期及时刻、当前时刻、订单号、实际行程。
在步骤S104中,当获取到前台终端发送的交易订单的报销请求时,生成审批请求。
本申请实施例由服务器保存交易订单,使得前台终端可以直接访问服务器获取交易订单的数据信息,方便了用户查看已完成的交易订单以及在所述指定APP上发起报销申报,也避免了将交易订单存储在前台终端带来的风险。
当获取到前台终端发送的交易订单的报销请求时,所述服务器生成审批请求,以请求完成对所述交易订单的签报审批流程。
在这里,前台终端从服务器获取到交易订单后,可以通过列表的方式展示该交易订单,以便于用户浏览和选取需要发起报销的交易订单。当检测到用户在所述列表上输入的预设手势操作时,根据所述预设手势操作获取用户选取的交易订单及生成报销请求。
在步骤S105中,基于该审批请求完成对所述交易订单的签报审批流程,并根据所述签报审批流程的结果生成报销执行指令。
服务器根据所述报销请求,生成审批请求,并将工作流流转至相应的企业领导完成对所述交易订单的报销审批操作。所述审批请求中包括用户发起报销的交易订单,从而无需用户线下提交发票等材料,实现了在线的报销申报和审批操作。
在这里,所述签报审批流程的审批结果包括两种,分别为企业领导认可所述交易订单并核定报销,和不认可所述交易订单并拒绝报销,不认可的情况包括所述交易订单不符合报销规则,比如交易叫车时间和日期不在可报销时间范围内、用户帐号有误等。因此,当企业领导认可所述交易订单并核定报销时,签报审批流程所生成的报销执行指令为执行报销支付;当企业领导不认可所述交易订单并拒绝报销时,签报审批流程所生成的报销执行指令为拒绝报销支付。
在步骤S106中,若所述报销执行指令为执行报销支付,从企业交易账号中划出该交易 订单对应的消费金额存入所述用户交易账号。
本申请实施例通过所述服务器,完成企业内部领导对交易订单的审批和确认操作。在企业领导审批完成后,所述服务器生成所述交易订单的报销执行指令,以指示完成对所述交易订单的报销操作。
本申请实施例中,企业和用户需均在所述服务器上备案相应的交易账号。服务器生成报销执行指令后,根据所述报销执行指令获取企业交易账号以及用户交易账号,获取该交易订单的消费金额,然后从所述企业交易账号中划出不低于所述消费金额的报销金额,将所述报销金额打入所述用户交易账号中。用户交易账号会在指定时间范围内收到报销金额。
本申请实施例通过联合用户及企业在所述服务器上备案交易账号,并通过所述服务器实现网络约车的结算操作,以及实现对网络约车的报销申报操作,从企业备案的交易账号直接向用户的交易账号打入报销金额,将出差用车记录以及费用报销有机地关联起来,无需用户线下收集发票,通过在前台终端上简单操作即可完成消费及报销,也无需企业领导线下核实发票信息,通过在线查看及确认即可完成在线的审批操作,有效地解决了现有企业内部的报销过程繁琐、自动化程度低、效率低的问题;且有效地规避了恶意报销的风险。
作为本申请的一个优选示例,所述服务器的执行主体可以有多个。图2示出了本申请实施例提供的网约车结算及报销的方法的第二实现流程。
在本申请实施例中,所述网约车结算及报销的方法应用于由服务器、前台终端组成的系统,其中,所述服务器包括后台服务器、与所述后台服务器通信的一个或多个网约车平台、支付服务器、企业内部的签报服务器。可选地,所述支付服务器为第三方支付平台服务器,所述第三方支付平台包括但不限于支付宝平台、财付通平台、银联支付平台、壹钱包平台、百度钱包平台。所述网约车平台为第三方网约车平台服务器,包括但不限于滴滴出行、优步、嘀嗒拼车、神州专车等。所述签报服务器为企业内部的审批系统服务器。所述前台终端、后台服务器、支付服务器以及签报服务器按照指定的计算机可读指令运作,共同实现了网约车的在线叫车及报销过程,有效地解决了现有企业内部的用车报销过程繁琐、自动化程度低、效率低的问题。
参阅图2,所述网约车结算及报销方法包括:
在步骤S201中,后台服务器获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,将所述起点位置、终点位置以及呼叫指令发送至至少一个网约车平台提供的呼叫接口进行车辆呼叫。
在步骤S202中,当检测到网约车司机接单且完成网络约车时,所述网约车平台生成待 交易订单,将所述待交易订单发送至支付服务器。
在步骤S203中,所述支付服务器从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单,将所述交易订单发送至后台服务器。
应当理解,在这里,由支付平台维护着用户的帐号信息与用户的交易账号。支付平台上的服务器,即支付服务器,根据从网约车平台接收到待交易订单后,生成所述待交易订单的交易链接,将所述交易链接发送至前台终端,以提示用户输入交易密码完成支付校验。若接收到交易密码时,所述支付服务器校验所述交易密码是否正确,并在正确的情况下从所述待交易订单对应的用户交易账号中扣除本次待交易订单对应的消费金额,以完成支付操作,生成交易订单。
可选地,所述后台服务器与支付服务器、网约车平台之间的通信方式可以采用标准http协议中的post请求方法。
在步骤S204中,所述后台服务器接收并存储所述交易订单。
在步骤S205中,当获取到前台终端发送的交易订单的报销请求时,所述后台服务器向签报服务器发送审批请求,以请求签报服务器完成对所述交易订单的签报审批流程。
在步骤S206中,在签报审批完成后,所述签报服务器向支付服务器发送报销执行指令。
在步骤S207中,所述支付服务器根据所述报销执行指令,从企业交易账号中划出该交易订单对应的消费金额存入所述用户交易账号。
应当理解,本申请实施例中,企业和用户相应的交易账号均在所述支付平台上备案。支付平台上的服务器,即支付服务器,接收到生成报销执行指令后,则根据所述报销执行指令获取企业交易账号以及用户交易账号,获取该交易订单的消费金额,然后从所述企业交易账号中划出不低于所述消费金额的报销金额,将所述报销金额打入所述用户交易账号中。用户交易账号会在指定时间范围内收到报销金额。
上述服务器的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
进一步地,基于图1提供的网约车结算及报销的方法的第一实现流程的基础上,提出本申请实施例提供的网约车结算及报销的方法的第三实现流程。
如图3所示,是本申请实施例提供的网约车结算及报销的方法的第三实现流程示意图。在本申请实施例中,在获取前台终端发送的乘车起点位置、终点位置之前,所述方法还包括:
在步骤S1001中,当获取到前台终端发送的用车指令时,调用GPS定位接口获取前台终端当前的位置信息;
在步骤S1002中,向所述前台终端返回所述位置信息对应的地图数据以及网约车链接, 以使得所述前台终端根据所述网约车链接加载包括地图数据的呼叫界面。
在这里,本申请实施例通过向前台终端返回包括地图数据的呼叫界面,方便了用户确认GPS定位是否正确,避免了数据丢失导致的定位出错。所述呼叫界面上包括起点位置以及终点位置输入框,用户可以在所述输入框中添加乘车起点以及终点。
相应地,在图1实施例中所述步骤S101还可以包括:
在步骤S1011中,获取前台终端发送的乘车起点位置和终点位置,调用GPS定位接口计算所述乘车起点位置和终点位置之间的行程距离。
在这里,所述前台终端通过所述呼叫界面获取用户输入的乘车起点位置和终点位置,然后发送至服务器。服务器获取到起点位置和终点位置后,调用GPS定位接口,优选为百度GPS定位接口,通过所述GPS定位接口结合地图数据获取该起点位置和终点位置之间的路线,并根据所述路线计算所述起点位置和终点位置之间的行程距离。
在步骤S1012中,调用至少一个网约车平台提供的呼叫接口,将所述乘车起点位置、终点位置以及行程距离发送至所述网约车平台,以请求预估价格。
服务器采用标准http协议中的post请求方法,将所述起点位置、终点位置以及行程距离发送至所述网约车平台,以请求每个网约车平台对本次行程的预估价格。网约车平台在接收到所述起点位置、终点位置以及行程距离之后,根据打车时段、起步价等信息预测打车费用,并将所预测的打车费用返回至所述服务器。
在步骤S1013中,接收所述网约车平台返回的预估价格,通过所述前台终端展示所述预估价格供用户选择使用的网约车平台。
在这里,网约车平台接收到预估价格之后,将所述预估价格发送至前台终端,以使得前台终端在所述呼叫界面上展示不同网约车平台及其对应的预估价格,以供用户选择执行车辆呼叫的网约车平台。
在步骤S1014中,通过所述前台终端获取用户选择的网约车平台,生成呼叫指令,并将所述呼叫指令发送至所述网约车平台提供的呼叫接口进行车辆呼叫。
在本申请实施例中,所述前台终端实时检测用户在所述呼叫界面上的手势操作,然后根据所述手势操作获取用户选择的网约车平台,将用户的选择发送至服务器,由服务器据此生成呼叫指令,向用户选择的网约车平台发起车辆呼叫。
上述步骤S1011至步骤S1014为通过该指定APP向网约车平台发起车辆呼叫的逻辑,实现了在非网约车平台对应的APP上进行网络约车,使得企业可以在内部非公开APP上进行网络约车,以便于实现在内部非公开APP上的报销逻辑。
进一步地,基于图1提供的网约车结算及报销的方法的第一实现流程的基础上,提出本申请实施例提供的网约车结算及报销的方法的第四实现流程。
如图4所示,是本申请实施例提供的网约车结算及报销的方法的第四实现流程示意图。在本申请实施例中,在所述步骤S104之前,所述方法还包括:
在步骤S1041中,将所述交易订单与用户帐号关联存储。
如前所述,所述用户帐号为用户在所述指定APP上注册的登录帐号,一个用户对应唯一的一个用户帐号。在本申请实施例中,所述服务器为每一个用户帐号维护着对应的交易订单列表。在接收到交易订单后,所述服务器获取完成所述交易订单的支付操作的用户交易账号,查询所述用户交易账号对应的用户帐号,将所述交易订单添加至所述用户帐号对应的交易订单列表中,完成所述交易订单与用户帐号之间的关联存储,以便于对交易订单进行有效管理和快速查找,规避虚假报销行为。
所述步骤S104所述当获取到前台终端发送的交易订单的报销请求时,生成审批请求包括:
在步骤S1042中,当获取到前台终端发送的包含用户帐号及日期信息的查看请求时,查询与所述用户帐号关联的交易订单,然后从所述关联的交易订单中筛选出该日期信息之前的交易订单作为可报销订单。
在步骤S1043中,向所述前台终端返回所述可报销订单,以使得前台终端展示所述可报销订单。
在本申请实施例中,所述指定APP上提供了可报销订单查看功能标识,用户可以通过触发所述查看功能标识来获取可报销订单。前端设备实时地监测用户的手势操作,根据用户帐号以及日期信息生成查看请求,将所述查看请求发送至服务器。服务器接收到所述查看请求后,解析所述请求,得到用户帐号和日期信息,从所述用户帐号关联的交易订单中筛选出在所述日期信息之前的交易订单作为可报销订单,以筛选出与该用户行为轨迹相关的交易订单作为可报销订单,并将所述可报销订单返回至前台终端。前台终端可以采用列表的方式将所述可报销订单展示给用户,以引导用户完成线上报销申报。在这里,所述用户帐号和日期信息指定了可报销订单的查询条件,使得不同用户不同时间触发所述查看功能标识时,所述指定APP上展示最新且与用户轨迹相关的可报销订单,有利于规避恶意用车引起的恶意报销的行为,提高了企业的风险监控。
进一步地,本申请实施例将交易订单存储在服务器中,用户只需在前台终端通过手势操作选择可报销订单即可发起报销申报,无需输入发票的相关信息,极大地简化了用户的操作。
在步骤S1044中,当获取到前台终端发送的报销请求时,通过报销接口获取所述报销请 求对应的可报销订单,并发起所述可报销订单的签报审批流程。
在检测到预设的手势操作时,前台终端生成报销请求,并调用服务器提供的报销接口,将所述报销请求通过所述报销接口发送至服务器,以发起对可报销订单的报销申报。服务器接收所述报销请求,得到可报销订单,然后发起签报审批流程,从而实现了在线的报销申报操作,使得用户只需要在前台终端的指定APP上挥动手指即可发起报销申报,无需再进行发票开具、收集、提交等步骤,有效地简化了用户的操作,提升了用户的体验感。
应理解,在上述实施例中,各步骤的序号的大小并不意味着执行顺序的先后,各步骤的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
实施例2
图5示出了本申请实施例提供的网约车结算及报销的系统的组成结构图,为了便于说明,仅示出了与本申请实施例相关的部分。
在本申请实施例中,所述网约车结算及报销的系统用于实现上述图1、图2、图3、图4实施例中所述的网约车结算及报销的方法,包括后台服务器51、至少一个网约车平台52、支付服务器53、签报服务器54以及至少一个前台终端55。其中,所述后台服务器51、网约车平台52、支付服务器53以及签报服务器54实现的功能与图1至图4实施例中所述的网约车结算及报销的方法对应的步骤一一对应。
参阅图5,所述网约车结算及报销的系统包括:
后台服务器51,用于获取前台终端发送的乘车起点位置、终点位置,生成呼叫指令,根据所述起点位置、终点位置以及呼叫指令进行车辆呼叫;
所述网约车平台52,用于当完成网络约车时,生成待交易订单;
所述支付服务器53,用于从用户交易账号中划出所述待交易订单对应的消费金额用以完成支付,并在支付完后生成对应的交易订单;
所述后台服务器51,还用于当获取到前台终端发送的交易订单的报销请求时,生成审批请求;
所述签报服务器54,用于基于该审批请求完成对所述交易订单的签报审批流程,并根据所述签报审批流程的结果生成报销执行指令;
所述支付服务器53,还用于若所述报销执行指令为执行报销支付,从企业交易账号中划出该交易订单对应的消费金额存入所述用户交易账号。
可选地,所述后台服务器51还用于:
将所述交易订单与用户帐号关联存储。
可选地,所述后台服务器51还用于:
当获取到前台终端发送的包含用户帐号及日期信息的查看请求时,查询与所述用户帐号关联的交易订单,然后从所述关联的交易订单中筛选出该日期信息之前的交易订单作为可报销订单;
向所述前台终端返回所述可报销订单,以使得前台终端展示所述可报销订单;
当获取到前台终端发送的报销请求时,通过报销接口获取所述报销请求对应的可报销订单,并发起所述可报销订单的签报审批流程。
可选地,所述后台服务器51还用于:
获取前台终端发送的乘车起点位置和终点位置,调用GPS定位接口计算所述乘车起点位置和终点位置之间的行程距离;
调用至少一个网约车平台提供的呼叫接口,将所述乘车起点位置、终点位置以及行程距离发送至所述网约车平台,以请求预估价格;
接收所述网约车平台返回的预估价格,通过所述前台终端展示所述预估价格供用户选择使用的网约车平台;
通过所述前台终端获取用户选择的网约车平台,生成呼叫指令,并将所述呼叫指令发送至所述网约车平台提供的呼叫接口进行车辆呼叫。
可选地,在获取前台终端发送的乘车起点位置、终点位置之前,所述后台服务器51还用于:
当获取到前台终端发送的用车指令时,调用GPS定位接口获取前台终端当前的位置信息;
向所述前台终端返回所述位置信息对应的地图数据以及网约车链接,以使得所述前台终端根据所述网约车链接加载包括地图数据的呼叫界面。
在本申请实施例中,所述后台服务器与网约车平台、支付服务器之间采用标准http协议中的post请求方法进行交互。
需要说明的是,本申请实施例中的后台服务器、网约车平台、支付服务器、签报服务器可以用于实现上述方法实施例中的对应技术方案。上述后台服务器、网约车平台、支付服务器以及签报服务器的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
实施例3
本实施例提供一个或多个存储有计算机可读指令的非易失性可读存储介质。该一个或多个存储有计算机可读指令的非易失性可读存储介质,计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行实施例1中网约车结算及报销的方法,为避免重复,这里不再赘述。或者,该计算机可读指令被处理器执行时实现实施例2中网约车结算及报销的系统中后台服务器、网约车平台、支付服务器以及签报服务器的功能,为避免重复,这里不再赘述。所述非易失性可读存储介质可以集成在可被各服务器共享的网络终端上,实施例2中各服务器可根据自身功能,基于RPC(Remote Procedure Call Protocol)远程过程调用协议,从所述非易失性可读存储介质中调用对应的计算机可读指令段或模块。可选地,所述存储介质可以是只读存储器,磁盘或光盘等。
可以理解地,一个或多个存储有计算机可读指令的非易失性可读存储介质可以包括:能够携带所述计算机可读指令的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、电载波信号和电信信号等。
实施例4
图6是本申请实施例提供的一种终端的示意图。如图6所示,该实施例的终端6包括上述图5实施例的后台服务器51、网约车平台52、支付服务器53、签报服务器54中的一种。比如终端6为后台服务器,其包括:处理器60、存储器61以及存储在所述存储器61中并可在所述处理器60上运行的计算机可读指令62。所述处理器60执行所述计算机可读指令62时实现上述网约车结算及报销的方法实施例中的对应步骤,即图2所示的步骤S201、S204、S205。为避免重复,此处不一一赘述。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述终端的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。
以上所述实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围,均应包含在本申请的保护范围之内。