CN112633965A - 订单处理方法、装置、电子设备及存储介质 - Google Patents

订单处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN112633965A
CN112633965A CN202011447756.2A CN202011447756A CN112633965A CN 112633965 A CN112633965 A CN 112633965A CN 202011447756 A CN202011447756 A CN 202011447756A CN 112633965 A CN112633965 A CN 112633965A
Authority
CN
China
Prior art keywords
order
request
responsibility
server
issuing request
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.)
Withdrawn
Application number
CN202011447756.2A
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.)
Hanhai Information Technology Shanghai Co Ltd
Original Assignee
Hanhai Information Technology Shanghai 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 Hanhai Information Technology Shanghai Co Ltd filed Critical Hanhai Information Technology Shanghai Co Ltd
Priority to CN202011447756.2A priority Critical patent/CN112633965A/zh
Publication of CN112633965A publication Critical patent/CN112633965A/zh
Withdrawn 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/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
    • 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
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • G06Q10/025Coordination of plural reservations, e.g. plural trip segments, transportation combined with accommodation

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明实施例提供了一种订单处理方法、装置、电子设备及存储介质。订单处理方法包括:第一服务端在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。本发明实施例能够使排队更加合理,保障乘客的权益,提升乘客体验,进而提高成单率。

Description

订单处理方法、装置、电子设备及存储介质
技术领域
本发明涉及互联网技术领域,特别是涉及一种订单处理方法、装置、电子设备及存储介质。
背景技术
随着互联网技术的迅速发展,网约车服务越来越受到用户的青睐,用户通过网约车服务能够更加便利、更加快速地进行乘车。
在使用网约车服务的过程中,乘客在乘客客户端发起发单请求,服务端按照发单请求的排队时间点对发单请求进行排队,发单请求被接单后,在服务端生成对应订单。但是,在实际应用中,可能存在发单请求被接单后取消的情况,该种情况下,乘客需要再次在乘客客户端发起发单请求,并在服务端重新排队等候。
但是,如果是接单方恶意取消订单,则会导致乘客的发单请求在服务端排队不合理,降低乘客体验,进而降低成单率。
发明内容
鉴于上述问题,提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种订单处理方法、装置、电子设备及存储介质。
第一方面,本发明实施例公开了一种订单处理方法,执行于第一服务端,所述方法包括:
在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;
在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;
当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。
可选地,所述方法还包括:在接收到与所述客户端之间的距离在预设范围内的其他客户端发起的第三发单请求后,如果所述第二发单请求还未被接单,则获取所述第一判责信息,并判断所述第三发单请求是否允许被延迟;在所述第一判责信息为接单方责任,并且所述第三发单请求允许被延迟时,将所述第三发单请求延迟预设时长后,发送至所述第二服务端和所述第三服务端。
可选地,所述判断所述第三发单请求是否允许被延迟,包括:判断是否存在所述第三发单请求对应的未处理的第二判责信息;在不存在所述第二判责信息时,确定所述第三发单请求允许被延迟;在存在所述第二判责信息,并且所述第二判责信息为非接单方责任时,确定所述第三发单请求允许被延迟。
可选地,在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息之前,还包括:在接收到所述第一发单请求后,记录所述第一发单请求的第一接收时间点;在接收到所述客户端再次发起的第二发单请求后,还包括:记录所述第二发单请求的第二接收时间点;所述将所述第一判责信息和所述第二发单请求发送至第二服务端,包括:在所述第一接收时间点和所述第二接收时间点之间的时间间隔小于预设阈值时,将所述第一判责信息和所述第二发单请求发送至第二服务端。
可选地,所述第一服务端为聚合平台服务端,所述第二服务端为自营商家服务端,所述第三服务端为入驻商家服务端。
第二方面,本发明实施例公开了一种订单处理方法,执行于第二服务端,所述方法包括:
接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息;所述第二发单请求由客户端在发起的所述第一发单请求被接单后取消的情况下,再次发起至所述第一服务端;所述第一判责信息由所述第一服务端在所述第一发单请求被接单后取消的情况下,对取消情况进行判责得到;
当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
可选地,在接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息之前,还包括:在接收到所述第一发单请求后,记录所述第一发单请求的排队时间点;所述将所述第二发单请求的排队时间点向前调节,包括:将所述第一发单请求的排队时间点,作为所述第二发单请求的排队时间点。
第三方面,本发明实施例公开了一种订单处理装置,应用于第一服务端,所述装置包括:
判责模块,用于在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;
发送模块,用于在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;
当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。
可选地,所述装置还包括:判断模块,用于在接收到与所述客户端之间的距离在预设范围内的其他客户端发起的第三发单请求后,如果所述第二发单请求还未被接单,则获取所述第一判责信息,并判断所述第三发单请求是否允许被延迟;延迟模块,用于在所述第一判责信息为接单方责任,并且所述第三发单请求允许被延迟时,将所述第三发单请求延迟预设时长后,发送至所述第二服务端和所述第三服务端。
可选地,所述判断模块包括:信息判断单元,用于判断是否存在所述第三发单请求对应的未处理的第二判责信息;确定单元,用于在不存在所述第二判责信息时,确定所述第三发单请求允许被延迟;在存在所述第二判责信息,并且所述第二判责信息为非接单方责任时,确定所述第三发单请求允许被延迟。
可选地,所述装置还包括:第一记录模块,用于在接收到所述第一发单请求后,记录所述第一发单请求的第一接收时间点;第二记录模块,用于在接收到所述客户端再次发起的第二发单请求后,记录所述第二发单请求的第二接收时间点;所述发送模块包括:信息发送单元,用于在所述第一接收时间点和所述第二接收时间点之间的时间间隔小于预设阈值时,将所述第一判责信息和所述第二发单请求发送至第二服务端。
可选地,所述第一服务端为聚合平台服务端,所述第二服务端为自营商家服务端,所述第三服务端为入驻商家服务端。
第四方面,本发明实施例公开了一种订单处理装置,应用于第二服务端,所述装置包括:
接收模块,用于接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息;所述第二发单请求由客户端在发起的所述第一发单请求被接单后取消的情况下,再次发起至所述第一服务端;所述第一判责信息由所述第一服务端在所述第一发单请求被接单后取消的情况下,对取消情况进行判责得到;
调节模块,用于当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
可选地,所述装置还包括:第三记录模块,用于在接收到所述第一发单请求后,记录所述第一发单请求的排队时间点;所述调节模块,具体用于当所述第一判责信息为接单方责任时,将所述第一发单请求的排队时间点,作为所述第二发单请求的排队时间点。
第五方面,本发明实施例公开了一种电子设备,包括:一个或多个处理器;和其上存储有指令的一个或多个机器可读介质;当所述指令由所述一个或多个处理器执行时,使得所述处理器执行如上任一项由第一服务端执行的订单处理方法,或者,执行如上任一项由第二服务端执行的订单处理方法。
第六方面,本发明实施例公开了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如上任一项由第一服务端执行的订单处理方法,或者,实现如上任一项由第二服务端执行的订单处理方法。
本发明实施例中,第一服务端在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到第一发单请求对应的第一判责信息;在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;当所述第一判责信息为接单方责任时,所述第二服务端将所述第二发单请求的排队时间点向前调节。由此可知,本发明实施例中,在客户端发起的第一发单请求被接单后取消的情况下,第一服务端对取消情况进行判责,并将第一发单请求对应的第一判责信息与客户端再次发起的第二发单请求一同发送至第二服务端,如果是由于接单方责任取消订单,则第二服务端对于客户端再次发起的第二发单请求不再重新排队,而是将第二发单请求的排队时间点向前调节,也即为第二发单请求插队,以使排队更加合理,保障乘客的权益,提升乘客体验,进而提高成单率。
附图说明
图1是本发明实施例的一种订单处理方法的步骤流程图。
图2是本发明实施例的另一种订单处理方法的步骤流程图。
图3是本发明实施例的一种订单处理过程的示意图。
图4是本发明实施例的一种订单处理装置的结构框图。
图5是本发明实施例的另一种订单处理装置的结构框图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
在聚合模式的网约车体系中,乘客在乘客客户端发起的第一发单请求发送至第一服务端,由第一服务端将第一发单请求分别发送至第二服务端和第三服务端,第二服务端和第三服务端对第一发单请求进行排队,第二服务端的商家和第三服务端的商家可以进行接单。如果乘客发起的第一发单请求在被接单后取消,则乘客可以再次发起第二发单请求,将第二发单请求发送至第一服务端,由第一服务端将第二发单请求分别发送至第二服务端和第三服务端。通常情况下,第二服务端和第三服务端对第二发单请求进行重新排队,但是如果是由于接单方恶意取消,则重新排队并不合理。
因此,本发明实施例中,在客户端发起的第一发单请求被接单后取消的情况下,第一服务端对取消情况进行判责,并将第一发单请求对应的第一判责信息与客户端再次发起的第二发单请求一同发送至第二服务端,如果是由于接单方责任取消订单,则第二服务端对于客户端再次发起的第二发单请求不再重新排队,而是将第二发单请求的排队时间点向前调节,也即为第二发单请求插队,以使排队更加合理,保障乘客的权益,提升乘客体验,进而提高成单率。
本发明实施例中,发起发单请求的客户端为乘客客户端。乘客客户端可以为乘客使用的APP(应用程序),也可以为巡游出租车乘客招手上车后,乘客使用的用来与该巡游出租车建立关联订单的APP。司机客户端可以为司机使用的APP,也可以为巡游出租车的车载智能车机端。
下面,通过以下各实施例进行详细说明。
参照图1,示出了本发明实施例的一种订单处理方法的步骤流程图。图1所示的订单处理方法执行于第一服务端。
如图1所示,订单处理方法可以包括以下步骤:
步骤101,第一服务端在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息。
客户端发起的第一发单请求可能在第二服务端被接单,也可能在第三服务端被接单。因此,第一发单请求被接单后取消的情况,可以为第一发单请求在第二服务端被接单后取消,也可以为第一发单请求在第三服务端被接单后取消,本发明实施例对此不做限制。
如果第一发单请求在第二服务端被接单后取消,则第二服务端将向第一服务端发送第一发单请求被接单后取消的通知;如果第一发单请求在第三服务端被接单后取消,则第三服务端将向第一服务端发送第一发单请求被接单后取消的通知。第一服务端在得知客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到第一判责信息。第一判责信息可以包括接单方责任、非接单方责任(比如乘客责任)等。
步骤102,第一服务端在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端。
客户端发起的第一发单请求被接单后取消的情况下,乘客可以在客户端再次发起第二发单请求,并将第二发单请求发送至第一服务端。第一服务端在接收到所述客户端再次发起的第二发单请求后,将第一判责信息和第二发单请求发送至第二服务端,将第二发单请求发送至第三服务端。
第二服务端接收到第二发单请求后,依据第一判责信息,确定第二发单请求的排队时间点。第三服务端接收到第二发单请求后,对第二发单请求进行重新排队。
参照图2,示出了本发明实施例的另一种订单处理方法的步骤流程图。图2所示的订单处理方法执行于第二服务端。
如图2所示,订单处理方法可以包括以下步骤:
步骤201,第二服务端接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息。
步骤202,第二服务端当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
第二服务端在接收到第一服务端发送的,由客户端发起的第一发单请求后,将接收到第一发单请求的时间点作为第一发单请求的排队时间点,对第一发单请求进行排队。
第二服务端在接收到第一服务端发送的,由客户端在第一发单请求被接单取消后再次发起的第二发单请求和第一判责信息后,依据第一判责信息确定第二发单请求的排队时间点。当第一判责信息为接单方责任时,第二服务端将第二发单请求的排队时间点向前调节;当第一判责信息为非接单方责任时,第二服务端对第二发单请求进行重新排队。
本发明实施例中,在客户端发起的第一发单请求被接单后取消的情况下,第一服务端对取消情况进行判责,并将第一发单请求对应的第一判责信息与客户端再次发起的第二发单请求一同发送至第二服务端,如果是由于接单方责任取消订单,则第二服务端对于客户端再次发起的第二发单请求不再重新排队,而是将第二发单请求的排队时间点向前调节,也即为第二发单请求插队,以使排队更加合理,保障乘客的权益,提升乘客体验,进而提高成单率。
下面,基于客户端、第一服务端、第二服务端、第三服务端之间的整体交互过程,介绍本发明实施例的订单处理方法。本发明实施例中的第一服务端为聚合平台服务端,第二服务端为自营商家服务端,第三服务端为入驻商家服务端。
图3是本发明实施例的一种订单处理过程的示意图。图3所示的实施例,以客户端发起的第一发单请求在第三服务端被接单后取消的情况为例进行说明。
如图3所示,订单处理过程如下:
1、乘客端向第一服务端发起第一发单请求。
乘客在客户端上设置起点位置、终点位置等信息后,触发第一发单请求,乘客端向第一服务端发起第一发单请求。第一发单请求中可以包括起点位置、终点位置、乘客信息、设备信息、车辆类型,等等。其中,乘客信息可以包括乘客的联系方式等信息;设备信息可以包括乘客客户端所在设备的标识信息、客户端信息等;车辆类型可以包括快车、专车、出租车、顺风车、拼车等。
2、第一服务端分别请求第二服务端(也即自营商家)和第三服务端(也即入驻商家)。
第一服务端接收到第一发单请求后,将第一发单请求分别发送至第二服务端和第三服务端。
3、第二服务端记录第一发单请求的排队信息。
第二服务端在接收到第一发单请求后,获取接收到第一发单请求的接收时间点,将接收到第一发单请求的接收时间点作为第一发单请求的排队时间点,并记录第一发单请求的排队时间点。
第二服务端按照第一发单请求的排队时间点,对第一发单请求进行排队等候,在排到第一发单请求后,第二服务端可以进行派单,或者由司机进行抢单,以便第二服务端的司机(也即自营商家的司机)进行接单。第二服务端还可以向第一服务端返回第一发单请求的排队信息,排队信息可以包括排队时间点、排队位置等。
4、第三服务端向第一服务端返回司机接单且订单取消。
第三服务端在接收到第一发单请求后,获取接收到第一发单请求的接收时间点,将接收到第一发单请求的接收时间点作为第一发单请求的排队时间点。第三服务端按照第一发单请求的排队时间点,对第一发单请求进行排队等候,在排到第一发单请求后,第三服务端可以进行派单,或者由司机进行抢单,以便第三服务端的司机(也即入驻商家的司机)进行接单。第三服务端还可以向第一服务端返回第一发单请求的排队信息,排队信息可以包括排队时间点、排队位置等。
第二服务端和第三服务端在各自接收到第一发单请求后,分别对第一发单请求进行排队。如果第二服务端的司机在第三服务端的司机之前接单,则第二服务端向第一服务端返回第一发单请求被司机接单;如果第三服务端的司机在第二服务端的司机之前接单,则第三服务端向第一服务端返回第一发单请求被司机接单。
本发明实施例中,以第三服务端的司机在第二服务端的司机之前接单为例进行说明。并且,第三服务端的司机接单之后订单又取消,也即第一发单请求在第三服务端被接单后取消。因此,第三服务端向第一服务端返回司机接单且订单取消。
5、第一服务端向判责系统请求判责。
6、判责系统向第一服务端返回第一判责信息。
第一服务端接收到第三服务端返回的司机接单且订单取消信息后,对取消情况进行判责,得到客户端发起的第一发单请求对应的第一判责信息。第一服务端存储第一发单请求对应的第一判责信息,还可以将第一判责信息标记为未处理。
在一种可选实施方式中,第一服务端可以向判责系统请求判责。比如,第三服务端在司机接单后,可以获取以下参考信息中的至少一种:乘客与接单司机之间的通话记录,乘客与接单司机之间的端内消息记录,接单车辆在接单后的行驶路线数据,乘客在被接单后的移动数据,第三服务端的故障数据,等等。第三服务端在第一发单请求被接单后取消的情况下,将获取的上述参考信息发送给第一服务端。第一服务端在第一发单请求被接单后取消的情况下,将接收到的参考信息发送给判责系统。判责系统接收到参考信息后,基于参考信息进行判责,得到第一发单请求对应的第一判责信息。判责系统将第一判责信息返回给第一服务端。
在一种可选实施方式中,判责系统可以根据预先训练的判责模型进行判责。在训练判责模型的过程中,获取大量的样本数据,每个样本数据都包括样本参考信息和所述样本参考信息的标注责任标签,比如责任标签可以为接单方责任、非接单方责任等。基于大量样本数据,采用机器学习算法对待训练判责模型进行训练,将样本参考信息作为待训练判责模型的输入,依据待训练判责模型的输出及样本参考信息的标注责任标签计算损失值,在损失值处于预设范围内时,确定训练完成,将训练完成的模型作为判责模型。因此,对取消情况进行判责的过程可以包括:将参考信息输入预先训练的判责模型,得到判责模型输出的,参考信息对应的第一判责信息。第一判责信息可以包括接单方责任、非接单方责任等。
7、乘客端向第一服务端发起第二发单请求。
乘客在第一发单请求被接单后取消的情况下,可以在客户端上再次触发第二发单请求,乘客端向第一服务端发起第二发单请求。第二发单请求中可以包括起点位置、终点位置、乘客信息、设备信息、车辆类型,等等。
8、第一服务端分别请求第二服务端(也即自营商家)和第三服务端(也即入驻商家)。
第一服务端接收到客户端再次发起的第二发单请求后,分别请求第二服务端和第三服务端。第一服务端可以获取该客户端发起的第一发单请求对应的第一判责信息,将第二发单请求和第一判责信息一同发送至第二服务端。第一服务端将第二发单请求发送至第三服务端。
在一种可选实施方式中,第三服务端在接收到客户端发起的第一发单请求后,还可以记录所述第一发单请求的第一接收时间点;在接收到该客户端再次发起的第二发单请求后,还可以记录所述第二发单请求的第二接收时间点。第一服务端在将所述第一判责信息和所述第二发单请求发送至第二服务端之前,还可以判断所述第一接收时间点和所述第二接收时间点之间的时间间隔是否小于预设阈值。如果所述第一接收时间点和所述第二接收时间点之间的时间间隔小于预设阈值,则可以认为客户端是因为第一发单请求被接单后取消的原因发起的第二发单请求,因此第一服务端可以将所述第一判责信息和所述第二发单请求发送至第二服务端;如果所述第一接收时间点和所述第二接收时间点之间的时间间隔大于等于预设阈值,则可以认为客户端不是因为第一发单请求被接单后取消的原因发起的第二发单请求,因此第一服务端不再将第一判责信息发送至第二服务端,将第二发单请求发送至第二服务端即可。
对于预设阈值的具体数值,本领域技术人员根据实际经验设置任意适用的数值均可。比如,预设阈值可以设置为2分钟、3分钟、5分钟,等等,本发明实施例对此不做限制。
比如,由于接单方责任取消订单的场景可以包括但不限于以下情况:
a)司机接单后原地不动,乘客无法联系到司机导致乘客取消订单;
b)司机以各种理由不愿意接乘客并要求乘客取消订单;
c)入驻商家系统(比如第三服务端)出错导致无故取消订单。
9、第二服务端判断第一判责信息是否为接单方责任。若是,则执行步骤10;若否,则执行步骤11。
如果第二服务端接收到第一服务端发送的第一判责信息和第二发单请求,则判断第一判责信息是否为接单方责任。
如果第二服务端接收到第一服务端发送的第二发单请求,未接收到第一判责信息,则第二服务端在接收到第二发单请求后,获取接收到第二发单请求的接收时间点,将接收到第二发单请求的接收时间点作为第二发单请求的排队时间点。第二服务端按照第二发单请求的排队时间点,对第二发单请求进行排队等候,在排到第二发单请求后,第二服务端可以进行派单,或者由司机进行抢单,以便第二服务端的司机进行接单。
本发明实施例中,步骤9~步骤11是对第二服务端接收到第一服务端发送的第一判责信息和第二发单请求的情况进行说明。
10、第二服务端在判定为接单方责任后,获取第一发单请求的排队信息,进行插队。
第二服务端在判断出第一判责信息为接单方责任后,可以将第二发单请求的排队时间点向前调节,以便为第二发单请求实现插队,缩短乘客的等待时间。第二服务端按照调节后的第二发单请求的排队时间点,对第二发单请求进行排队等候,在排到第二发单请求后,第二服务端可以进行派单,或者由司机进行抢单,以便第二服务端的司机进行接单。第二服务端还可以向第一服务端返回第二发单请求的排队信息,排队信息可以包括排队时间点、排队位置等。
在一种可选实施方式中,第二服务端可以获取之前记录的第一发单请求的第一发单请求的排队时间点,将所述第一发单请求的排队时间点,作为所述第二发单请求的排队时间点。
11、第二服务端在判定为非接单方责任后,进行重新排队。
第二服务端在判断出第一判责信息为非接单方责任后,对第二发单请求进行重新排队。第二服务端获取接收到第二发单请求的接收时间点,将接收到第二发单请求的接收时间点作为第二发单请求的排队时间点。第二服务端按照第二发单请求的排队时间点,对第二发单请求进行排队等候,在排到第二发单请求后,第二服务端可以进行派单,或者由司机进行抢单,以便第二服务端的司机进行接单。第二服务端还可以向第一服务端返回第二发单请求的排队信息,排队信息可以包括排队时间点、排队位置等。
12、第三服务端进行重新排队。
第三服务端在接收到第二发单请求后,对第二发单请求进行重新排队。第三服务端获取接收到第二发单请求的接收时间点,将接收到第二发单请求的接收时间点作为第二发单请求的排队时间点。第三服务端按照第二发单请求的排队时间点,对第二发单请求进行排队等候,在排到第二发单请求后,第三服务端可以进行派单,或者由司机进行抢单,以便第三服务端的司机进行接单。第三服务端还可以向第一服务端返回第二发单请求的排队信息,排队信息可以包括排队时间点、排队位置等。
13、第一服务端对预设范围内的其他客户端执行延迟策略。
在一种可选实施方式中,第一服务端还可以对与当前客户端之间的距离在预设范围内的其他客户端执行延迟策略。
在实现中,第一服务端在接收到与所述客户端之间的距离在预设范围内的其他客户端发起的第三发单请求后,如果所述第二发单请求还未被接单,则获取所述第一判责信息,并判断所述第三发单请求是否允许被延迟;在所述第一判责信息为接单方责任,并且所述第三发单请求允许被延迟时,将所述第三发单请求延迟预设时长后,发送至所述第二服务端和所述第三服务端。在所述第二发单请求已被接单,或者,所述第三发单请求不允许被延迟,或者,所述第一判责信息为非接单方责任的情况下,不对第三发单请求做延迟处理,将所述第三发单请求发送至所述第二服务端和所述第三服务端。对于预设范围和预设时长的具体数值,可以根据实际经验设置任意适用的数值。比如,预设范围可以为2公里、2.5公里、3公里,等等。预设时长可以为15秒、20秒、25秒,等等。
其中,判断所述第三发单请求是否允许被延迟的过程可以包括:判断是否存在所述第三发单请求对应的未处理的第二判责信息;在不存在所述第二判责信息时,确定所述第三发单请求允许被延迟;在存在所述第二判责信息,并且所述第二判责信息为非接单方责任时,确定所述第三发单请求允许被延迟;在存在所述第二判责信息,并且所述第二判责信息为接单方责任时,确定所述第三发单请求不允许被延迟。
如果第二服务端的司机在第三服务端的司机之前接单,则第二服务端向第一服务端返回第二发单请求被司机接单;如果第三服务端的司机在第二服务端的司机之前接单,则第三服务端向第一服务端返回第二发单请求被司机接单。第一服务端在第二发单请求被接单后,停止对上述其他客户端执行延迟策略。第一服务端在第二发单请求被接单后,还可以删除第一发单请求对应的第一判责信息,或者将第一发单请求对应的第一判责信息标记为已处理,等等。
本发明实施例中,基于聚合平台的场景,同时包含自营商家和入驻商家。针对接单方恶意取消订单的情况,从乘客体验视角考虑,乘客再次发单实现自营商家兜底插队逻辑,保证乘客此次出行顺利完成,提高乘客出行体验,提高成单率;并且聚合平台侧对一定范围内的其他客户端的发单请求执行延迟策略,保证当前乘客的足够运力,减少当前乘客的等待时间,提高乘客出行效率,增加用户粘性。
参照图4,示出了本发明实施例的一种订单处理装置的结构框图。图4所示的订单处理装置应用于第一服务端。
如图4所示,订单处理装置可以包括以下模块:
判责模块401,用于在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;
发送模块402,用于在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端。
其中,当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。
可选地,所述装置还包括:判断模块,用于在接收到与所述客户端之间的距离在预设范围内的其他客户端发起的第三发单请求后,如果所述第二发单请求还未被接单,则获取所述第一判责信息,并判断所述第三发单请求是否允许被延迟;延迟模块,用于在所述第一判责信息为接单方责任,并且所述第三发单请求允许被延迟时,将所述第三发单请求延迟预设时长后,发送至所述第二服务端和所述第三服务端。
可选地,所述判断模块包括:信息判断单元,用于判断是否存在所述第三发单请求对应的未处理的第二判责信息;确定单元,用于在不存在所述第二判责信息时,确定所述第三发单请求允许被延迟;在存在所述第二判责信息,并且所述第二判责信息为非接单方责任时,确定所述第三发单请求允许被延迟。
可选地,所述装置还包括:第一记录模块,用于在接收到所述第一发单请求后,记录所述第一发单请求的第一接收时间点;第二记录模块,用于在接收到所述客户端再次发起的第二发单请求后,记录所述第二发单请求的第二接收时间点;所述发送模块402包括:信息发送单元,用于在所述第一接收时间点和所述第二接收时间点之间的时间间隔小于预设阈值时,将所述第一判责信息和所述第二发单请求发送至第二服务端。
可选地,所述第一服务端为聚合平台服务端,所述第二服务端为自营商家服务端,所述第三服务端为入驻商家服务端。
参照图5,示出了本发明实施例的一种订单处理装置的结构框图。图5所示的订单处理装置应用于第二服务端。
如图5所示,订单处理装置可以包括以下模块:
接收模块501,用于接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息;所述第二发单请求由客户端在发起的所述第一发单请求被接单后取消的情况下,再次发起至所述第一服务端;所述第一判责信息由所述第一服务端在所述第一发单请求被接单后取消的情况下,对取消情况进行判责得到;
调节模块502,用于当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
可选地,所述装置还包括:第三记录模块,用于在接收到所述第一发单请求后,记录所述第一发单请求的排队时间点;所述调节模块502,具体用于当所述第一判责信息为接单方责任时,将所述第一发单请求的排队时间点,作为所述第二发单请求的排队时间点。
本发明实施例中,在客户端发起的第一发单请求被接单后取消的情况下,第一服务端对取消情况进行判责,并将第一发单请求对应的第一判责信息与客户端再次发起的第二发单请求一同发送至第二服务端,如果是由于接单方责任取消订单,则第二服务端对于客户端再次发起的第二发单请求不再重新排队,而是将第二发单请求的排队时间点向前调节,也即为第二发单请求插队,以使排队更加合理,保障乘客的权益,提升乘客体验,进而提高成单率。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
在本发明的实施例中,还提供了一种电子设备。该电子设备可以包括一个或多个处理器,以及其上存储有指令的一个或多个机器可读介质,指令例如应用程序。当所述指令由所述一个或多个处理器执行时,使得所述处理器执行如上任一项由第一服务端执行的订单处理方法,或者,执行如上任一项由第二服务端执行的订单处理方法。
在本发明的实施例中,还提供了一种非临时性计算机可读存储介质,其上存储有计算机程序,该程序可由电子设备的处理器执行,以实现如上任一项由第一服务端执行的订单处理方法,或者,实现如上任一项由第二服务端执行的订单处理方法。例如,所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本发明所提供的一种订单处理方法、装置、电子设备及存储介质,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims (11)

1.一种订单处理方法,其特征在于,执行于第一服务端,所述方法包括:
在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;
在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;
当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在接收到与所述客户端之间的距离在预设范围内的其他客户端发起的第三发单请求后,如果所述第二发单请求还未被接单,则获取所述第一判责信息,并判断所述第三发单请求是否允许被延迟;
在所述第一判责信息为接单方责任,并且所述第三发单请求允许被延迟时,将所述第三发单请求延迟预设时长后,发送至所述第二服务端和所述第三服务端。
3.根据权利要求2所述的方法,其特征在于,所述判断所述第三发单请求是否允许被延迟,包括:
判断是否存在所述第三发单请求对应的未处理的第二判责信息;
在不存在所述第二判责信息时,确定所述第三发单请求允许被延迟;
在存在所述第二判责信息,并且所述第二判责信息为非接单方责任时,确定所述第三发单请求允许被延迟。
4.根据权利要求1所述的方法,其特征在于,
在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息之前,还包括:在接收到所述第一发单请求后,记录所述第一发单请求的第一接收时间点;
在接收到所述客户端再次发起的第二发单请求后,还包括:记录所述第二发单请求的第二接收时间点;
所述将所述第一判责信息和所述第二发单请求发送至第二服务端,包括:在所述第一接收时间点和所述第二接收时间点之间的时间间隔小于预设阈值时,将所述第一判责信息和所述第二发单请求发送至第二服务端。
5.根据权利要求1所述的方法,其特征在于,所述第一服务端为聚合平台服务端,所述第二服务端为自营商家服务端,所述第三服务端为入驻商家服务端。
6.一种订单处理方法,其特征在于,执行于第二服务端,所述方法包括:
接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息;所述第二发单请求由客户端在发起的所述第一发单请求被接单后取消的情况下,再次发起至所述第一服务端;所述第一判责信息由所述第一服务端在所述第一发单请求被接单后取消的情况下,对取消情况进行判责得到;
当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
7.根据权利要求6所述的方法,其特征在于,
在接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息之前,还包括:在接收到所述第一发单请求后,记录所述第一发单请求的排队时间点;
所述将所述第二发单请求的排队时间点向前调节,包括:将所述第一发单请求的排队时间点,作为所述第二发单请求的排队时间点。
8.一种订单处理装置,其特征在于,应用于第一服务端,所述装置包括:
判责模块,用于在客户端发起的第一发单请求被接单后取消的情况下,对取消情况进行判责,得到所述第一发单请求对应的第一判责信息;
发送模块,用于在接收到所述客户端再次发起的第二发单请求后,将所述第一判责信息和所述第二发单请求发送至第二服务端,将所述第二发单请求发送至第三服务端;
当所述第一判责信息为接单方责任时,所述第一判责信息作为所述第二服务端将所述第二发单请求的排队时间点向前调节的依据。
9.一种订单处理装置,其特征在于,应用于第二服务端,所述装置包括:
接收模块,用于接收第一服务端发送的第二发单请求和第一发单请求对应的第一判责信息;所述第二发单请求由客户端在发起的所述第一发单请求被接单后取消的情况下,再次发起至所述第一服务端;所述第一判责信息由所述第一服务端在所述第一发单请求被接单后取消的情况下,对取消情况进行判责得到;
调节模块,用于当所述第一判责信息为接单方责任时,将所述第二发单请求的排队时间点向前调节。
10.一种电子设备,其特征在于,包括:
一个或多个处理器;和
其上存储有指令的一个或多个机器可读介质;
当所述指令由所述一个或多个处理器执行时,使得所述处理器执行如权利要求1至5任一项所述的方法,或者,执行如权利要求6至7任一项所述的方法。
11.一种计算机可读存储介质,其特征在于,其上存储有计算机程序,该程序被处理器执行时实现如权利要求1至5任一项所述的方法,或者,实现如权利要求6至7任一项所述的方法。
CN202011447756.2A 2020-12-11 2020-12-11 订单处理方法、装置、电子设备及存储介质 Withdrawn CN112633965A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011447756.2A CN112633965A (zh) 2020-12-11 2020-12-11 订单处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011447756.2A CN112633965A (zh) 2020-12-11 2020-12-11 订单处理方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN112633965A true CN112633965A (zh) 2021-04-09

