CN115860848A - 电子乘车发票处理方法及装置 - Google Patents

电子乘车发票处理方法及装置 Download PDF

Info

Publication number
CN115860848A
CN115860848A CN202211581027.5A CN202211581027A CN115860848A CN 115860848 A CN115860848 A CN 115860848A CN 202211581027 A CN202211581027 A CN 202211581027A CN 115860848 A CN115860848 A CN 115860848A
Authority
CN
China
Prior art keywords
payment
order
travel
information
riding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211581027.5A
Other languages
English (en)
Inventor
吴昆�
王沈桢
郑成俊
张雪
瞿晓高
邢健
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Priority to CN202211581027.5A priority Critical patent/CN115860848A/zh
Publication of CN115860848A publication Critical patent/CN115860848A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/045Payment circuits using payment protocols involving tickets
    • G06Q20/0457Payment circuits using payment protocols involving tickets the tickets being sent electronically
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0633Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635Processing of requisition or of purchase orders

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本说明书实施例提供了电子乘车发票处理方法及装置,其中,一种电子乘车发票处理方法包括:获取根据传输组件上传的乘车行程信息生成的行程订单;在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;建立所述行程订单与所述目标支付订单的关联关系;基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。

Description

电子乘车发票处理方法及装置
本申请是申请日为2020年11月02日、申请号为CN202011202843.1、名称为“电子乘车发票处理方法及装置”的中国发明专利申请的分案申请。
技术领域
本文件涉及数据处理技术领域,尤其涉及一种电子乘车发票处理方法及装置。
背景技术
出租车是一种具有方便、舒适、灵活、全天候,以及“门到门”等特点的运输服务方式,在一定程度上可与私家车相媲美,目前已成为重点满足个性化与支付能力较强的出行需求的出行方式,一直以来,出租车都能够给用户的出行提供便利,但是,出租车在给用户带来方便和舒适的同时,还有很多问题没有得到有效解决,制约着出租车行业的发展。
发明内容
本说明书一个或多个实施例提供了一种电子乘车发票处理方法。所述电子乘车发票处理方法包括:获取根据传输组件上传的乘车行程信息生成的行程订单。在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单。建立所述行程订单与所述目标支付订单的关联关系。基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
本说明书一个或多个实施例提供了一种电子乘车发票处理装置,包括:获取模块,被配置为获取根据传输组件上传的乘车行程信息生成的行程订单。查询模块,被配置为在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单。关联模块,被配置为建立所述行程订单与所述目标支付订单的关联关系。确定模块,被配置为基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
本说明书一个或多个实施例提供了一种电子乘车发票处理设备,包括:处理器;以及,被配置为存储计算机可执行指令的存储器,所述计算机可执行指令在被执行时使所述处理器:获取根据传输组件上传的乘车行程信息生成的行程订单。在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单。建立所述行程订单与所述目标支付订单的关联关系。基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
本说明书一个或多个实施例提供了一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被执行时实现以下流程:获取根据传输组件上传的乘车行程信息生成的行程订单。在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单。建立所述行程订单与所述目标支付订单的关联关系。基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
附图说明
为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本说明书一个或多个实施例提供的一种电子乘车发票处理方法处理流程图;
图2为本说明书一个或多个实施例提供的一种应用于出租车场景的电子乘车发票处理方法处理流程图;
图3为本说明书一个或多个实施例提供的一种电子乘车发票处理装置示意图;
图4为本说明书一个或多个实施例提供的一种电子乘车发票处理设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案,下面将结合本说明书一个或多个实施例中的附图,对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书的一部分实施例,而不是全部的实施例。基于本说明书一个或多个实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本文件的保护范围。
本说明书提供的一种电子乘车发票处理方法实施例:
参照图1,其示出了本实施例提供的一种电子乘车发票处理方法处理流程图,参照图2,其示出了本实施例提供的一种应用于出租车场景的电子乘车发票处理方法处理流程图。
参照图1,本实施例提供的电子乘车发票处理方法具体包括下述步骤S102至步骤S108。
步骤S102,获取根据传输组件上传的乘车行程信息生成的行程订单。
实际应用中,每一笔出租车乘车行程结束之后,都会默认打印出一张纸质发票,在一定程度上,纸质发票成本较高,容易造成污染浪费,且纸质发票保存不易,容易污损遗失,遗失后无法再次开具,给乘客带来不便。
本实施例提供的电子乘车发票处理方法,首先获取根据传输组件上传的乘车行程信息生成的行程订单,在行程订单被标记为已支付状态的情况下,生成该行程订单对应的乘车行程的电子乘车发票,然后在支付平台生成的多个支付订单中查询与电子乘车发票对应的支付订单,并且在查询到的支付订单的数目仅有一个的情况下,将该查询到的支付订单与电子乘车发票建立绑定关系,并向用户开通访问电子乘车发票的访问通道,以使用户能够获取电子乘车发票。以此实现了用户对线上数字化订单的发票开具处理,节约成本,延长了发票的保存周期,进一步提升用户使用发票的便捷程度。
本实施例中,通过一种中间连接装置(即传输组件)实现数据传输,并且,通过所述传输组件实现出租车的中控系统与服务器侧的数据传输,具体的,所述传输组件通过排线与出租车计价器建立物理连接,在所述物理连接的基础上获取数据并上传。
具体实施时,为了确保获得的数据可靠且有效,确保乘客乘车的有效性和真实性,本实施例提供的一种可选实施方式中,所述传输组件通过排线连接于出租车的计价器,所述传输组件从与所述计价器连接的中控系统获取身份标识,并从所述计价器获取所述乘车行程信息中的计价信息;其中,所述计价器在检测到所述出租车扣表动作和/或所述出租车抬表动作的情况下,采集的行程起始信息和/或行程终止信息,并将所述行程起始信息和/或所述行程终止信息传输给所述传输组件。
具体的,为了保证数据的准确性,通过与出租车连接的传输组件直接获取所述出租车的信息,本实施例提供的一种可选实施方式中,所述传输组件采用如下方式上传所述乘车行程信息:
获取行程起始信息以及行程终止信息;
在监测到满足行程上传条件的情况下,将所述行程起始信息与所述行程终止信息作为乘车行程信息上传。
例如,与出租车通过排线建立物理连接的传输组件,获取到出租车计价器在检测到出租车扣表动作时传输的行程起始信息以及检测到出租车抬表动作时传输的行程终止信息,在传输系统监测到已经接收乘车费用的情况下,将行程其实信息以及行程终止信息作为乘车行程信息上传;其中,行程起始信息中包括出租车当班司机的身份标识、出租车的车牌号、行程起始时间以及行程起始位置;行程终止信息中包括乘车费用、当班司机的身份标识、出租车的车牌号、行程终止时间以及行程终止位置。
实际应用中,所述传输组件上配置至少一个图像标识,所述图像标识是为了使司机人员进行绑定,在司机人员没有与所述图像标识绑定的情况下,乘客不能通过所述图像标识进行乘车费用的支付。具体实施时,为了使乘客支付乘车费用的过程更加简便,在乘客结束乘车行程通过扫描所述图像标识进行乘车费用支付之前,参与所述传输组件所属车辆换班处理的至少一个司机人员需要与所述传输组件上配置的至少一个图像标识进行绑定,具体的,一个司机人员只能与一个图像标识码进行绑定,所述出租车的当班司机扫描所述传输组件配置的图像标识的情况下,将所述图像标识与所述当班司机进行绑定,在绑定之后将所述图像标识配置为所述当班司机对应的收款标识,并建立所述收款标识与所述当班司机的收款账户的关联关系。
具体实施时,为了节约成本,减少浪费与环境污染,针对每一笔乘车行程,在对应的乘车订单被标记为已支付状态的情况下,都会生成该笔乘车行程的电子乘车发票;本实施例提供的一种可选实施方式中,在获取到根据所述传输组件上传的乘车行程数据生成的行程订单之后,还要进行如下操作:
在所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息,生成所述乘车行程信息对应的乘车行程的电子乘车发票;其中,所述电子乘车发票与所述乘车行程信息具有关联关系。
例如,乘客乘坐出租车,在t1时刻从p1位置出发前往p2位置,出租车的计价器上通过排线连接了传输组件,传输组件从计价器获取到行程信息并上传之后,会根据该乘车行程信息生成此次乘车行程的行程订单,在乘客的乘车行程结束且通过与传输组件配合扫码完成乘车费用的支付之后,该行程订单被标记为已支付状态,在此基础上,生成该乘车行程的电子乘车发票,其中,电子乘车发票与该次乘车行程的乘车行程信息具有关联关系。
步骤S104,在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单。
具体实施时,支付平台中存在至少一个用户的至少一个乘车行程的支付订单,为了将与乘车行程的乘车行程信息绑定的电子乘车发票绑定到对应乘客对该乘车行程的支付信息中,使乘客可以在需要的时候获取该电子乘车发票,需要查询与所述乘车行程匹配的目标支付订单。本实施例从四个数据维度进行所述目标支付订单的查询,具体的,包括支付信息中的支付链路、收款账户、支付时间以及支付金额,上述四个数据维度在具体实现时可以并行实现,也可以串行实现。
为了使查询到的目标支付订单更加有效并且更加准确,本实施例提供的一种可选实施方式中,具体采用如下方式查询所述目标支付订单:
在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个中间支付订单;
在所述至少一个中间支付订单中查询支付信息中的支付要素与所述乘车行程信息中对应的基准要素匹配的支付订单;所述基准要素包括:当班司机对应的收款账户、行程终止时间以及乘车费用;
判断查询到的支付订单的数目是否为一个;
若是,则将查询到的支付订单确定为所述目标支付订单;
若否,则判定未查询到与所述乘车行程信息匹配的支付信息。
具体实施时,首先在所述至少一个支付订单中查询支付订单中包含的支付链路为乘车标识码对应的支付链路的至少一个中间支付订单,然后在所述至少一个中间支付订单中,查询支付信息中的收款账户、支付时间以及支付金额与所述乘车行程信息中的当班司机对应的收款账户、行程终止时间以及乘车费用匹配的支付订单,再判断所述支付订单的数目,在所述支付订单的数目为一个的情况下,将所述支付订单确定为所述目标支付订单。
例如,乘客乘坐当班司机D的出租车,在t1时刻从p1地出发前往p2地,在t2时刻到达p2地,乘车费用为n1,乘车行程的行程订单为已支付状态,并生成了乘车行程的电子乘车发票,该电子乘车发票与乘车行程的乘车行程信息具有关联关系,其中,为了查找与乘车行程的乘车行程信息匹配的支付订单,首先在支付平台生成的至少一个支付订单中,查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个中间支付订单;在查询到的至少一个中间支付订单中查询支付收款方为当班司机D对应的收款账户、支付时间在t2时刻前后五分钟内以及支付金额为n1的支付订单;判断查询到的支付订单是否为一个,若为一个,则将该支付订单确定为与该乘车行程的乘车行程信息匹配的目标支付订单。
除此之外,为了提升所述目标支付订单的查询效率,本实施例提供的一种可选实施方式中,还可以通过如下方式来查询所述目标支付订单:
在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个第一支付订单;
在所述至少一个第一支付订单中查询支付信息中的收款方为所述乘车行程信息中的当班司机对应的收款账户的至少一个第二支付订单;
在所述至少一个第二支付订单中查询支付信息中的支付时间在所述乘车行程信息中的行程终止时间的预设时间范围内的至少一个第三支付订单;
在所述至少一个第三支付订单中查询支付信息中的支付金额在所述乘车行程信息中的乘车费用的预设费用范围内的至少一个第四支付订单;
判断所述第四支付订单的数目是否为一个;
若是,确定所述第四支付订单为所述目标支付订单;
若否,则判定未查询到与所述乘车行程信息匹配的支付信息。
具体的,在获得所述第一支付订单之后,判断所述第一支付订单的数目是否为一个,若是,则确定所述第一支付订单为所述目标支付订单;在获得所述第二支付订单之后,判断所述第二支付订单的数目是否为一个,若是,则确定所述第二支付订单为所述目标支付订单;在获得所述第三支付订单之后,判断所述第三支付订单的数目是否为一个,若是,则确定所述第三支付订单为所述目标支付订单;此外,若所述第一支付订单的数目为一个,还可对所述第一支付订单进行支付元素的核验,如收款账户、支付时间以及支付金额;类似的,在所述第二支付订单或所述第三支付订单的数目为一个的情况下,也可对所述第二支付订单或所述第三支付订单进行支付元素的核验。
例如,乘客乘坐当班司机D的出租车,在t1时刻从p1地出发前往p2地,在t2时刻到达p2地,乘车费用为n1,乘车行程的行程订单为已支付状态,并生成了乘车行程P的电子乘车发票,该电子乘车发票与乘车行程的乘车行程信息具有关联关系,其中,为了查找与乘车行程的乘车行程信息匹配的支付订单,首先在支付平台生成的至少一个支付订单中,查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个第一支付订单;再在至少一个第一支付订单中查询支付信息中的收款方为当班司机D对应的收款账户的至少一个第二支付订单;然后,在至少一个第二支付订单中查询支付信息中的支付时间在t2时刻前后五分钟内的至少一个第三支付订单;还要在至少一个第三支付订单中查询支付信息中的支付金额为n1的至少一个第四支付订单,最后,判断第四支付订单的数目是否为一个,若是,则将该第四支付订单确定为与该乘车行程的乘车行程信息匹配的目标支付订单。
具体实施时,若查询到的所述支付订单的数目不为一个,则确定所述目标支付订单的查询结果为空,为了确保乘客在使用时能够获取到对应的电子乘车发票,本实施例提供的一种可选实施方式中,在所述查询结果为空的情况下,采用如下方式进行查询:
确定订单列表中被访问支付订单的基准支付信息;
在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;
建立所述目标行程订单与所述被访问支付订单的关联关系;
基于所述关联关系,在所述被访问支付订单的订单详情页面展示所述被访问支付订单的电子乘车发票。
具体的,在乘客打开乘车行程对应的支付订单时,确定被访问支付订单的基准支付信息,在所述至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;在查询到所述目标行程订单的基础上,建立所述目标行程订单与所述被访问支付订单的关联关系,基于所述关联关系,将所述目标行程订单对应的乘车行程的电子乘车发票确定为所述被访问支付订单的电子乘车发票,并建立所述电子乘车发票与所述被访问支付订单的关联关系,最后在所述被访问支付订单的订单详情页面展示所述电子乘车发票或者在所述订单详情页面配置可查看所述电子乘车发票的触发控件。
为了使查询到的目标行程订单的乘车行程信息与所述基准支付信息的匹配程度更高,本实施例提供的一种可选实施方式中,具体采用如下方式查询所述目标行程订单:
判断所述被访问支付订单的支付信息中的支付链路是否为乘车标识码对应的特定支付链路;
在所述支付链路为所述特定支付链路的情况下,在所述至少一个行程订单中查询乘车行程信息中的乘车费用与所述基准支付信息的支付金额匹配的第一行程订单;
判断所述第一行程订单的数目是否为一个;
若是,将所述第一行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验,和/或,将所述乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间进行核验;
在所述核验通过的情况下,将所述第一行程订单作为所述目标行程订单。
具体实施时,首先对所述被访问支付订单中包含的支付链路进行判断,判断所述支付链路是否为所述乘车标识码对应的特定支付链路,若不是,确定所述被访问支付订单不可开具电子乘车发票;若是,则在所述至少一个行程订单中查询乘车行程信息中的乘车费用为所述基准支付信息中的支付金额的第一行程订单,并判断所述第一行程订单的数目是否为一个,若所述第一行程订单的数目为一个,则对所述第一行程订单进行进一步的核验,具体的,对所述第一行程订单的乘车行程信息中的当班司机的身份标识对应的收款账户以及行程终止时间进行核验,其中,核验所述当班司机的身份标识对应的收款账户与所述基准信息中的收款账户是否一致,核验所述行程终止时间与所述基准支付信息中的支付时间是否一致;最后,在核验通过的情况下,将所述第一行程订单作为所述目标行程订单;若核验不通过,则判定所述被访问支付订单没有匹配的电子乘车发票。
本实施例提供的一种可选实施方式中,为了进一步确保所述目标行程订单的有效性以及准确性,进一步提高乘车行程信息与所述基准支付信息的匹配程度,在经过判断所述第一行程订单的数目为至少两个的情况下,采用如下方式进行进一步查询:
在所述第一行程订单中查询乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间匹配的第二行程订单;
判断所述第二行程订单的数目是否为一个;
若是,将所述第二行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验;
在所述核验通过的情况下,将所述第二行程订单作为所述目标行程订单。
具体实施时,在至少两个第一支付订单中查询乘车行程信息中的行程终止信息与所述基准支付信息中的支付时间匹配的第二行程订单,并判断所述第二行程订单的数目是否为一个,若所述第二行程订单的数目为一个,则对所述第二行程订单进行进一步的核验,具体的,对所述第二行程订单的乘车行程信息中的当班司机的身份标识对应的收款账户进行核验,核验所述当班司机的身份标识对应的收款账户与所述基准信息中的收款账户是否一致,若一致,则将所述第二行程订单作为所述目标行程订单;若不一致,则判定所述被访问支付订单没有匹配的电子乘车发票;若所述第二行程订单的数目为至少两个,则在至少两个第二行程订单中查询乘车行程信息中的当班司机的身份标识对应的收款账户与所述基准支付信息中的收款账户匹配的第三行程订单,并判断所述第三行程订单的数目是否为一个,若是,则将所述第三行程订单作为所述目标行程订单,若不是,则判定所述被访问支付订单没有匹配的电子乘车发票。
步骤S106,建立所述行程订单与所述目标支付订单的关联关系。
具体实施时,在查询到所述目标支付订单的基础上,将所述目标支付订单作为所述行程订单对应的乘车行程的支付订单,并建立所述行程订单与所述目标支付订单的关联关系。
步骤S108,基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
具体实施时,为了简化乘客的使用流程,使乘客在使用时能够方便快捷的使用电子乘车发票,在建立了所述行程订单与所述目标支付订单的关联关系之后,在所述目标支付订单的订单详情页面进行发票申请通道配置。
本实施例提供的一种可选实施方式中,在获取根据传输组件上传的乘车行程信息生成的行程订单被标记为已支付状态的情况下,根据所述乘车行程信息生成所述乘车行程信息对应的乘车行程的电子乘车发票,在此基础上,采用如下方式确定所述目标支付订单的电子乘车发票并进行发票申请通道配置:
将所述乘车行程的电子乘车发票确定为所述目标支付订单的电子乘车发票;
建立所述电子乘车发票与所述目标支付订单的关联关系并在所述目标支付订单的订单详情页面进行发票申请通道配置。
具体实施时,首先将所述乘车行程的电子乘车发票确定为所述目标支付订单的电子乘车发票,并建立所述电子乘车发票与所述目标支付订单的关联关系,基于此,所述乘车行程信息、所述电子发票与所述目标支付订单之间具有关联关系,基于这种关联关系,在所述目标支付订单的订单详情页面进行发票申请通道配置;本实施例提供的一种可选实施方式中,采用如下方式进行所述发票申请通道的配置:
在所述目标支付订单的订单详情页面展示所述目标支付订单的电子乘车发票;
或者,在所述目标支付订单的订单详情页面配置所述目标支付订单的电子乘车发票的触发控件。
例如,经过查询,确定了与乘车行程的行程订单匹配的目标支付订单,则将该乘车行程的电子乘车发票确定为目标支付订单的电子乘车发票,并且,建立该电子乘车发票与该目标支付订的关联关系,然后在该目标支付订单的订单详情页面展示该电子乘车发票或者在该订单详情页面配置可查看该电子乘车发票的触发控件。
下述结合附图2,以本实施例提供的电子乘车发票处理方法在出租车场景的应用为例,对本实施例提供的电子乘车发票处理方法进行进一步说明。参照图2,应用于出租车场景的电子乘车发票处理方法具体包括步骤S202至步骤S216。
步骤S202,获取传输组件上传的乘车行程信息生成的行程订单。
步骤S204,在支付平台生成的至少一个支付订单中查询中间支付订单。
具体的,在支付平台生成的至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个中间支付订单。
进一步,判断中间支付订单的查询结果是否为空;
若是,则确定订单列表中被访问支付订单的基准支付信息;并在行程订单集合包含的至少一个行程订单中查询乘车行程信息与基准支付信息匹配的目标行程订单;在目标行程订单仅有一个的情况下,建立目标行程订单与被访问支付订单的关联关系,并在该被访问支付订单的订单详情页面展示与目标行程订单对应的乘车行程信息绑定的电子乘车发票;
若否,则执行步骤S206至步骤S208。
步骤S206,在中间支付订单中查询支付要素与乘车行程信息匹配的支付订单。
具体的,在所述至少一个中间支付订单中查询支付信息中的支付要素与所述乘车行程信息中对应的基准要素匹配的支付订单;所述基准要素包括:当班司机对应的收款账户、行程终止时间和/或乘车费用。
步骤S208,判断查询到的支付订单的数目是否为一个;
若是,则执行步骤S210至步骤S216;
若否,则判定未查询到与行程订单匹配的目标支付订单。
步骤S210,将查询到的支付订单确定为目标支付订单。
步骤S212,建立目标支付订单与行程订单的绑定关系。
步骤S214,确定目标支付订单的电子乘车发票。
步骤S216,在目标支付订单的订单详情页面进行发票申请通道配置。
本实施例提供的电子乘车发票处理方法,首先获取根据传输组件上传的乘车行程信息生成的行程订单,然后在支付平台生成的至少一个支付订单中查询支付信息与乘车行程匹配的目标支付订单,在查询到目标支付订单的基础上,建立目标支付订单与行程订单的关联关系并确定该目标支付订单的电子乘车发票,最后在目标支付订单的订单详情页面进行发票申请通道配置。以此将行程信息与乘客的支付信息关联起来,进一步通过开具电子发票节约成本,提高发票的保存时间。
本说明书提供的一种电子乘车发票处理装置实施例如下:
在上述的实施例中,提供了一种电子乘车发票处理方法,与之相对应的,还提供了一种电子乘车发票处理装置,下面结合附图进行说明。
参照图3,其示出了本实施例提供的一种电子乘车发票处理装置示意图。
由于装置实施例对应于方法实施例,所以描述得比较简单,相关的部分请参照上述提供的方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例提供一种电子乘车发票处理装置,包括:
获取模块302,被配置为获取根据传输组件上传的乘车行程信息生成的行程订单;
查询模块304,被配置为在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
关联模块306,被配置为建立所述行程订单与所述目标支付订单的关联关系;
确定模块308,被配置为基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
可选的,所述查询模块304,包括:
中间支付订单查询子模块,被配置为在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个中间支付订单;
要素查询子模块,被配置为在所述至少一个中间支付订单中查询支付信息中的支付要素与所述乘车行程信息中对应的基准要素匹配的支付订单;所述基准要素包括:当班司机的身份标识对应的收款账户、行程终止时间和/或乘车费用;
判断子模块,被配置为判断查询到的支付订单的数目是否为一个;
若是,则运行目标支付订单确定子模块,所述目标支付订单确定子模块,被配置为将查询到的支付订单确定为所述目标支付订单。
可选的,所述查询模块304,包括:
第一支付订单查询子模块,被配置为在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个第一支付订单;
第二支付订单查询子模块,被配置为在所述至少一个第一支付订单中查询支付信息中的收款方为所述乘车行程信息中的当班司机对应的收款账户的至少一个第二支付订单;
第三支付订单查询子模块,被配置为在所述至少一个第二支付订单中查询支付信息中的支付时间在所述乘车行程信息中的行程终止时间的预设时间范围内的至少一个第三支付订单;
第四支付订单查询子模块,被配置为在所述至少一个第三支付订单中查询支付信息中的支付金额在所述乘车行程信息中的乘车费用的预设费用范围内的至少一个第四支付订单;
数目判断子模块,被配置为判断所述第四支付订单的数目是否为一个;
若是,则运行所述目标支付订单确定子模块。
可选的,所述电子乘车发票处理装置,还包括:
电子乘车发票生成模块,被配置为在所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息,生成所述乘车行程信息对应的乘车行程的电子乘车发票;其中,所述电子乘车发票与所述乘车行程信息具有关联关系;
相应的,所述确定模块308,具体被配置为将所述乘车行程的电子乘车发票确定为所述目标支付订单的电子乘车发票;建立所述电子乘车发票与所述目标支付订单的关联关系并在所述目标支付订单的订单详情页面进行发票申请通道配置。
可选的,所述确定模块308,包括:
展示子模块,被配置为建立所述电子乘车发票与所述目标支付订单的关联关系并在所述目标支付订单的订单详情页面展示所述目标支付订单的电子乘车发票;
触发控件配置子模块,被配置为建立所述电子乘车发票与所述目标支付订单的关联关系并在所述目标支付订单的订单详情页面配置所述目标支付订单的电子乘车发票的触发控件。
可选的,所述传输组件通过运行如下模块上传所述乘车行程信息:
信息获取模块,被配置为获取行程起始信息以及行程终止信息;
信息上传模块,被配置为在监测到满足行程上传条件的情况下,将所述行程起始信息与所述行程终止信息作为乘车行程信息上传。
可选的,所述传输组件通过排线连接于出租车的计价器,所述传输组件从与所述计价器连接的中控系统获取身份标识,并从所述计价器获取所述乘车行程信息中的计价信息;所述出租车的当班司机扫描所述传输组件配置的图像标识的情况下,将所述图像标识与所述当班司机进行绑定,在绑定之后将所述图像标识配置为所述当班司机对应的收款标识,并建立所述收款标识与所述当班司机的收款账户的关联关系;其中,所述计价器在检测到所述出租车扣表动作和/或所述出租车抬表动作的情况下,采集的行程起始信息和/或行程终止信息,并将所述行程起始信息和/或所述行程终止信息传输给所述传输组件。
可选的,所述电子乘车发票处理装置,还包括:
基准支付信息确定模块,被配置为确定订单列表中被访问支付订单的基准支付信息;
目标行程订单查询模块,被配置为在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;
关联关系建立模块,被配置为建立所述目标行程订单与所述被访问支付订单的关联关系;
页面展示模块,被配置为基于所述关联关系,在所述被访问支付订单的订单详情页面展示所述被访问支付订单的电子乘车发票。
可选的,所述目标行程订单查询模块,包括:
支付链路判断子模块,被配置为判断所述被访问支付订单的支付信息中的支付链路是否为乘车标识码对应的特定支付链路;
第一行程订单查询子模块,被配置为在所述支付链路为所述特定支付链路的情况下,在所述至少一个行程订单中查询乘车行程信息中的乘车费用与所述基准支付信息的支付金额匹配的第一行程订单;
第一行程订单数目判断子模块,被配置为判断所述第一行程订单的数目是否为一个;
若是,运行第一核验子模块,所述第一核验子模块,被配置为将所述第一行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验,将所述乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间进行核验;在所述核验通过的情况下,将所述第一行程订单作为所述目标行程订单。
可选的,所述订单数目判断子模块,包括:
第二行程订单查询单元,被配置为在所述第一行程订单中查询乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间匹配的第二行程订单;
第二行程订单数目判断单元,被配置为判断所述第二行程订单的数目是否为一个;
若是,运行第二核验单元,所述第二核验单元,被配置为将所述第二行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验;在所述核验通过的情况下,将所述第二行程订单作为所述目标行程订单。
本说明书提供的一种电子乘车发票处理设备实施例如下:
对应上述描述的一种电子乘车发票处理方法,基于相同的技术构思,本说明书一个或多个实施例还提供一种电子乘车发票处理设备,该设备用于执行上述的一种电子乘车发票处理方法,图4为本说明书一个或多个实施例提供的一种电子乘车发票处理设备的结构示意图。
如图4所示,电子乘车发票处理设备可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上的处理器401和存储器402,存储器402中可以存储有一个或一个以上存储应用程序或数据。其中,存储器402可以是短暂存储或持久存储。存储在存储器402的应用程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括电子乘车发票处理设备中的一系列计算机可执行指令。更进一步地,处理器401可以设置为与存储器402通信,在电子乘车发票处理设备上执行存储器402中的一系列计算机可执行指令。电子乘车发票处理设备还可以包括一个或一个以上电源403,一个或一个以上有线或无线网络接口404,一个或一个以上输入输出接口405,一个或一个以上键盘406等。
在一个具体的实施例中,电子乘车发票处理设备包括有存储器,以及一个或一个以上的程序,其中一个或者一个以上程序存储于存储器中,且一个或者一个以上程序可以包括一个或一个以上模块,且每个模块可以包括对电子乘车发票处理设备中的一系列计算机可执行指令,且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令:
获取根据传输组件上传的乘车行程信息生成的行程订单;
在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
建立所述行程订单与所述目标支付订单的关联关系;
基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
可选的,所述目标支付订单的查询结果为空的情况下,执行如下操作:
确定订单列表中被访问支付订单的基准支付信息;
在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;
建立所述目标行程订单与所述被访问支付订单的关联关系;
基于所述关联关系,在所述被访问支付订单的订单详情页面展示所述被访问支付订单的电子乘车发票。
可选的,所述在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单,包括:
判断所述被访问支付订单的支付信息中的支付链路是否为乘车标识码对应的特定支付链路;
在所述支付链路为所述特定支付链路的情况下,在所述至少一个行程订单中查询乘车行程信息中的乘车费用与所述基准支付信息的支付金额匹配的第一行程订单;
判断所述第一行程订单的数目是否为一个;
若是,将所述第一行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验,和/或,将所述乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间进行核验;
在所述核验通过的情况下,将所述第一行程订单作为所述目标行程订单。
可选的,所述判断所述第一行程订单的数目是否为一个子步骤执行之后的执行结果为否,执行如下操作:
在所述第一行程订单中查询乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间匹配的第二行程订单;
判断所述第二行程订单的数目是否为一个;
若是,将所述第二行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验;
在所述核验通过的情况下,将所述第二行程订单作为所述目标行程订单。
本说明书提供的一种存储介质实施例如下:
对应上述描述的一种电子乘车发票处理方法,基于相同的技术构思,本说明书一个或多个实施例还提供一种存储介质。
本实施例提供的存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被执行时实现以下流程:
获取根据传输组件上传的乘车行程信息生成的行程订单;
在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
建立所述行程订单与所述目标支付订单的关联关系;
基于所述关联关系,确定所述目标支付订单的电子乘车发票并进行发票申请通道配置。
可选的,所述目标支付订单的查询结果为空的情况下,执行如下操作:
确定订单列表中被访问支付订单的基准支付信息;
在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;
建立所述目标行程订单与所述被访问支付订单的关联关系;
基于所述关联关系,在所述被访问支付订单的订单详情页面展示所述被访问支付订单的电子乘车发票。
可选的,所述在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单,包括:
判断所述被访问支付订单的支付信息中的支付链路是否为乘车标识码对应的特定支付链路;
在所述支付链路为所述特定支付链路的情况下,在所述至少一个行程订单中查询乘车行程信息中的乘车费用与所述基准支付信息的支付金额匹配的第一行程订单;
判断所述第一行程订单的数目是否为一个;
若是,将所述第一行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验,和/或,将所述乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间进行核验;
在所述核验通过的情况下,将所述第一行程订单作为所述目标行程订单。
可选的,所述判断所述第一行程订单的数目是否为一个子步骤执行之后的执行结果为否,执行如下操作:
在所述第一行程订单中查询乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间匹配的第二行程订单;
判断所述第二行程订单的数目是否为一个;
若是,将所述第二行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验;
在所述核验通过的情况下,将所述第二行程订单作为所述目标行程订单。
需要说明的是,本说明书中关于存储介质的实施例与本说明书中关于用户资源处理方法的实施例基于同一发明构思,因此该实施例的具体实施可以参见前述对应方法的实施,重复之处不再赘述。
上述对本说明书特征实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特征顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在20世纪30年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特征的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书实施例时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特征方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特征任务或实现特征抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书的一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本文件的实施例而已,并不用于限制本文件。对于本领域技术人员来说,本文件可以有各种更改和变化。凡在本文件的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本文件的权利要求范围之内。

