网约车订单处理方法、装置、服务器及存储介质与流程

本发明涉及互联网技术领域，尤其涉及一种网约车订单处理方法、装置、服务器及存储介质。

背景技术：

随着移动互联网技术的发展，满足人们出行和拉货需求的网约车也得到了快速发展。人们通过打车应用软件在线上进行网约车下单，由司机进行线上接单后，在线下根据网约车订单进行拉客或拉货。

由于司机在接到乘客或货物驾驶过程中，会遇到车辆出现故障无法正常行驶的情况。现有技术中只能由司机通过电话或即时通信的方式找到继续完成订单的车辆，而通过这种方式使找到继续完成该订单的车辆的效率较低，耽误网约车订单的完成速度，进而使用户网约车体验较差。

技术实现要素：

本发明实施例提供了一种网约车订单处理方法、装置、服务器及存储介质，能够快速获取需要完成改派订单的车辆，提高用户网约车体验。

第一方面，本发明实施例提供一种网约车订单处理方法，包括：

接收第一终端设备发送的订单改派请求，所述订单改派请求中包括：所述第一终端设备对应的弃单车辆位置和初始订单信息；

根据所述弃单车辆位置和所述初始订单信息生成改派订单；

确定执行所述改派订单的改派车辆；

获取改派车辆信息，并向所述第一终端设备发送所述改派车辆信息。

第二方面，本发明实施例提供一种网约车订单处理装置，包括：

改派请求接收模块，用于接收第一终端设备发送的订单改派请求，所述订单改派请求中包括：所述第一终端设备对应的弃单车辆位置和初始订单信息；

改派订单生成模块，用于根据所述弃单车辆位置和所述初始订单信息生成改派订单；

改派车辆确定模块，用于确定执行所述改派订单的改派车辆；

信息发送模块，用于获取改派车辆信息，并向所述第一终端设备发送所述改派车辆信息。

第三方面，本发明实施例提供一种服务器，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第一方面中的网约车订单处理方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，用于储存服务器所用的计算机软件指令，其包含用于执行如第一方面的网约车订单处理方法所涉及的程序。

在本发明实施例中，司机只需通过第一终端设备触发订单改派请求，服务器就可根据订单改派请求匹配出改派车辆，并将改派车辆的信息发送给第一终端设备，所以能够快速获取需要完成改派订单的车辆，提高用户网约车体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一个实施例提供的网约车订单处理方法的流程图；

图2为本发明另一实施例提供的网约车订单处理方法的流程图；

图3为本发明又一实施例提供的网约车订单处理方法的流程图；

图4为本发明再一实施例提供的网约车订单处理方法的信令交互图；

图5为本发明下一实施例提供的网约车订单处理方法的流程图；

图6为本发明一个实施例提供的网约车订单处理装置的结构示意图；

图7为与图6所示实施例提供的网约车订单处理装置对应的服务器的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

下面结合以下的各个实施例对本文提供的网约车订单处理方法的执行过程进行说明。

图1为本发明一个实施例提供的网约车订单处理方法的流程图，如图1所示，该方法的执行主体为服务器，则该网约车订单处理方法包括以下步骤：

101、接收第一终端设备发送的订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置和初始订单信息。

在本实施例中，在第一终端设备中安装了进行打车的应用软件，如可以为滴滴打车，快狗打车等。用户通过该打车应用软件进行网约车的下单，司机通过该打车软件进行网约车的接单。

此处的第一终端设备的“第一”二字是为了与后续其他实施例中的终端设备进行区别。本文实施例中所提到的终端设备可以为智能手机、平板电脑、车载终端等终端设备。

可以理解的是，网约车的订单可以为拉客订单也可以为拉货订单，本实施例中对此不作限定。

其中，初始订单为用户通过打车应用软件进行下单的订单。第一终端设备为接到初始订单的司机的终端设备。

在本实施例，司机通过第一终端设备抢到初始订单从初始订单的起点行驶到初始订单的终点的过程中，由于出现一些突发情况，如车辆故障，家中突发急事儿，司机身体突发疾病等，而无法在继续该初始订单，将乘客和/或货物送到终点，需要进行订单的改派，则通过第一终端设备的打车应用软件的界面触发订单改派请求，则服务器接收到第一终端设备发送的订单改派请求。

其中，在该订单改派请求中可包括：第一终端设备对应的弃单车辆位置和初始订单信息。其中，初始订单信息中可包括：初始订单编号，起点位置，终点位置，订单为乘客或货物，需要接单车辆的类型等信息。

102、根据弃单车辆位置和初始订单信息生成改派订单。

在本实施例中，可获取初始订单中的终点位置并获取弃单车辆位置，根据终点位置及弃单车辆位置生成改派订单，并可为改派订单分配改派订单编号。可以理解的是，弃单车辆位置为改派订单的起点位置，初始订单中的终点位置为改派订单的终点位置。

值得说明的是，还可将初始订单中的订单为乘客或货物，和/或需要接单车辆的类型也加入到改派订单中，以便根据改派订单获取到与用户需求更加匹配的改派车辆。

103、确定执行改派订单的改派车辆。

在本实施例中，可向在每个已经开启接单功能的司机的终端设备发送该改派订单，在司机通过终端设备接收到改派订单后，若希望执行该改派订单，则通过终端设备向服务器发送改派接单响应。在服务器接收到至少一个终端设备发送的改派接单响应后，可将最先接收到的改派接单响应对应的终端设备的车辆确定为改派车辆。或者根据至少一个改派接单响应，确定与初始订单信息最匹配的终端设备的车辆确定该改派车辆，本实施例中对此不作限定。

104、获取改派车辆信息，并向第一终端设备发送改派车辆信息。

在本实施例中，可根据改派车辆的标识信息获取改派车辆信息，改派车辆信息可以包括：改派车辆司机的手机号，改派车辆的车牌号，改派车辆的类型及颜色等信息。并将改派车辆信息发送给第一终端设备，以使第一终端设备的司机根据改派车辆信息对改派车辆进行识别并可主动与改派车辆司机取得联系。

其中，改派车辆的标识信息可以为改派车辆在服务器中注册的编号，行驶证等唯一标识该改派车辆的信息。

本实施例提供的网约车订单处理方法，通过接收第一终端设备发送的订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置和初始订单信息；根据弃单车辆位置和初始订单信息生成改派订单；确定执行改派订单的改派车辆；获取改派车辆信息，并向第一终端设备发送改派车辆信息。司机只需通过第一终端设备触发订单改派请求，服务器就可根据订单改派请求匹配出改派车辆，并将改派车辆的信息发送给第一终端设备，所以能够快速获取需要完成改派订单的车辆，提高用户网约车体验。

图2为本发明另一个实施例提供的网约车订单处理方法的流程图，如图2所示，本实施例的执行主体为服务器，则该网约车订单处理方法包括以下步骤：

201、接收第一终端设备发送的订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置和初始订单信息。

202、根据弃单车辆位置和初始订单信息生成改派订单。

本实施例中，201-202的实现方式与图1中所示实施例中的101-102的实现方式相同，在此不再一一赘述。

203、确定与改派订单相匹配的至少一个第一车辆。

204、将改派订单发送给第一车辆对应的第二终端设备。

205、若最先接收到的第三终端设备发送的改派接单响应，则将第三终端设备对应的第一车辆确定为改派车辆。

此处，第一车辆中的“第一”二字是为了与后续其他实施例中的第二车辆进行区别。

结合203-205进行说明。在本实施例中，在确定执行改派订单的改派车辆时，由于采用打车应用软件等待接单的司机有多个，为了尽量满足公平竞争机制，在服务器确定出与改派订单相匹配的至少一个第一车辆后，向每个第一车辆对应的第二终端设备均发送该改派订单，由司机通过对应的第二终端设备进行抢单，若多个第二终端设备中的第三终端设备的司机最先进行了抢单，服务器最先接收到第三终端设备发送的改派接单响应，则将第三终端设备对应的第一车辆确定为改派车辆。该种方式确定出的执行改派订单的改派车辆更加符合司机的接单意愿，并且由多个第二终端设备进行抢单，能够更加快速地确定出改派车辆。

作为一种可选实施方式，本实施例中203中确定与改派订单相匹配的至少一个第一车辆可以包括：

2031、获取以弃单车辆位置为中心预设区域范围内的至少一个未接单车辆。

2032、将与弃单车辆同类型的未接单车辆确定为第一车辆。

在确定与改派订单相匹配的改派车辆时，目标是使该改派车辆尽可能满足用户对初始订单中车辆的要求，并且该改派车辆能够快速到达弃单车辆位置，继续完成该初始订单。

所以本实施例中，确定与改派订单相匹配的至少一个第一车辆时，首先选择出离弃单车辆位置距离较近的未接单车辆。具体方法可以为采用定位系统获取弃单车辆周围的未接单车辆的位置，确定出以弃单车辆为中心预设区域范围内的至少一个未接单车辆。然后根据初始订单信息中的需要接单车辆的类型确定出与弃单车辆同类型的未接单车辆，将与弃单车辆同类型的未接单车辆确定为第一车辆。

其中，确定出以弃单车辆为中心预设区域范围内的至少一个未接单车辆时，预设区域范围可以为以弃单车辆为中心的圆形区域，方形区域等，本实施例中对此不作限定。

可以理解的是，若确定出以弃单车辆为中心预设区域范围内没有未接单车辆，则可扩大预设区域范围重新确定出以弃单车辆为中心预设区域范围内的未接单车辆，直到未接单车辆为至少一个为止。

所以本实施例在确定与改派订单相匹配的至少一个第一车辆时，通过获取以弃单车辆位置为中心预设区域范围内的至少一个未接单车辆；将与弃单车辆同类型的未接单车辆确定为第一车辆，不仅能够从第一车辆中选择出的改派车辆快速到达弃单车辆的位置，而且能够使改派车辆尽可能满足用户对初始订单的要求。

206、获取改派车辆信息，并向第一终端设备发送改派车辆信息。

207、实时获取改派车辆的位置信息。

208、将改派车辆的位置信息实时发送给第一终端设备。

在本实施例中，在获取到改派车辆信息后，改派车辆的终端设备可通过gps模块实时获取改派车辆的位置信息并发送给服务器，由服务器将改派车辆的实时位置信息同步给弃单车辆对应的第一终端设备，能够使第一终端设备的司机实时获知改派车辆的位置，在最佳时机与改派车辆司机进行联系和交流，有效防止错过交汇地点。

图3为本发明又一实施例提供的网约车订单处理方法的流程图，如图3所示，本实施例中的应用场景为司机通过第一终端设备抢到初始订单从初始订单的起点行驶到初始订单的终点的过程中，由于车辆出现故障进行网约车订单处理的方法，则该网约车订单处理方法除了执行图2所示实施例的步骤外，在接收第一终端设备发送的订单改派请求后，还执行以下步骤：

301、根据弃单车辆故障信息、弃单车辆位置和初始订单信息生成救援订单。

在本实施例中，在接收第一终端设备发送的订单改派请求中除了包括第一终端设备对应的弃单车辆位置和初始订单外，还包括：改派原因信息。

在本实施例中，改派原因信息为弃单车辆故障信息，所以不仅需要根据弃单车辆位置和初始订单信息生成改派订单，还需要根据弃单车辆故障信息、弃单车辆位置和初始订单信息生成救援订单。

在本实施例中，可获取初始订单中的需要接单车辆的类型，由于初始订单是根据需要接单车辆的类型为用户匹配到的第一终端设备对应的车辆的，所以初始订单中的需要接单车辆的类型即为弃单车辆的类型。并获取弃单车辆故障信息和弃单车辆位置加入到救援订单中，并可为救援订单分配救援订单编号。

可以理解的是，弃单车辆位置作为救援订单的起点位置，弃单车辆故障信息和类型加入到救援订单中，可使服务器为该救援订单获取更加匹配的救援车辆。

302、确定执行救援订单的救援车辆。

作为一种可选实施方式，确定执行救援订单的救援车辆的方法可以为：

3021、确定与救援订单相匹配的至少一个第二车辆。

3022、将改派订单发送给第二车辆对应的第四终端设备。

3023、若最先接收到的第五终端设备发送的救援接单响应，则将第五终端设备对应的第二车辆确定为救援车辆。

可以理解的是，确定执行救援订单的救援车辆的方法与确定执行改派订单的改派车辆的方法类似，在此不再一一赘述。

作为一种可选实施方式，本实施例中，确定与救援订单相匹配的至少一个第二车辆可以为：

首先，获取以弃单车辆位置为中心预设区域范围内的至少一个未接单救援车辆。

其次，将与弃单车辆故障信息和类型相匹配的未接单救援车辆确定为第二车辆。

在本实施例中，可首先采用定位系统获取弃单车辆周围的未接单车辆的位置，确定出以弃单车辆为中心预设区域范围内的未接单车辆，获取各未接单车辆的类型，从中确定出未接单救援车辆。然后根据弃单车辆故障信息和类型确定出相匹配的未接单救援车辆，比如弃单车辆故障信息为爆胎并且未有备胎，类型为小面包车类型，则与弃单车辆故障信息和类型相匹配的未接单救援车辆可以为装载小面包车备胎的救援车辆。又比如弃单车辆故障信息为无法启动，类型为小客车类型，则与弃单车辆故障信息和类型相匹配的未接单救援车辆可以为小客车的拖车。最后将与弃单车辆故障信息和类型相匹配的未接单救援车辆确定为第二车辆。

303、获取救援车辆信息，并向第一终端设备发送救援车辆信息。

在本实施例中，可根据救援车辆的标识信息获取救援车辆信息，救援车辆信息可以包括：救援车辆司机的手机号，救援车辆的车牌号，救援车辆的类型及颜色等。并将救援车辆信息发送给第一终端设备，以使第一终端设备的司机根据救援车辆信息对改派车辆进行识别，并与救援车辆司机主动进行联系。

其中，救援车辆的标识信息可以为改派车辆在服务器中注册的编号，行驶证等唯一标识该改派车辆的信息。

304、实时获取救援车辆的位置信息。

305、将救援车辆的位置信息实时发送给第一终端设备。

在本实施例中，在获取到救援车辆信息后，救援车辆的终端设备可通过gps模块实时获取救援车辆的位置信息并发送给服务器，由服务器将救援车辆的实时位置信息同步给弃单车辆对应的第一终端设备，能够使第一终端设备的司机实时获知救援车辆的位置，在最佳时机与救援车辆司机进行交流，有效防止错过交汇地点。

图4为本发明再一实施例提供的网约车订单处理方法的信令交互图，如图4所示，本实施例中的执行主体为网约车订单处理系统，该网约车订单处理系统包括：第一终端设备，服务器，第三终端设备及第五终端设备，则本实施例提供的网约车订单处理方法包括以下步骤。

401、第一终端设备向服务器发送订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置、改派原因信息和初始订单信息。

其中，改派原因信息为弃单车辆故障信息，其中弃单车辆故障信息可以为无法启动，爆胎，刹车失灵等信息。

402、服务器根据弃单车辆位置和初始订单信息生成改派订单，并根据弃单车辆故障信息、弃单车辆位置和初始订单信息生成救援订单。

在本实施例中，由于弃单车辆正在执行初始订单的过程中，由司机发送订单改派请求，说明该弃单车辆故障不能快速排除，无法将乘客和/或货物顺利送到目的地，为了将乘客和/或货物顺利送到目的地，并且对该弃单车辆进行处理，所以服务器需要为该初始订单生成改派订单和救援订单，改派订单为了派送改派车辆将乘客和/或货物顺利送到初始订单的终点，救援订单是为了派送救援车辆对该故障车辆进行救援。

其中，根据弃单车辆位置和初始订单信息生成改派订单可以参见图2所示实施例中202的说明，根据弃单车辆故障信息、弃单车辆位置和初始订单信息生成救援订单可以参见图3所示实施例中301的说明，本实施例中不再进行赘述。

403、服务器确定执行改派订单的改派车辆和执行救援订单的救援车辆。

其中，服务器确定执行改派订单的改派车辆可以参见图2所示实施例中203-205的说明，服务器确定执行救援订单的救援车辆可以参见图3所示实施例中3021-3023的说明，本实施例中不再进行赘述。

可以理解的是，为了加快确定执行改派订单的改派车辆和执行救援订单的救援车辆，服务器可将确定执行改派订单的改派车辆和确定执行救援订单的救援车辆并行进行。

404、第三终端设备实时向服务器发送改派车辆的位置信息。

405、第五终端设备实时向服务器发送救援车辆的位置信息。