Family

ID=75310295

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011447756.2A Withdrawn CN112633965A (zh) 2020-12-11 2020-12-11 订单处理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN112633965A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115578160A (zh) * 2022-11-24 2023-01-06 云账户技术(天津)有限公司 一种临时接单的方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108009650A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器
CN108805660A (zh) * 2018-05-24 2018-11-13 北京三快在线科技有限公司 订单处理方法、装置及服务器
WO2019196244A1 (zh) * 2018-04-10 2019-10-17 平安科技(深圳)有限公司 实时回调订单的方法和系统
CN110738441A (zh) * 2019-09-03 2020-01-31 熊维淑 一种基于互联网的商品预定配送方法及系统
CN111368590A (zh) * 2018-12-25 2020-07-03 北京嘀嘀无限科技发展有限公司 一种情绪识别方法、装置、电子设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108009650A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器
WO2019196244A1 (zh) * 2018-04-10 2019-10-17 平安科技(深圳)有限公司 实时回调订单的方法和系统
CN108805660A (zh) * 2018-05-24 2018-11-13 北京三快在线科技有限公司 订单处理方法、装置及服务器
CN111368590A (zh) * 2018-12-25 2020-07-03 北京嘀嘀无限科技发展有限公司 一种情绪识别方法、装置、电子设备及存储介质
CN110738441A (zh) * 2019-09-03 2020-01-31 熊维淑 一种基于互联网的商品预定配送方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
郑小红;龙军;蔡志平;: "关于网约车订单分配策略的综述", 计算机工程与科学, no. 07, pages 130 - 138 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115578160A (zh) * 2022-11-24 2023-01-06 云账户技术(天津)有限公司 一种临时接单的方法及装置