Claims (14)

1.一种电子乘车发票处理方法,包括:
获取根据传输组件上传的乘车行程信息生成的行程订单;所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息生成所述行程订单对应的乘车行程的电子乘车发票;
在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
建立所述行程订单与所述目标支付订单的关联关系,并在所述目标支付订单的订单详情页面展示所述电子乘车发票。
2.根据权利要求1所述的电子乘车发票处理方法,所述在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单,包括:
在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个中间支付订单;
在所述至少一个中间支付订单中查询支付信息中的支付要素与所述乘车行程信息中对应的基准要素匹配的支付订单;所述基准要素包括:当班司机的身份标识对应的收款账户、行程终止时间和/或乘车费用;
判断查询到的支付订单的数目是否为一个;
若是,则将查询到的支付订单确定为所述目标支付订单。
3.根据权利要求1所述的电子乘车发票处理方法,所述在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单,包括:
在所述至少一个支付订单中查询支付信息中的支付链路为乘车标识码对应的特定支付链路的至少一个第一支付订单;
在所述至少一个第一支付订单中查询支付信息中的收款方为所述乘车行程信息中的当班司机对应的收款账户的至少一个第二支付订单;
在所述至少一个第二支付订单中查询支付信息中的支付时间在所述乘车行程信息中的行程终止时间的预设时间范围内的至少一个第三支付订单;
在所述至少一个第三支付订单中查询支付信息中的支付金额在所述乘车行程信息中的乘车费用的预设费用范围内的至少一个第四支付订单;
判断所述第四支付订单的数目是否为一个;
若是,确定所述第四支付订单为所述目标支付订单。
4.根据权利要求1所述的电子乘车发票处理方法,所述获取根据传输组件上传的乘车行程信息生成的行程订单步骤执行之后,还包括:
在所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息,生成所述乘车行程信息对应的乘车行程的电子乘车发票;其中,所述电子乘车发票与所述乘车行程信息具有关联关系;
相应的,所述在所述目标支付订单的订单详情页面展示所述电子乘车发票,包括:
将所述乘车行程的电子乘车发票确定为所述目标支付订单的电子乘车发票;
建立所述电子乘车发票与所述目标支付订单的关联关系并在所述订单详情页面展示所述电子乘车发票。
5.根据权利要求4所述的电子乘车发票处理方法,所述将所述乘车行程的电子乘车发票确定为所述目标支付订单的电子乘车发票,包括:
建立所述电子乘车发票与所述目标支付订单的关联关系。
6.根据权利要求1所述的电子乘车发票处理方法,所述传输组件采用如下方式上传所述乘车行程信息:
获取行程起始信息以及行程终止信息;
在监测到满足行程上传条件的情况下,将所述行程起始信息与所述行程终止信息作为乘车行程信息上传。
7.根据权利要求1所述的电子乘车发票处理方法,所述传输组件通过排线连接于出租车的计价器,所述传输组件从与所述计价器连接的中控系统获取身份标识,并从所述计价器获取所述乘车行程信息中的计价信息;
所述出租车的当班司机扫描所述传输组件配置的图像标识的情况下,将所述图像标识与所述当班司机进行绑定,在绑定之后将所述图像标识配置为所述当班司机对应的收款标识,并建立所述收款标识与所述当班司机的收款账户的关联关系;
其中,所述计价器在检测到所述出租车扣表动作和/或所述出租车抬表动作的情况下,采集行程起始信息和/或行程终止信息,并将所述行程起始信息和/或所述行程终止信息传输给所述传输组件。
8.根据权利要求1所述的电子乘车发票处理方法,所述目标支付订单的查询结果为空的情况下,执行如下操作:
确定订单列表中被访问支付订单的基准支付信息;所述基准支付信息包括支付金额、收款账户和/或支付时间;
在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单;
建立所述目标行程订单与所述被访问支付订单的关联关系;
基于所述关联关系,在所述被访问支付订单的订单详情页面展示所述被访问支付订单的电子乘车发票。
9.根据权利要求8所述的电子乘车发票处理方法,所述在行程订单集合包含的至少一个行程订单中查询乘车行程信息与所述基准支付信息匹配的目标行程订单,包括:
判断所述被访问支付订单的支付信息中的支付链路是否为乘车标识码对应的特定支付链路;
在所述支付链路为所述特定支付链路的情况下,在所述至少一个行程订单中查询乘车行程信息中的乘车费用与所述基准支付信息的支付金额匹配的第一行程订单;
判断所述第一行程订单的数目是否为一个;
若是,将所述第一行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验,和/或,将所述乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间进行核验;
在所述核验通过的情况下,将所述第一行程订单作为所述目标行程订单。
10.根据权利要求9所述的电子乘车发票处理方法,所述判断所述第一行程订单的数目是否为一个子步骤执行之后的执行结果为否,执行如下操作:
在所述第一行程订单中查询乘车行程信息中的行程终止时间与所述基准支付信息中的支付时间匹配的第二行程订单;
判断所述第二行程订单的数目是否为一个;
若是,将所述第二行程订单的乘车行程信息中的身份标识对应的收款账户与所述基准支付信息中的收款账户进行核验;
在所述核验通过的情况下,将所述第二行程订单作为所述目标行程订单。
11.一种电子乘车发票处理方法,包括:
获取根据传输组件上传的乘车行程信息生成的行程订单;所述行程订单被标记为已支付状态的情况下,生成所述行程订单对应的乘车行程的电子乘车发票;
在支付平台生成的多个支付订单中查询与所述电子乘车发票对应的目标支付订单;
在所述目标支付订单的数目为一个的情况下建立所述目标支付订单与所述电子乘车发票的绑定关系;
对所述目标支付订单开通所述电子乘车发票的访问通道。
12.一种电子乘车发票处理装置,包括:
获取模块,被配置为获取根据传输组件上传的乘车行程信息生成的行程订单;所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息生成所述行程订单对应的乘车行程的电子乘车发票;
查询模块,被配置为在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
关联模块,被配置为建立所述行程订单与所述目标支付订单的关联关系,并在所述目标支付订单的订单详情页面展示所述电子乘车发票。
13.一种电子乘车发票处理设备,包括:
处理器;以及,
被配置为存储计算机可执行指令的存储器,所述计算机可执行指令在被执行时使所述处理器:
获取根据传输组件上传的乘车行程信息生成的行程订单;所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息生成所述行程订单对应的乘车行程的电子乘车发票;
在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
建立所述行程订单与所述目标支付订单的关联关系,并在所述目标支付订单的订单详情页面展示所述电子乘车发票。
14.一种存储介质,用于存储计算机可执行指令,所述计算机可执行指令在被执行时实现以下流程:
获取根据传输组件上传的乘车行程信息生成的行程订单;所述行程订单被标记为已支付状态的情况下,基于所述乘车行程信息生成所述行程订单对应的乘车行程的电子乘车发票;
在支付平台生成的至少一个支付订单中查询支付信息与所述乘车行程信息匹配的目标支付订单;
建立所述行程订单与所述目标支付订单的关联关系,并在所述目标支付订单的订单详情页面展示所述电子乘车发票。
CN202211581027.5A 2020-11-02 2020-11-02 电子乘车发票处理方法及装置 Pending CN115860848A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211581027.5A CN115860848A (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011202843.1A CN112288502B (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置
CN202211581027.5A CN115860848A (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202011202843.1A Division CN112288502B (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置

Publications (1)

Publication Number Publication Date
CN115860848A true CN115860848A (zh) 2023-03-28

Family

ID=74354004

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202011202843.1A Active CN112288502B (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置
CN202211581027.5A Pending CN115860848A (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202011202843.1A Active CN112288502B (zh) 2020-11-02 2020-11-02 电子乘车发票处理方法及装置

Country Status (1)

Country Link
CN (2) CN112288502B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113222679A (zh) * 2021-05-26 2021-08-06 支付宝(杭州)信息技术有限公司 一种票据的生成方法及装置
CN113674038A (zh) * 2021-08-18 2021-11-19 支付宝(杭州)信息技术有限公司 凭证权限处理方法及装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107316216A (zh) * 2017-07-28 2017-11-03 北京聚利科技股份有限公司 出租车电子发票生成方法、装置和系统
CN107993106B (zh) * 2017-12-14 2020-04-10 阿里巴巴集团控股有限公司 电子发票生成方法及装置
CN108230053A (zh) * 2017-12-19 2018-06-29 广州地铁设计研究院有限公司 一种城市轨道交通电子发票的开票系统及方法
CN109191093A (zh) * 2018-09-25 2019-01-11 深圳邮信互联软件信息平台有限公司 电子发票开票方法、装置及终端设备
CN109615444A (zh) * 2018-11-02 2019-04-12 航天信息股份有限公司 开具电子发票的方法,行程工单装置和电子发票系统
CN109978638A (zh) * 2019-03-11 2019-07-05 秒针信息技术有限公司 一种出租车行程费用处理方法及装置
CN110033573A (zh) * 2019-03-20 2019-07-19 北京悦畅科技有限公司 一种开具停车发票的方法、服务器和系统
CN110163614A (zh) * 2019-05-21 2019-08-23 深圳前海微众银行股份有限公司 应付账款订单校验方法、装置、设备及存储介质
CN111523902B (zh) * 2020-03-17 2024-08-02 上海云砺信息科技有限公司 电子发票开具方法、系统、控制设备及存储介质

Also Published As

Publication number Publication date
CN112288502B (zh) 2023-01-10
CN112288502A (zh) 2021-01-29

Similar Documents

Publication Publication Date Title
CN113128508B (zh) 基于车牌号的支付处理方法及装置
CN111968401B (zh) 车位推荐方法及装置、停车场的车位预测方法及装置
CN112288502B (zh) 电子乘车发票处理方法及装置
CN110852736B (zh) 用车支付方法、装置、系统及电子设备
CN108805601B (zh) 一种识别用户、账号注册的方法、装置及设备
CN115345608A (zh) 乘车信息处理方法及装置
CN117935383A (zh) 乘车费用计算方法及装置
CN113411385B (zh) 车辆信息采集方法及装置、车辆订单处理方法及装置
CN115293533A (zh) 派单处理方法及装置
CN115408705A (zh) 车辆通行数据的处理方法、装置、设备及系统
CN113672784B (zh) 基于区块链的车辆信息处理方法、装置及系统
CN112233422B (zh) 车辆停驶检测方法及装置
CN113807810A (zh) 电子车牌共享方法及装置
CN114550322A (zh) 车辆服务费用处理方法及装置
CN114037547A (zh) 车险事故处理方法、装置、系统以及设备
CN113673975A (zh) 数据处理方法及装置
CN113034710A (zh) 租赁车辆的etc代扣处理方法及装置
CN113674038A (zh) 凭证权限处理方法及装置
CN113672786A (zh) 电子车牌处理方法及装置
CN113065863B (zh) 公交车辆乘车费用支付方法及装置
CN112884925B (zh) 多账户切换处理方法及装置
CN116013089A (zh) 车辆提醒方法及装置
CN115827960A (zh) 车辆通行处理方法及装置
CN117456622A (zh) Etc代扣处理方法及装置
CN115933939A (zh) 出租车的服务交互处理方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination