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

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.本技术提供的方案针对待派发的用车订单，根据该用车订单圈定候选司机端以作
备选；其次确定该用车订单中指定用车车型的当前运力信息，若该当前运力信息表征该用车车型的当前运力不足时，也即无法将该用车订单派发给本车车型与用车车型一致的司机端时，将该用车车型调整为目标车型，该目标车型的级别可以高于用车车型，也可以低于用车车型，相当于将用车订单进行升舱处理或降舱处理；接着，从候选司机端中选择最终派单的目标司机端，该司机端的接单车型包括了目标车型，该目标车型可以是该目标司机端对应的本车车型，也可以是除了本车车型之外的其他接单车型，相当于该目标司机端可以承接未指定本车车型的用车订单。本技术提供的方案通过在用车车型运力不足时，根据调整后的用车车型以及司机端的多个接单车型，为用户匹配到合适的目标司机端，能够提升用车订单的接单率和成单率，以及提高了各类车型资源的利用率，增大了运力效益。
39.本技术的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
40.为了更清楚地说明本技术实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
41.图1是本技术实施例提供的一种用车订单处理方法的实施环境示意图；
42.图2是本技术实施例提供的一种用车订单处理方法的流程示意图；
43.图3是本技术实施例提供的一种确定候选司机端的流程示意图；
44.图4是本技术实施例提供的一种确定用车车型当前运力信息的流程示意图；
45.图5是本技术实施例提供的一种将用车车型调整为目标车型的流程示意图；
46.图6是本技术实施例提供的一种确定目标司机端的流程示意图；
47.图7是本技术实施例提供的一种下探策略的配置示意图；
48.图8是本技术实施例提供的一种基于司机端配置接单配置信息的流程示意图；
49.图9是本技术实施例提供的另一种确定目标司机端的流程示意图；
50.图10是本技术实施例提供的一种具体应用场景下的的流程示意图；
51.图11是本技术实施例提供的一种用车订单处理装置的示意图；
52.图12是本技术实施例提供的用于实现一种用车订单处理方法的设备的硬件结构示意图。
具体实施方式
53.为了提高用车订单的接单率和车型资源的利用率，本技术实施例提供了一种用车订单处理方法、装置、介质及设备。下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。
54.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
55.请参阅图1，其为本技术实施例提供的一种用车订单处理方法的实施环境示意图，如图1所示，该实施环境可以至少包括客户端10、司机端20和服务器30。
56.具体的，所述客户端10可以包括智能手机、台式电脑、平板电脑、笔记本电脑、车载终端、数字助理、智能可穿戴设备、监控设备及语音交互设备等类型的设备，也可以包括运行于设备中的软体，例如一些服务商提供给用户的网页页面，也可以为该些服务商提供给用户的应用。具体的，所述客户端10可以用于生成并提交包含用车车型的用车订单至所述服务器30。
57.具体的，所述司机端20可以是车辆，也可以是智能手机、台式电脑、平板电脑、笔记本电脑、车载终端、数字助理、智能可穿戴设备、监控设备及语音交互设备等类型的设备，还可以包括运行于设备中的软体，例如一些服务商提供给用户的网页页面，也可以为该些服务商提供给用户的应用。具体的，所述司机端20可以用于接收所述服务器30派发的用车订单。
58.具体的，所述服务器30可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(content deliverynetwork，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。所述服务器30可以包括有网络通信单元、处理器和存储器等等。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术在此不做限制。具体的，所述服务器30可以用于在用车订单中指定的用车车型运力不足时，为该用车订单匹配合适的目标司机端，满足该用车订单的用车需求。
59.本技术实施例还可以结合云技术实现，云技术(cloud technology)是指在广域网或局域网内将硬件、软件及网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，也可理解为基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术及应用技术等的总称。云技术需要以云计算作为支撑。云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。具体地，所述服务器30和数据库位于云端，所述服务器30可以是实体机器，也可以是虚拟化机器。
60.以下介绍本技术提供的一种用车订单处理方法。图2是本技术实施例提供的一种用车订单处理方法的流程图，本技术提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处
理器或者多线程处理的环境)。请参照图2，本技术实施例提供的一种用车订单处理方法可以包括如下步骤：
61.s210：获取用户的用车订单，所述用车订单的订单信息至少包括用车车型。
62.在本技术实施例中，用户可以通过终端中的应用程序创建用车订单并将该用车订单提交至系统或平台，以使系统或平台根据用户订单为用户选择合适的司机端，并将该用车订单派发给该司机端，从而满足用户的用车需求以及为司机创收。
63.在本技术实施例中，该用车订单的订单信息至少包括用车车型，用车车型即用户所能接受的接单车辆的车型。一般的，系统或平台会根据用户所选择的用车车型将该用车订单派送给本车车型与用车车型一致的司机端，但在上下班高峰期期间，这种一致性的要求容易造成部分车型的运力紧张，无法满足暴增的用车需求，故本技术实施例针对该问题提出了一种改进的用户订单处理方法。
64.可选的，订单信息还可以包括但不限于订单类型(如实时单、预约单等)、上车点、途经点、下车点、预约出发时间、乘坐人数或是否携带有大件行李等。
65.s230：根据所述用车订单确定候选司机端。
66.在本技术实施例中，可以根据该用车订单中的订单信息进行初步的筛选，确定候选司机端。常见的，可以根据用户与司机端的相对距离、上车点与司机端的相对距离、用车订单的订单类型与司机端的接单类型等条件进行初步的筛选，本技术实施例对此不作限定。
67.在一种可行的实施方式中，如图3所示，步骤s230可以包括以下步骤：
68.s231：根据所述用车订单的订单类型和订单起点信息，确定处于预设范围内的候选司机端。
69.s233：根据白名单和报点信息，对所述候选司机端进行过滤，得到过滤后的候选司机端。
70.具体地，基于订单类型(如实时单、预约单)和以订单起点为中心确定的预设派单范围，圈定该派单范围内已上线、处于空闲状态或支持接力单的司机。示例性的，如果用车订单为实时单，则确定出的候选司机满足以下条件：当前处于接单时段、允许接实时单(也即具有实时单接单意愿)、历史上报的经纬度处于该派单范围内、司机所处的城市区域与订单一致等；如果用车订单为预约单，则确定出的候选司机满足以下条件：允许接预约单、司机城市与订单城市一致等。
71.具体地，根据白名单和报点信息再对候选司机端进行过滤，如可以根据用户的手机号判断该用户是否处于白名单，若该用户为白名单用户，则将候选司机端中非白名单实际剔除。
72.具体地，根据司机端上报的点位，对候选司机端进行过滤，示例性的，将最近一次的点位上报时间在用车订单创建的90秒之前的候选司机端剔除。
73.可以理解的是，可以根据具体的业务形态和业务需求圈定候选司机端，本技术实施例对具体的筛选条件不作限定。
74.s250：确定所述用车车型对应的当前运力信息。
75.在本技术实施例中，运力信息可以表征车型运力的紧张程度，进一步地可以指示车型接单率的高低。如，当运力信息表示该车型运力紧张，或称运力不足时，则可以理解为
当前该车型的接单率已到达上限，该车型的车辆无法满足当前的订单需求；当运力信息表示该车型运力宽松，或称运力充裕时，则可以理解为当前有较多该车型的车辆处于空闲状态，造成了资源浪费的情况。
76.在本技术的一个实施例中，可以根据当前各车型的接单率确定各车型的当前运力信息。具体的，如图4所示，所述确定所述用车车型对应的当前运力信息，可以包括以下步骤：
77.s251：获取针对所述用车车型预设的接单率上限阈值。
78.在本技术的一个实施例中，针对网约车的业务场景，在后台可以预先设置各车型的接单率上限阈值，接单率上限阈值可以根据城市、网约车数量、车型、分包商类型、订单类型、时段等因素适应业务需求而设置，此处不做赘述。
79.在本技术的另一个实施例中，还可以预先设置各车型的接单率下限阈值，理论上，接单率下限阈值小于接单率上限阈值。
80.在本技术的一个实施例中，车型的接单率上限阈值可以控制该车型的用车订单是否允许车型升舱或车型降舱，车型的接单率下限阈值可以控制司机端的接单车型是否允许向上接单或向下接单。
81.s253：确定在所述用户所在城市内所述用车车型对应的当前接单率。
82.在一种可行的实施方式中，通过大数据计算实时统计当前城市所有车型的接单率和成单率。
83.s255：将所述接单率上限阈值与所述当前接单率进行比较，得到所述用车车型对应的当前运力信息。
84.其中，若所述当前的接单率超过所述接单率上限阈值时，则所述当前运力信息表征所述用车车型的运力不足。
85.其中，若所述当前的接单率低于所述接单率下限阈值时，则所述当前运力信息表征所述用车车型的运力过余。
86.s270：在所述当前运力信息表征所述用车车型的运力不足时，确定候选的目标车型；所述目标车型的级别不同于所述用车车型。
87.在本技术实施例中，对于用户(也即乘客端)，在用车订单所指定的用车车型运力不足时，当前没有本车车型为该用车车型的车辆可以接单，无法满足该用户的用车需求。此时，后台可以将用车车型进行扩展，对用车车型进行车型升舱或车型降舱，故作为候选的目标车型的级别可以高于用车车型，也可以低于用车车型。
88.示例性的，当前有四种车型，等级从低到高分别为a、b、c和d，当车型a的当前接单率高于配置的车型a的接单率上限阈值时，则车型a开启升舱，也即，可以将用车车型为车型a的用车订单派送给本车车型为b、c或d的司机端。相应的，司机端也应被允许接收用车车型不为本车车型的用车订单，当车型d的当前接单率低于车型d对应的接单率下限阈值，则车型d的车辆开启下探，能够接到低等级车型的用车订单。
89.在本技术的一个实施例，对用车车型的升级或降级可以根据预先设置的调整策略确定。具体地，如图5所示，步骤s270可以包括以下步骤：
90.s271：根据所述用车订单的订单类型或业务类型，确定匹配的调整策略。
91.s273：基于所述调整策略，确定候选的目标车型，所述目标车型的级别高于或低于
所述用车车型。
92.在一种可行的实施方式中，可以根据订单类型和业务线进行预先的配置，配置后在处理用户订单时后台根据不同条件生效调整策略，如根据实时订单、预约订单、专车订单、企业订单等设置订单用车车型的调整策略，如是车型升级或是车型降级、车型级别跨度等。
93.在另一种可行的实施方式中，当该车型的当前运力不足时，首先在用户端提示用户是否需要进行车型升级或降级，在用户许可之后，再生效对应的车型调整策略。
94.s290：从所述候选司机端中，确定接单车型包括所述目标车型的目标司机端，并将所述用车订单分配给所述目标司机端；所述目标司机端的接单车型不限于所述目标司机端的本车车型。
95.在本技术实施例中，确定了候选的目标车型后，根据目标车型开始聚合叫车，可以将派单范围扩大至更多级别的车辆，能够提升用户的接单率，提高乘客满意度，也能够有效缓解原始的用车车型运力紧张的情况，减少车型资源不平衡的现象，使各车型的运力效益最大化。
96.在本技术实施例中，目标车型可以是目标司机端的本车车型，还可以是除了本车车型之外的其他可接单车型。故，相应地，司机端可以开启接单车型扩展功能，如司机端的本车车型对应的接单率低于接单率下限阈值时，司机端可以将接单车型进行扩展，不限于本车车型，还可以包括比本车车型级别高的车型，也可以是比本车车型级别低的车型。
97.在本技术的一个实施例中，可以根据司机端所开启的接单车型扩展配置来进一步筛选。具体的，如图6所示，步骤s290可以包括以下步骤：
98.s291：确定所述候选司机端中各司机端的接单配置信息，所述接单配置信息包含所述候选司机端对应的接单车型。
99.在一种可行的实施方式中，在步骤s210之前，后台预先配置车型与接单率上下限阈值的对应关系，以及司机端的车型调整策略。具体地，如图7所示，可以支持业务人员基于不同分包商的运力情况，决定分包商运力调整策略，在实际配置中，业务人员可根据城市、适用分包商、车辆类型、司机意愿、可服务类型、生效时间、生效周期等条件细化不同城市、车型等条件的运力调整策略。同时，司机在司机端可以根据自主意愿进行调整设置，如服务车型(本车车型)为高级别车型的司机，可配置是否愿意接用车车型为低级别车型的订单。
100.示例性，如图8所示，在司机端，根据其对应的分包商初始化运力调整策略，再根据司机的个人意愿进行个性化配置。当司机端拉取的运力调整策略为强制调整时，则司机在司机端上线以后强制执行所设置的多种接单车型的用车订单；当司机端拉取的运力调整策略为自由选择是否调整但不可自主设置接单车型时，则司机可以在司机端开启车型调整开关，若关闭，则还是接收用车车型为本车车型的订单；当司机端拉取运力调整策略为自选类型(自由开闭且可选类型)时，则司机可以在司机端进行开关设置，并可以自主选择调整后的接单车型。
101.s293：当所述目标车型的级别高于所述用车车型时，基于所述接单配置信息从所述候选司机端中确定所述目标司机端，所述目标司机端对应的接单车型至少包括所述本车车型和第一候选车型，所述第一候选车型的级别低于所述本车车型；所述目标车型为所述本车车型或所述第一候选车型。
102.在一种具体的实施例中，设有三种车型，等级从低到高分别为a、b、c，设有一用车订单中指定的用车车型为a但车型a当前的运力不足而车型b和c当前的运力充裕或过余时，升级该用车车型为目标车型b；本车车型为车型b的司机端和本车车型为车型c的司机端分别扩展了接单车型，车型b的司机端的接单车型包括车型a和车型b，车型c的司机端的接单车型包括车型a、车型b和车型c，则对于用车车型升级为了目标车型b的这一用车订单，既可以分配给本车车型为车型b的司机端，也可以分配给本车车型为车型c的司机端。
103.s295：当所述目标车型的级别低于所述用车车型时，基于所述接单配置信息从所述候选司机端中确定所述目标司机端，所述目标司机端对应的接单车型至少包括所述本车车型和第二候选车型，所述第二候选车型的级别高于所述本车车型；所述目标车型为所述本车车型或所述第二候选车型。
104.对于目标车型的级别低于该用车车型的情况，可以参考上述实施例中的实施思路同理可得，此处不再赘述。
105.进一步地，如图9所示，步骤s290还可以包括以下步骤：
106.s297：确定所述候选司机端中各司机端与所述用户的相对距离。
107.s299：基于所述接单配置信息和所述相对距离，从所述候选司机端中确定所述目标司机端，所述目标司机端与所述用户的相对距离满足预设派单距离条件。
108.具体地，对于将用车车型调整为目标车型的用车订单，进行聚合叫车派单，从候选司机端中筛选出接单车型包括该目标车型的一个或多个，并根据派单范围和司机端的意愿选取合适的作为目标司机端。
109.在一个具体实施场景中，如图10所示，响应于乘客端下单操作，后台的订单模块轮询获取用车订单，根据用车订单中用车车型的接单率是否达到上限阈值，判断是否命中升舱策略，也即对用车车型进行升级；若否，则将该用车订单派送给本车车型为用车车型的司机；若命中了升舱策略，则进一步判断候选司机端是否开启了司机下探策略，也即将接单车型扩展为低于本车车型，若是，则根据调整后的用车车型和接单车型，派送该乘客的用车订单，将原本是低车型的用车订单派送给高车型的司机。
110.在本技术实施例中，首先针对待派发的用车订单，根据该用车订单圈定候选司机端以作备选；其次确定该用车订单中指定用车车型的当前运力信息，若该当前运力信息表征该用车车型的当前运力不足时，也即无法将该用车订单派发给本车车型与用车车型一致的司机端时，将该用车车型调整为目标车型，该目标车型的级别可以高于用车车型，也可以低于用车车型，相当于将用车订单进行升舱处理或降舱处理；接着，从候选司机端中选择最终派单的目标司机端，该司机端的接单车型包括了目标车型，该目标车型可以是该目标司机端对应的本车车型，也可以是除了本车车型之外的其他接单车型，相当于该目标司机端可以承接未指定本车车型的用车订单。本技术提供的方案通过在用车车型运力不足时，根据调整后的用车车型以及司机端的多个接单车型，为用户匹配到合适的目标司机端，能够提升用车订单的接单率和成单率，以及提高了各类车型资源的利用率，增大了运力效益。
111.本技术实施例还提供了一种用车订单处理装置1100，如图11所示，所述装置1100可以包括：
112.用车订单获取模块1110，用于获取用户的用车订单，所述用车订单的订单信息至少包括用车车型；
113.候选司机端确定模块1120，用于根据所述用车订单确定候选司机端；
114.车型运力信息确定模块1130，用于确定所述用车车型对应的当前运力信息；
115.用车车型调整模块1140，用于在所述当前运力信息表征所述用车车型的运力不足时，确定候选的目标车型；所述目标车型的级别不同于所述用车车型；
116.用车订单分配模块1150，用于从所述候选司机端中，确定接单车型包括所述目标车型的目标司机端，并将所述用车订单分配给所述目标司机端；所述目标司机端的接单车型不限于所述目标司机端的本车车型。
117.在本技术的一个实施例中，所述车型运力信息确定模块1130可以包括：
118.阈值获取单元，用于获取针对所述用车车型预设的接单率上限阈值；
119.当前接单率确定单元，用于确定在所述用户所在城市内所述用车车型对应的当前接单率；
120.比较单元，用于将所述接单率上限阈值与所述当前接单率进行比较，得到所述用车车型对应的当前运力信息。
121.其中，若所述当前的接单率超过所述接单率上限阈值时，则所述当前运力信息表征所述用车车型的运力不足。
122.在本技术的一个实施例中，所述用车车型调整模块1140可以包括：
123.策略匹配单元，用于根据所述用车订单的订单类型或业务类型，确定匹配的调整策略；
124.目标车型确定单元，用于基于所述调整策略，确定候选的目标车型，所述目标车型的级别高于或低于所述用车车型。
125.在本技术的一个实施例中，所述候选司机端确定模块1120可以包括：
126.司机端圈定单元，用于根据所述用车订单的订单类型和订单起点信息，确定处于预设范围内的候选司机端；
127.司机端过滤单元，用于根据白名单和报点信息，对所述候选司机端进行过滤，得到过滤后的候选司机端。
128.在本技术的一个实施例中，所述用车订单分配模块1150可以包括：
129.接单配置信息确定单元，用于确定所述候选司机端中各司机端的接单配置信息，所述接单配置信息包含所述候选司机端对应的接单车型；
130.目标司机端第一确定单元，用于当所述目标车型的级别高于所述用车车型时，基于所述接单配置信息从所述候选司机端中确定所述目标司机端，所述目标司机端对应的接单车型至少包括所述本车车型和第一候选车型，所述第一候选车型的级别低于所述本车车型；所述目标车型为所述本车车型或所述第一候选车型
131.目标司机端第二确定单元，用于当所述目标车型的级别低于所述用车车型时，基于所述接单配置信息从所述候选司机端中确定所述目标司机端，所述目标司机端对应的接单车型至少包括所述本车车型和第二候选车型，所述第二候选车型的级别高于所述本车车型；所述目标车型为所述本车车型或所述第二候选车型。
132.在本技术的一个实施例中，所述用车订单分配模块1150还可以包括：
133.相对距离确定单元，用于确定所述候选司机端中各司机端与所述用户的相对距离；
134.目标司机端第三确定单元，用于基于所述接单配置信息和所述相对距离，从所述候选司机端中确定所述目标司机端，所述目标司机端与所述用户的相对距离满足预设派单距离条件。
135.需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
136.本技术实施例提供了一种计算机设备，该计算机设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的一种用车订单处理方法。
137.图12示出了一种用于实现本技术实施例所提供的一种用车订单处理方法的设备的硬件结构示意图，所述设备可以参与构成或包含本技术实施例所提供的装置或系统。如图12所示，设备10可以包括一个或多个(图中采用1002a、1002b，
……
，1002n来示出)处理器1002(处理器1002可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器1004、以及用于通信功能的传输装置1006。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图12所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图12中所示更多或者更少的组件，或者具有与图12所示不同的配置。
138.应当注意到的是上述一个或多个处理器1002和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
139.存储器1004可用于存储应用软件的软件程序以及模块，如本技术实施例中所述的方法对应的程序指令/数据存储装置，处理器1002通过运行存储在存储器1004内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种用车订单处理方法。存储器1004可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1004可进一步包括相对于处理器1002远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
140.传输装置1006用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置1006包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置1006可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
141.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。
142.本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质可设置于服务器之中以保存用于实现方法实施例中一种用车订单处理方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的一种用车订单处理方法。
143.可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，randomaccess memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
144.本发明实施例还提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施方式中提供的一种用车订单处理方法。
145.由上述本技术提供的一种用车订单处理方法、装置、介质及设备的实施例可见，
146.本技术提供的方案针对待派发的用车订单，根据该用车订单圈定候选司机端以作备选；其次确定该用车订单中指定用车车型的当前运力信息，若该当前运力信息表征该用车车型的当前运力不足时，也即无法将该用车订单派发给本车车型与用车车型一致的司机端时，将该用车车型调整为目标车型，该目标车型的级别可以高于用车车型，也可以低于用车车型，相当于将用车订单进行升舱处理或降舱处理；接着，从候选司机端中选择最终派单的目标司机端，该司机端的接单车型包括了目标车型，该目标车型可以是该目标司机端对应的本车车型，也可以是除了本车车型之外的其他接单车型，相当于该目标司机端可以承接未指定本车车型的用车订单。本技术提供的方案通过在用车车型运力不足时，根据调整后的用车车型以及司机端的多个接单车型，为用户匹配到合适的目标司机端，能够提升用车订单的接单率和成单率，以及提高了各类车型资源的利用率，增大了运力效益。
147.需要说明的是：上述本技术实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
148.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
149.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
150.以上所述仅为本技术的较佳实施例，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。