Similar Documents

Publication Publication Date Title
JP2020502666A5 (zh)
CN106228383A (zh) 一种生成订单邀约信息的方法和装置
US9037389B2 (en) Vehicle apparatus and system for controlling platoon travel and method for selecting lead vehicle
US20170169366A1 (en) Systems and Methods for Adjusting Ride-Sharing Schedules and Routes
CN105869424B (zh) 一种公交车调度方法和装置
WO2016008391A1 (zh) 在网络租车系统中为他人订车的方法和系统
CN109146280B (zh) 一种推送信息的方法、装置及系统
WO2016074538A1 (zh) 网络租车中降低空驶等待时间的派单排序系统和方法
CN107230091B (zh) 拼车请求订单匹配方法及装置
CN110570003A (zh) 一种基于空闲行程车辆的预约出行订单的派单方法和装置
CN111832788B (zh) 一种服务信息生成的方法、装置、计算机设备及存储介质
CN110033152A (zh) 用户车辆调度应对系统以及存储介质
CN108399460B (zh) 网络约车订单分配处理方法及服务器
US20190320043A1 (en) Network computer system to generate synthetic messages based on service-specific information
CN113701772B (zh) 一种导航路线确定方法、系统、电子设备及存储介质
CN111967720B (zh) 一种网约车的调度方法和系统
CN112633965A (zh) 订单处理方法、装置、电子设备及存储介质
CN112714101A (zh) 上车识别方法、装置、电子设备及存储介质
CN111178558B (zh) 网约车订单处理方法及装置、计算机设备和可读存储介质
CN109493168B (zh) 一种处理订单的方法、装置、设备及存储介质
CN109151035B (zh) 车辆通行管理方法及相关装置
CN110570100A (zh) 一种基于实时单行程车辆的实时单派单方法和装置
CN113254771B (zh) 银行网点推荐方法及装置
WO2014188587A1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
CN109725639A (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
WW01 Invention patent application withdrawn after publication

Application publication date: 20210409

WW01 Invention patent application withdrawn after publication