一种网约车订单的处理方法、装置、设备及介质与流程

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.图1显示为本发明的一种网约车订单的处理方法的流程图。
39.图2显示为图1中步骤s10的流程图。
40.图3显示为图1中步骤s30的流程图。
41.图4显示为图3中步骤s36的流程图。
42.图5显示为本发明的一种网约车订单的处理装置的示意图。
43.图6显示为本发明的一种计算机设备的示意图。
44.元件标号说明：
45.10、费用预估模块；20、订单生成模块；30、风险校验模块；40、订单取消模块；50、订单处理模块。
具体实施方式
46.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
47.请参阅图1-6。需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
48.请参阅图1所示，图1为本发明实施例提供的一种网约车订单的处理方法一个流程示意图，包括如下步骤：
49.步骤s10、响应于发起方的呼叫指令，服务端调用多个平台进行费用预估，并生成预估费用列表，其中，呼叫指令包括起点、终点、平台的类型及车型等。
50.请参阅图2所示，在本发明的一个实施例中，当进行步骤s10时，即响应于发起方的呼叫指令，服务端调用多个平台进行费用预估，并生成预估费用列表。具体的，步骤s10的子步骤可包括：
51.步骤s11、响应于发起方的呼叫指令，服务端调用多个平台进行费用预估。
52.步骤s12、对多个平台进行轮询，以生成预估费用。
53.步骤s13、当平台生成预估费用时，保留相应的预估费用。
54.步骤s14、将保留的预估费用进行集合，以生成预估费用列表。
55.步骤s15、当所有平台均未生成预估费用时，服务端生成呼叫失败指令，并将呼叫失败指令发送至发起方，以提醒发起方叫单失败。
56.在本发明的一个实施例中，具体的，发起方可以为乘客，平台可以为网约车平台，从而当乘客需要约车时，可以通过手机内部的app等向服务端发出呼叫指令，即发出打车请求。呼叫指令可以包括起点、终点、平台的类型及车型。其中，平台的类型可以是不同的网约车平台，例如可以为专车、众悦、公务、帮忙、包车游等平台。车型可以表示不同的车辆型号，
例如可以为新能源、舒适型、豪华型、商务型等车型。当乘客确定起点、终点后，选择相应的平台与相应的车型，之后向服务端发出呼叫指令时，服务端会根据呼叫指令中的信息，调用相应的平台，并根据起点与终点确定路程，根据路程与车型生成预估费用。
57.在本发明的一个实施例中，具体的，在生成预估费用的过程中，由于有的平台可能会存在一定的问题，导致服务端在轮询该平台时，该平台响应超时，从而此时该平台无法生成相应的预估费用，此时服务器会轮询其他平台。当其中一个平台生成相应的预估费用时，对该预估费用进行保存，之后可对生成的预估费用进行集合，从而生成相应的预估费用列表。预估费用列表中的每一项预估费用都会对应相应的平台，此时可将生成的预估费用列表发送至发起方，以供发起方进行选择。在服务端轮询的过程中，当所有的平台都出现响应超时的情况时，此时无法生成预估费用，从而此时服务端生成呼叫失败指令，并将呼叫失败指令发送至发起方，以提醒发起方叫单失败。发起方可以重新输入起点、终点、平台的类型及车型等，重新发出呼叫指令。
58.步骤s20、将预估费用列表发送至发起方，同时生成订单。
59.在本发明的一个实施例中，当执行步骤s20时，即将预估费用列表发送至发起方，同时生成订单。具体的，当将预估费用列表发送至发起方后，发起方可以在预估费用列表上选择相应的平台与车型，从而生成相应的订单，并将订单发送到服务端内。
60.步骤s30、对订单进行风控校验，以将订单发送至多个平台。
61.请参阅图3所示，在本发明的一个实施例中，当进行步骤s30时，即对订单进行风控校验，以将订单发送至多个平台。具体的，步骤s30的子步骤可包括：
62.步骤s31、服务端判断发起方是否存在未完成订单，若存在未完成订单，则将未完成订单的信息发送至发起方，若不存在未完成订单，则判断发起方是否属于风控人群。
63.步骤s32、当发起方属于风控人群时，服务端生成呼叫失败指令，将呼叫失败指令发送至发起方，并进行撤单处理。
64.步骤s33、当发起方不属于风控人群时，将订单发送至多个平台，对平台进行轮询，并判断平台是否成功接收到订单，同时初始化平台的需求状态。
65.步骤s34、当某一平台成功接收到订单后，将相应的平台的需求状态置为创建成功状态。
66.步骤s35、当某一平台未接收到订单后，将该平台的需求状态置为创建失败状态。
67.步骤s36、对处于创建失败状态的平台进行撤单处理。
68.在本发明的一个实施例中，具体的，当生成订单后，此时服务端需要对订单进行风控校验，判断订单是否合格。例如可以先判断发起方是否存在未完成的订单，之后再对该订单进行风控校验，或者也可先对该订单进行风控校验，之后再判断发起方是否存在未完成的订单。两者判断顺序可不加限制，可根据实际需求进行设定，在本实施例中，以先判断发起方是否存在未完成的订单，之后再对该订单进行风控校验为例进行说明。
69.在本发明的一个实施例中，具体的，当判断发起方是否存在未完成的订单时，若存在未完成订单，则服务端将未完成订单的信息发送至发起方，此时发起方可对该未完成订单进行处理，防止发起方重复下单，影响用户体验。若不存在未完成订单，此时服务端则判断发起方是否属于风控人群，风控人群可以是因违反了相关协定要求而被进行风险控制管理的一类人。例如，在订单完成后，发起方未支付相应的费用，此时服务端可将该发起方标
注属于风控人群。又例如，在将订单发送至平台时，平台接单后，发起方多次取消订单，此时服务端也可将该发起方标注属于风控人群。当发起方属于风控人群时，此时服务端可以生成呼叫失败指令，并将呼叫失败指令发送至发起方，进行撤单处理。当发起方不属于风控人群时，此时服务端可将订单发送到发起方选择的多个平台。
70.在本发明的一个实施例中，具体的，当服务端将订单发送到发起方选择的多个平台时，此时需要判断相应的平台是否接收到该订单。此时可初始化平台的需求状态，当某一个平台接收到该订单后，该平台可向服务端发出信号，服务端接收到此信号后，可将该平台的需求状态置为创建成功状态。当某一个平台未接收到该订单后，此时服务端与该平台之间无法通讯，此时服务端可将该平台的需求状态置为创建失败状态。如果服务端与所有平台之间均无法通讯，则此时服务端将所有平台的需求状态均置为创建失败状态。当平台顺利接收到该订单后，则表示叫单成功，并跳转到派单页面，等待司机接单。
71.请参阅图4所示，在本发明的一个实施例中，当进行步骤s36时，即对处于创建失败状态的平台进行撤单处理。具体的，步骤s36的子步骤可包括：
72.步骤s361、对处于创建失败状态的平台，经过预设时间阈值后，进行撤单处理，并判断是否撤单成功。
73.步骤s362、若撤单成功，则取消该平台的订单，若撤单失败，则重复执行多次撤单处理任务，直至当执行次数超过预设次数阈值时，取消该平台的订单。
74.在本发明的一个实施例中，具体的，对处于创建失败状态的平台，可以经过预设时间阈值后，对其进行撤单处理。在本实施例中，时间阈值可以为3秒、4秒、5秒、6秒等，时间阈值的大小可根据实际需求具体设定。由于可能会存在撤单失败的情况，当第一次撤单失败时，此时可经过另一个时间间隔，之后再进行撤单处理。当再次撤单失败时，可重复进行撤单处理，直至执行撤单的次数超过预设次数阈值时，直接取消该平台的订单。在本实施例中，在每次撤单处理前，等待的时间间隔可以相同，也可以不相同。次数阈值可以为5次，也可以为6次，次数阈值的大小可根据实际需求进行设定。例如当经过第一次撤单处理后，撤单失败时，可等待3秒后进行下一轮撤单，之后每一轮均等待3秒后进行撤单，直至撤单成功或者撤单次数达到次数阈值时，取消该平台的订单。
75.步骤s40、判断发起方是否发出取消指令，若发出取消指令，则服务端取消订单，若未发出取消指令，则判断是否有平台对订单进行接单处理。
76.在本发明的一个实施例中，具体的，在平台未对订单进行接单处理前，发起方可能因临时有事而取消订单，因此，在平台进行接单处理前，还需要判断发起方是否发出取消指令。当发起方发出取消指令时，服务端接收到该取消指令，并取消该订单，从而此时平台接收到的订单都会进行撤单处理。而当平台进行接单处理前，发起方未发出取消指令时，此时平台可正常进行接单处理，并判断是否有平台对订单进行接单处理。
77.步骤s50、当某一平台对订单进行接单处理后，向服务端服发出接单请求，服务端将接单结果返回至发起方，并锁定其余平台的订单。
78.在本发明的一个实施例中，具体的，由于服务端是将订单同时发往多个平台的，此时多个平台可均对该订单进行处理。当其中某一个平台内的司机进行接单处理后，该平台会向服务端发出接单请求，服务端接收到该平台的接单请求后，会将接单结果返回值发起方，表示发起方的订单被司机接单。同时，为了防止其他平台的司机重复接单，当服务端接
收到先接单平台的接单请求后，会锁定其余平台的订单，并进行撤单处理，其余平台内的司机无法对该订单进行接单操作。
79.可见，在上述方案中，通过聚合与管控打车生命周期，首先乘客的起点与终点，并通过多个平台，多个车型，预估费用，之后生成多个平台、多个车型的订单，在一个需求下，可以生成多个订单，从而完成接单需求。
80.应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
81.请参阅图5所示，本发明还提供一种网约车订单的处理装置，该网约车订单的处理装置与上述实施例中网约车订单的处理方法一一对应。该网约车订单的处理装置可以包括费用预估模块10、订单生成模块20、风险校验模块30、订单取消模块40以及订单处理模块50。各功能模块详细说明如下：
82.费用预估模块10可用于响应于发起方的呼叫指令，服务端调用多个平台进行费用预估，并生成预估费用列表，其中，呼叫指令包括起点、终点、平台的类型及车型等。订单生成模块20可用于将预估费用列表发送至发起方，同时生成订单。风险校验模块30可用于对订单进行风控校验，以将订单发送至多个平台。订单取消模块40可用于判断发起方是否发出取消指令，若发出取消指令，则服务端取消订单，若未发出取消指令，则判断是否有平台对订单进行接单处理。订单处理模块50可用于当某一平台对订单进行接单处理后，向服务端服发出接单请求，服务端将接单结果返回至发起方，并锁定其余平台的订单。
83.在本发明的一个实施例中，具体的，费用预估模块10可用于响应于发起方的呼叫指令，服务端调用多个平台进行费用预估，并生成预估费用列表。其中，发起方可以为乘客，平台可以为网约车平台，从而当乘客需要约车时，可以通过手机内部的app等向服务端发出呼叫指令，即发出打车请求。呼叫指令可以包括起点、终点、平台的类型及车型。其中，平台的类型可以是不同的网约车平台，例如可以为专车、众悦、公务、帮忙、包车游等平台。车型可以表示不同的车辆型号，例如可以为新能源、舒适型、豪华型、商务型等车型。当乘客确定起点、终点后，选择相应的平台与相应的车型，之后向服务端发出呼叫指令时，服务端会根据呼叫指令中的信息，调用相应的平台，并根据起点与终点确定路程，根据路程与车型生成预估费用。
84.在本发明的一个实施例中，具体的，订单生成模块20可用于将预估费用列表发送至发起方，同时生成订单。其中，当将预估费用列表发送至发起方后，发起方可以在预估费用列表上选择相应的平台与车型，从而生成相应的订单，并将订单发送到服务端内。
85.在本发明的一个实施例中，具体的，风险校验模块30可用于对订单进行风控校验，以将订单发送至多个平台。其中，生成订单后，此时服务端需要对订单进行风控校验，判断订单是否合格。例如可以先判断发起方是否存在未完成的订单，之后再对该订单进行风控校验，或者也可先对该订单进行风控校验，之后再判断发起方是否存在未完成的订单。两者判断顺序可不加限制，可根据实际需求进行设定。
86.在本发明的一个实施例中，具体的，订单取消模块40可用于判断发起方是否发出取消指令，若发出取消指令，则服务端取消订单，若未发出取消指令，则判断是否有平台对订单进行接单处理。其中，在平台未对订单进行接单处理前，发起方可能因临时有事而取消
订单，因此，在平台进行接单处理前，还需要判断发起方是否发出取消指令。当发起方发出取消指令时，服务端接收到该取消指令，并取消该订单，从而此时平台接收到的订单都会进行撤单处理。而当平台进行接单处理前，发起方未发出取消指令时，此时平台可正常进行接单处理，并判断是否有平台对订单进行接单处理。
87.在本发明的一个实施例中，具体的，订单处理模块50可用于当某一平台对订单进行接单处理后，向服务端服发出接单请求，服务端将接单结果返回至发起方，并锁定其余平台的订单。其中，由于服务端是将订单同时发往多个平台的，此时多个平台可均对该订单进行处理。当其中某一个平台内的司机进行接单处理后，该平台会向服务端发出接单请求，服务端接收到该平台的接单请求后，会将接单结果返回值发起方，表示发起方的订单被司机接单。同时，为了防止其他平台的司机重复接单，当服务端接收到先接单平台的接单请求后，会锁定其余平台的订单，并进行撤单处理，其余平台内的司机无法对该订单进行接单操作。
88.关于网约车订单的处理装置的具体限定可以参见上文中对于网约车订单的处理方法的限定，在此不再赘述。上述网约车订单的处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
89.请参阅图6所示，本发明还提供了一种计算机设备，该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性和/或易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的客户端通过网络连接通信。该计算机程序被处理器执行时以实现一种网约车订单的处理方法的功能或步骤。
90.在本发明的一个实施例中，计算机设备可以包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：
91.响应于发起方的呼叫指令，服务端调用多个平台进行费用预估，并生成预估费用列表，其中，呼叫指令包括起点、终点、平台的类型及车型。
92.将预估费用列表发送至发起方，同时生成订单。
93.对订单进行风控校验，以将订单发送至多个平台。
94.判断发起方是否发出取消指令，若发出取消指令，则服务端取消订单，若未发出取消指令，则判断是否有平台对订单进行接单处理。
95.当某一平台对订单进行接单处理后，向服务端服发出接单请求，服务端将接单结果返回至发起方，并锁定其余平台的订单。
96.需要说明的是，上述关于计算机可读存储介质或计算机设备所能实现的功能或步骤，可对应参阅前述方法实施例中，服务端侧以及客户端侧的相关描述，为避免重复，这里不再一一描述。
97.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机
可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
98.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
99.在本说明书的描述中，参考术语“本实施例”、“示例”、“具体示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的多个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
100.以上公开的本发明实施例只是用于帮助阐述本发明。实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。