在本实施例中，在第三终端设备和第五终端设备中安装有gps模块，可通过第三终端设备的gps模块对改派车辆的位置进行实时定位，并将改派车辆的实时位置信息发送给服务器。同理，第五终端设备的gps模块对救援车辆的位置信息进行实时定位，并将救援车辆的实时位置信息发送给服务器。

406、服务器将改派车辆的位置信息实时发送给第一终端设备。

407、服务器将救援车辆的位置信息实时发送给第一终端设备。

在本实施例中，为了使第一终端设备的司机能够清楚的区分出改派车辆的实时位置信息及救援车辆的实时位置信息，可在打车应用软件的界面上，以不同的标记或颜色区分改派车辆和救援车辆。如以红色表示改派车辆，以绿色表示救援车辆。

本实施例提供的网约车订单处理方法，服务器能够根据订单改派请求，若订单改派的原因为车辆故障，则服务器能够根据订单改派请求同时生成改派订单和救援订单，并快速确定出改派车辆和救援车辆。不仅能够加快改派订单的执行速度，提高用户网约车体验，而且能够快速对弃单车辆进行救援，防止交通事故的发生。

图5为本发明下一实施例提供的网约车订单处理方法的流程图，如图5所示，本实施例的执行主体为服务器，该网约车订单处理方法在打车应用软件上注册的每个司机终端设备接单前执行。则该网约车订单处理方法包括以下步骤：

501、接收第一终端设备发送的接单开启请求。

在本实施例中，第一终端设备接收用户下达的初始订单前，首先需要将接单状态设置为开启状态才能进行接单，所以通过在打车应用软件的界面上点击开始接单的组件触发接单开启请求，服务器接收第一终端设备的接单开启请求。

可以理解的是，无论是接收用户下达的初始订单，还是弃单车辆的司机触发的改派订单或救援订单，也均需要接收改派订单的第二终端设备或接收救援订单的第四终端设备首先开启接单状态才能进行接单，所以服务器也可接收到第二终端设备或第四终端设备发送的接单开启请求。

502、获取接单开启请求对应车辆的车牌信息和当天车牌限号信息。

为了保障接单车辆都是当天未限号车辆，禁止司机在对应的车辆限号时进行接单，本实施例中，可在接单开启请求中包括车辆标识信息或司机标识信息，根据车辆标识信息或司机标识信息获取对应车辆的车牌信息，并可从第三方平台获取当天车牌限号信息，将需要开启接单的车辆的车牌信息与当天车牌限号信息进行对比，判断该需要开启接单的车辆是否限号。

为了准确地确定需要开启接单的车辆是否限号，作为一种可选实施例，在获取接单开启请求对应车辆的车牌信息时，还获取接单开启请求对应车辆的位置信息，获取该车辆所在的区域范围，在从第三方平台获取当天车牌限号信息时，获取所在区域范围的当天车牌限号信息。并将需要开启接单的车辆的车牌信息与对应区域范围当天车牌限号信息进行对比，判断该需要开启接单的车辆是否限号。

举例说明为：确定需要开启接单的车辆的车牌尾数为“8”,车辆位置所在的区域范围为“北京市西城区”，在从第三方平台获取“北京市西城区”当天车牌限号信息为“限制尾号为4,8车辆禁止进入北京市西城区”，则通过将需要开启接单的车辆的车牌信息与对应区域范围当天车牌限号信息进行对比，确定该需要开启接单的车辆限号。

503、若根据车牌信息和当天车牌限号信息确定对应车辆限号，则向第一终端设备发送禁止接单响应。

在本实施例中，向第一终端设备发送禁止接单响应，可在打车应用程序的界面上显示禁止接单响应的提醒，并可显示禁止接单的原因，如可以为“由于本车辆在该区域今天进行了限号，所以禁止接单”。在向第一终端设备发送禁止接单响应后，服务器可在用户进行下单时，不再向该限号车辆发送订单，该终端设备无法接收到订单。

值得说明的是，若接收第二终端或第四终端发送的接单开启请求，则在根据对应终端的车牌信息和当天车牌限号信息确定对应车辆限号后，也可向第二终端或第四终端发送禁止接单响应。

可以理解的是，若根据车牌信息和当天车牌限号信息确定对应车辆不限号，则对接单开启请求进行接单开启响应，终端设备的状态变为接单开启状态，司机可通过终端设备进行接单。

本实施例提供的网约车订单处理方法，接收第一终端设备发送的接单开启请求；获取接单开启请求对应车辆的车牌信息和当天车牌限号信息；若根据车牌信息和当天车牌限号信息确定对应车辆限号，则向第一终端设备发送禁止接单响应，能够使司机的车辆限号时，禁止司机接单，保证了接单车辆都是未限号车辆，有效防止车辆限号上道，避免违反交通法规。

以下将详细描述本发明的一个或多个实施例的网约车订单处理装置。本领域技术人员可以理解，这些网约车订单处理装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图6为本发明一个实施例提供的网约车订单处理装置的结构示意图，如图6所示，该网约车订单处理装置可以包括：改派请求接收模块11，改派订单生成模块12，改派车辆确定模块13及信息发送模块14。

改派请求接收模块11，用于接收第一终端设备发送的订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置和初始订单信息。

改派订单生成模块12，用于根据弃单车辆位置和初始订单信息生成改派订单。

改派车辆确定模块13，用于确定执行改派订单的改派车辆。

信息发送模块14，用于获取改派车辆信息，并向第一终端设备发送改派车辆信息。

可选地，改派车辆确定模块13具体可以用于：确定与改派订单相匹配的至少一个第一车辆；将改派订单发送给第一车辆对应的第二终端设备；若最先接收到的第三终端设备发送的改派接单响应，则将第三终端设备对应的第一车辆确定为改派车辆。

可选地，改派车辆确定模块13，在确定与改派订单相匹配的至少一个第一车辆时，具体可以用于：获取以弃单车辆位置为中心预设区域范围内的至少一个未接单车辆；将与弃单车辆同类型的未接单车辆确定为第一车辆。

可选地，该网约车订单处理装置还包括：位置获取模块，用于实时获取改派车辆的位置信息。信息发送模块14，还用于将改派车辆的位置信息实时发送给第一终端设备。

可选地，订单改派请求中还包括：改派原因信息；若改派原因信息为弃单车辆故障信息，则该网约车订单处理装置还包括：救援订单生成模块和救援车辆确定模块。

救援订单生成模块，用于根据弃单车辆故障信息、弃单车辆位置和初始订单信息生成救援订单。救援车辆确定模块，用于确定执行救援订单的救援车辆。信息发送模块14，还用于获取救援车辆信息，并向第一终端设备发送救援车辆信息。

可选地，位置获取模块，还用于实时获取救援车辆的位置信息。信息发送模块14，还用于：将救援车辆的位置信息实时发送给第一终端设备。

可选地，该网约车订单处理装置还包括：开启请求接收模块，信息获取模块及禁止接单模块。

开启请求接收模块，用于接收第一终端设备发送的接单开启请求。信息获取模块，用于获取接单开启请求对应车辆的车牌信息和当天车牌限号信息。禁止接单模块，用于若根据车牌信息和当天车牌限号信息确定对应车辆限号，则向第一终端设备发送禁止接单响应。

图6所示网约车订单处理装置可以执行图1-图5所示实施例的方法，详细执行过程可以前述实施例中的描述，在此不再赘述。

在一个可能的设计中，图6所示网约车订单处理装置的结构可实现为一服务器，该服务器可以是包含一独立主机的物理服务器，或者也可以为主机集群承载的虚拟服务器，或者也可以为云服务器等。如图7所示，该服务器可以包括：处理器21和存储器22。其中，存储器22用于存储支持服务器执行上述图1-图5所示实施例中提供的网约车订单处理方法的程序，处理器21被配置为用于执行存储器22中存储的程序。

该程序包括一条或多条计算机指令，其中，一条或多条计算机指令被处理器21执行时能够实现如下步骤：

接收第一终端设备发送的订单改派请求，订单改派请求中包括：第一终端设备对应的弃单车辆位置和初始订单信息。

根据弃单车辆位置和初始订单信息生成改派订单。

确定执行改派订单的改派车辆。

获取改派车辆信息，并向第一终端设备发送改派车辆信息。

可选地，处理器21还用于执行前述图1-图5所示实施例中的全部或部分步骤。

其中，服务器的结构中还可以包括通信接口23，通信接口23用于与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机可读存储介质，用于储存服务器所用的计算机软件指令，其包含用于执行上述图1-图5所示方法实施例中网约车订单处理方法所涉及的程序。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。