CN109740842A - 用车管理方法及装置 - Google Patents

Abstract

本申请实施例提供了一种用车管理方法及一种用车管理装置。该方法通过确定用户端对应的至少一个用车订单，并接收所述用户端发送的针对任一用车订单的用车管理请求。基于所述用车管理请求生成用车调度信息。将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。本申请可自动实现用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率。

Description

用车管理方法及装置

技术领域

本发明属于电子技术领域，具体地说，涉及一种用车管理方法及一种用车管理装置。

背景技术

目前，企业与司机达成用车意向后，会根据用车需求生成用车订单。由于企业的用车订单通常具有阶段性，即用车订单实际会根据企业一周、一个月或一季度的用车计划生成。因此，一般是企业自己根据用车订单整理一份用车工作表，该工作表中安排了每个司机对应的配送任务，管理人员将司机的实际配送任务完成情况记录在该用车工作表中，以便于对司机进行管理。

由于实际存在一些不可控因素，例如司机临时无法按照订单完成配送、企业实际用车需求增加或减少或天气原因取消配送任务等，均需要及时进行司机调度或异常记录，以避免不必要的损失。但由于随着司机数量的增加，用车管理难度会越来越大，就需要更多的管理人员参与用车管理，大大增加了企业用车成本。

发明内容

有鉴于此，本发明提供了一种用车管理方法及装置，可以大大提高用车管理的效率，降低企业用车成本。

为了解决上述技术问题，本发明提供了一种用车管理方法，包括：

确定用户端对应的至少一个用车订单；

接收所述用户端发送的针对任一用车订单的用车管理请求；

基于所述用车管理请求生成用车调度信息；

将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

优选地，还包括：

获取任一用车订单对应的司机端的订单配送状态；

判断所述订单配送状态是否存在异常；

如果存在异常，将所述任一用车订单标记为异常用车订单；

接收用户端针对所述异常用车订单查询请求；

将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

优选地，还包括：

接收所述用户端针对所述异常用车订单的异常处理请求；

基于所述异常处理请求进行异常处理并记录异常处理结果；

基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

优选地，接收所述用户端发送的针对任一用车订单的用车管理请求包括：

接收所述用户端针对所述异常用车订单的用车调度请求；

所述基于所述用车管理请求生成用车调度信息包括：

基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机；

基于所述异常用车订单及所述调度司机生成用车调度信息。

优选地，还包括：接收任一司机端发送的针对任一用车订单的审批请求；其中，所述审批请求为所述任一司机端的司机触发生成；发送所述审批请求至所述用户端；

接收所述用户端针对所述审批请求发送的审批结果，并发送所述审批结果至所述任一司机端，以使所述任一司机端的司机根据所述审批结果进行订单配送。

优选地，所述接收用户端发送的针对任一用车订单的用车管理请求包括：

接收用户端根据用车需求增加发送的针对所述任一用车订单对应的至少一个司机的用车订单增加请求。

优选地，所述基于所述用车管理请求生成用车调度信息包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单增加请求，生成针对所述任一用车订单对应的至少一个司机的加跑用车订单；

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送包括：

将所述加跑用车订单发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述加跑用车订单进行订单配送。

优选地，所述接收用户端发送的针对任一用车订单的用车管理请求包括：

接收用户端根据用车需求减少发送的针对所述任一用车订单对应的至少一个司机的用车订单取消请求。

优选地，所述基于所述用车管理请求生成用车调度信息包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单取消请求，生成针对所述任一用车订单对应的至少一个司机的不出车提示信息；

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送包括：

将所述不出车提示信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述不出车提示信息停止相应单配送。

优选地，所述订单配送状态包括：到仓状态、到仓时间、配送完成时间及配送路线中的一个或多个。

优选地，所述判断所述订单配送状态是否存在异常包括：

根据到仓状态及到仓时间判断所述任一用车订单对应的司机端的司机是否存在迟到或旷工。

优选地，所述判断所述订单配送状态是否存在异常包括：

根据到仓时间、所述配送完成时间及配送路线判断所述任一用车订单对应的司机端的司机是否存在误工。

本申请还提供了一种用车管理装置，包括：

确定模块，用于确定用户端对应的至少一个用车订单；

第一接收模块，用于接收用户端发送的针对任一用车订单的用车管理请求；

用车调度信息生成模块，用于基于所述用车管理请求生成用车调度信息；

第一发送模块，用于将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

优选地，还包括：

第二获取模块，用于获取任一用车订单对应的司机端的订单配送状态；

判断模块，用于判断所述订单配送状态是否存在异常；

异常标记模块，用于如果存在异常，将所述任一用车订单标记为异常用车订单；

第二接收模块，用于接收用户端针对所述异常用车订单查询请求；

第二发送模块，用于将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

优选地，还包括：

第三接收模块，用于接收所述用户端针对所述异常用车订单的异常处理请求；

异常处理模块，用于基于所述异常处理请求进行异常处理并记录异常处理结果；

结算模块，用于基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

优选地，还包括：

所述第一接收模块具体用于，接收所述用户端针对所述异常用车订单的用车调度请求；

所述用车调度信息生成模块具体用于：

基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机；

调度用车订单生成模块用于，基于所述异常用车订单及所述调度司机生成调度用车调度信息。

与现有技术相比，本发明可以获得包括以下技术效果：

本发明提供了一种用车管理方法及一种用车管理装置，该方法通过接收用户端发送的针对任一用车订单的用车管理请求并基于所述用车管理请求生成用车调度信息。将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。可以及时将用车调度信息及时通知到司机，使得司机按照用车调度信息进行订单配送，从而可自动实现用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的一种用车管理方法的一个实施例的流程图；

图2是本发明实施例的一种用车管理方法的又一个实施例的流程图；

图3是本发明实施例的一种用车管理装置的一个实施例的结构示意图；

图4是本发明实施例的一种用车管理装置的又一个实施例的结构示意图。

具体实施方式

以下将配合附图及实施例来详细说明本发明的实施方式，藉此对本发明如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

在本申请的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

下面将结合附图对本申请技术方案进行详细描述。

图1是本发明实施例的一种用车管理方法的一个实施例的流程图。该方法可以包括：

101：确定用户端对应的至少一个用车订单。

可选地，用车订单为用户根据计划用车需求通过用车招标与中标司机生成的用车订单。实际应用中，如果用户是通过用车招标平台进行用车招标后自动生成的用车订单，则服务端可通过用车招标平台直接获取该用户对应的用车订单。如果用户通过人工用车招标，需要通过签订合同方式生成用车订单，则需要工作人员将用车订单输入至服务端。该用车订单发送至服务端后由服务器将该用车订单分别发送至用户端及司机端进行显示。当然服务端还可通过其他方式确定用户端对应的用车订单，具体可根据实际情况进行设定在此不做具体限定。

可以理解的是，用户端及司机端可以是分别安装有用户端的用车管理应用程序及司机端的用车管理应用程序的智能终端。例如手机、计算机、平板电脑等智能设备，在此不做具体限定。

实际应用中，用户通过一次用车招标可对应生成一个用车订单，如果用户发起多次用车招标，则会对应每一次用车招标分别生成一个用车订单。可选地，该用车订单可以包括至少一个用车子订单，其中，每一个用车子订单对应一个司机生成。因此，服务端在确定用户端对应的至少一个用车订单后会将该至少一个用车订单显示在用户端，用户通过用户端可以通过项目编号或者日期等查找获得。而服务端发送至司机端的用车订单实际为其对应的用着订单中的至少一个用车子订单。司机通过司机端可根据用户名称，时间、项目名称等查找相应的用车子订单。

例如，在企业用户一次用车招标中，需要15个司机进行配送服务，且每个司机的服务天数为一周，每天配送两次，时间为从2018年12月7日起至2018年12月13日止。实际生成的用车子订单可根据司机的服务次数生成，例如任一个司机需要每天配送两次，连续配送七天，则可针对每一个司机生成14个用车子订单，即一个用车订单包含210个用车子订单。也可以按照服务天数生成用车子订单，即按照服务天数7天，对应每个司机生成7个用车子订单。实际用车子订单的生成方式可根据实际情况进行设定，且根据不同每个用车子订单的生成方式匹配相应每个用车子订单的价格结算方式。

102：接收用户端发送的针对任一用车订单的用车管理请求。

可以理解的是，用车订单中包括但不限于每一个中标司机的服务时间、服务天数、服务价格、是否提供搬运、是否到仓等。由于该用车订单是按照计划用车需求进行设定的，因此可能会由于外界天气原因、司机个人原因、用户原因等用车计划临时取消或发生变更，就需要及时进行协调。因此，当用户需要对用车订单及司机进行调度和管理可通过用户端生成用车订单管理请求与司机端的司机进行协调。

103：基于所述用车管理请求生成用车调度信息。

服务端接收到用户端发送的用车管理请求后，根据用车管理请求确定该用车管理请求对应的至少一个司机端，并对应至少一个司机端生成用车调度信息分别发送至相应的司机端。

104：将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

可选地，在某些实施例中，所述接收用户端发送的针对任一用车订单的用车管理请求可以包括：

接收用户端根据用车需求增加发送的针对所述任一用车订单对应的至少一个司机的用车订单增加请求。

如果用户任一用车订单用车需求比预设计划用车需求增多，且增加较少时可申请通过增加已中标司机配送次数或根据已中标司机实际运力增加配送重量或件数等方式进行协调和调度。

可选地，用户端可通过查询已中标司机的运力，确定运力较大的司机，并发送针对确定的运力较大司机生成用车订单增加请求，服务端根据用车订单增加请求生成用车订单增加调度信息，并将该用车订单增加调度信息发送至相应的司机端。

可选地，实际用户生成用车订单增加请求之前还可以预先与已中标的司机或与已中标的司机中确定的运力较大司机进行预先协商，这一协商过程可以由管理人员预先与司机进行协商沟通，或生成加单协调信息由服务端发送至每个待协商的司机端，司机端的司机根据自身情况确认是否同意该加单协调信息，如果同意则发送确认信息至用户端，用户端根据接收到的确认信息，生成针对每一个确认信息对应的用车订单增加请求。

可选地，在某些实施例中，所述基于所述用车管理请求生成用车调度信息可以包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单增加请求，生成针对所述任一用车订单对应的至少一个司机的加跑用车订单；

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送包括：

将所述加跑用车订单发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述加跑用车订单进行订单配送。

实际该加跑订单中还可以包括加跑信息，该加跑信息可以包括司机的服务价格，并说明加跑配送的方式，是增加配送次数还是增加配送运力等，如果是增加配送次数，还需要标明增加配送的时间，从而使得该至少一个司机端的司机可以按照加跑订单中的加跑信息执行配送服务。同时加跑信息中还可以包括协定好的服务价格，使得司机在完成加跑订单后按照定好的服务价格进行价格结算。

可选地，在某些实施例中，所述接收用户端发送的针对任一用车订单的用车管理请求可以包括：

接收用户端根据用车需求减少发送的针对所述任一用车订单对应的至少一个司机的用车订单取消请求。

可选地，在某些实施例中，所述基于所述用车管理请求生成用车调度信息可以包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单取消请求，生成针对所述任一用车订单对应的至少一个司机的不出车提示信息。

用户可能由于项目取消、时间变更、天气、节假日等原因取消至少一个用车订单。可以理解的是，用户可以根据自身情况直接取消包含多个用车子订单的任一个用车订单，也可以取消任一个用车订单中的至少一个用车子订单。可选地，用户可以通过用户端针对需要取消用车订单对应的司机端生成用车订单取消请求，并生成不出车提示信息提醒司机该用车订单已取消，不需要出车。实际操作中，企业用户可以按照签订的服务协议中规定的违约金额或赔偿金额对该取消订单的司机进行赔偿，如果没有相应规定，则需要与司机预先进行协商，并将协商结果增加到不出车提示信息中。

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送可以包括：

将所述不出车提示信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述不出车提示信息停止相应配送。

实际上，用户或司机均可以提出用车管理请求，同样地，司机端的司机如果存在任何情况无法按照用车订单约定时间进行配送服务可以发出针对任一用车订单的审批请求，通过审批请求与用户进行用车调度协商。

可选地，在某些实施例中，还可以包括：接收任一司机端发送的针对任一用车订单的审批请求；其中，所述审批请求为所述任一司机端的司机触发生成。

发送所述审批请求至所述用户端。

接收所述用户端针对所述审批请求发送的审批结果，并发送所述审批结果至所述任一司机端，以使所述任一司机端的司机根据所述审批结果进行订单配送。

该审批请求可以是，无法按照任一用车订单约定时间到仓的告假请求，车辆故障需要进行用车协调导致实际司机运力增加或减少，生成的用车订单增加请求或用车订单减少请求等，具体可根据实际需求进行设定，在此不做具体限定。

司机在司机端生成的针对任一用车订单的审批请求，可以是针对任一用车订单的用车订单增加请求，也可以是针对司机端对应的至少一个用车子订单的告假、调度请求等。用户端在接收到司机端针对任一用车订单发送的审批请求后，进行审批并发送审批结果至服务端，由服务端将审批结果发送至司机端。

可以理解的是，如果司机发送的审批请求为用车订单增加请求，则用户在存在用车订单增加需求的时候优先考虑该司机。如果是告假请求可根据约定协议，在对该司机对应的订单进行结算是扣除相应的误工费用。当然还可以使申请调度请求，例如该司机的用车订单的服务时间为周四，司机如果周四无法完成配送服务可以优先申请调度请求，即请求用户根据用车订单将其他司机与该司机进行换班，但如果换班未成功，则在考虑进一步发送订单取消请求，请求用户进行审批。

实际应用中，如果用户端接收到司机端发送的针对任一用车订单的审批请求后，根据审批请求的内容及审批结果判断是否需要对该用车订单进行调度和管理，如果需要则可根据实际需求生成针对任一用车订单的用车管理请求并发送至服务端，由服务端基于所述用车管理请求生成用车调度信息；将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

本申请实施例中，通过接收用户端发送的针对任一用车订单的用车管理请求并基于所述用车管理请求生成用车调度信息。将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。可以及时将用车调度信息及时通知到司机，使得司机按照用车调度信息进行订单配送，此外，司机也可以通过司机端发送针对任一用车订单的审批请求至服务端，有服务端将该审批请求发送至用户端进行审批。用户端将审批结果发送至司机端，从而可自动实现企业用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率。

图2是本发明实施例的一种用车管理方法的另一个实施例的流程图。该方法可以包括：

201：确定用户端对应的至少一个用车订单。

202：获取任一用车订单对应的司机端的订单配送状态。

可选地，在某些实施例中，所述订单配送状态可以包括：到仓状态、到仓时间、配送完成时间及配送路线中的一个或多个。

一方面司机可以自主输入订单配送状态，也可以司机端通过GPS定位等定位装置或者用户触发生成订单配送状态。例如，任一用车订单要求司机到仓取货，因此可以在司机到达预定仓库所在地后，生成已到仓配送状态信息。该已到仓配送状态信息可以通过司机触发司机端生成，也可以是司机端中定位装置检测当前位置为预定仓库位置时生成，也可以是用户根据实际司机到仓时间通过用户端生成该司机的已到仓配送状态信息，并发送至服务端。

可以理解的是，到仓时间可以是将生成已到仓配送状态信息的时间作为到仓时间，也可以是在生成到仓配送状态信息的同时输入到仓时间信息。

实际司机在按照任一用车订单在进行配送服务端过程中，司机端会通过定位装置记录司机的配送路线，并根据司机的到仓时间及配送完成时间记录司机的总服务时间。

203：判断所述订单配送状态是否存在异常。

204：如果存在异常，将所述任一用车订单标记为异常用车订单。

可选地，在某些实施例中，所述判断所述订单配送状态是否存在异常包括：

根据到仓状态及到仓时间判断所述任一用车订单对应的司机端的司机是否存在迟到或旷工。

可选地，在某些实施例中，所述判断所述订单配送状态是否存在异常包括：

根据到仓时间、所述配送完成时间及配送路线判断所述任一用车订单对应的司机端的司机是否存在误工。

服务端会及时获取任一用车订单对应的司机端的订单配送状态，根据是否到仓、到仓时间、配送完成时间及配送路线中的一个或多个状态信息，判断是否存在异常用车订单。例如司机未在规定时间内到仓，出现迟到或无故旷工等异常情况；或司机未按照规定配送路线进行配送、或配送完成时间超过规定的完成时间。例如，应该在两个小时完成配送，司机用了四个小时造成拖延误工。异常用车订单包括但不限于上述任一异常情况，且只要存在任一中异常情况即可标记为异常用车订单。

205：接收用户端针对所述异常用车订单查询请求。

用户可以通过用户端随时查看任一用车订单的订单配送状态，并可通过生成异常用车订单查询请求查询存在异常的用车订单。

206：将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

服务端根据异常用车订单查询请求，将异常用车订单发送至用户端进行显示并根据实时监控信息，更新异常用车订单列表。

可选地，在某些实施例中，还可以包括：

接收所述用户端针对所述异常用车订单的异常处理请求；

基于所述异常处理请求进行异常处理并记录异常处理结果；

基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

当用户查询异常用车订单是由于，天气原因、道路施工原因或其他因素引起，可将该异常用车订单进行异常处理，即通过协调、调度并未引起客户损失，无需追究司机责任。如果该异常用车订单经用户调查是由于司机个人原因出现迟到、旷工、拖延工时等异常情况时，特别是造成用户出现损失，则需要再对司机进行订单结算时扣除相应的误工费用或财产随时费用。

207：接收所述用户端针对所述异常用车订单的用车调度请求。

可以理解的是，在对出现配送状态异常的司机进行惩罚的同时，另一方面用户还可以对异常用车订单进行用车调度，例如确定调度司机替代无故旷工的司机，或者是通过加跑减少由于拖延或迟到造成的时间损失。

208：基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机。

因此，用户端可以生成针对任一异常用车订单的调度请求，服务端可根据实际情况调配确定调度司机，也可以根据用户要求协调用户中意的调度司机。

209：基于所述异常用车订单及所述调度司机生成调度用车信息。

如果司机出现迟到、旷工、拖延工时等情况时可以生成针对异常用车订单以及调度司机生成加跑用车订单信息，或生成针对调度司机的调度用车订单信息由调度司机完成或协助完成该用车订单对应的配送服务。

210：将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

服务端将生成的针对调度司机的加跑用车订单或者调度用车订单发送至该调度司机对应的司机端，及时通知调度司机执行配送服务。可以理解的是，用车调度信息中还可以包含价格信息，在调度司机完成配送服务后按照设定的价格信息进行订单结算。

本身请实施实例中，通过对任一用车订单的订单配送状态进行监测可以及时获得该任一用车订单的订单配送状态，并根据订单配送状态判断该任一用车订单是否存在异常。如果存在异常则对该任一用车订单进行异常标记，标记为异常用车订单。用户可以通过用户端查询异常用车订单，并对异常用车订单进行调度和管理以保证配送任务的正常完成，同时对于造成该任一用车订单异常的司机进行异常处理，例如可以停止该司机之后的用车订单的配送服务，或对该司机按照协议规定进行惩罚措施等。服务端可以根据用户的用车调度请求，确定调度司机，并生成对应该调度司机的用车调度信息，该调度司机可以是一个或多个在此不做具体限定。使得调度司机按照用车调度信息进行订单配送，从而可自动实现企业用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率，进一步降低用户的损失。

图3是本发明实施例的一种用车管理装置的一个实施例的结构示意图。该装置可以包括：

确定模块301，用于确定用户端对应的至少一个用车订单。

可选地，用车订单为用户根据计划用车需求通过用车招标与中标司机生成的用车订单。实际应用中，如果用户是通过用车招标平台进行用车招标后自动生成的用车订单，则服务端可通过用车招标平台直接获取该用户对应的用车订单。如果用户通过人工用车招标，需要通过签订合同方式生成用车订单，则需要工作人员将用车订单输入至服务端。该用车订单发送至服务端后由服务器将该用车订单分别发送至用户端及司机端进行显示。当然服务端还可通过其他方式确定用户端对应的用车订单，具体可根据实际情况进行设定在此不做具体限定。

实际应用中，用户通过一次用车招标可对应生成一个用车订单，如果用户发起多次用车招标，则会对应每一次用车招标分别生成一个用车订单。可选地，该用车订单可以包括至少一个用车子订单，其中，每一个用车子订单对应一个司机生成。因此，服务端在确定用户端对应的至少一个用车订单后会将该至少一个用车订单显示在用户端，用户通过用户端可以通过项目编号或者日期等查找获得。而服务端发送至司机端的用车订单实际为其对应的用着订单中的至少一个用车子订单。司机通过司机端可根据用户名称，时间、项目名称等查找相应的用车子订单。

例如，在企业用户一次用车招标中，需要15个司机进行配送服务，且每个司机的服务天数为一周，每天配送两次，时间为从2018年12月7日起至2018年12月13日止。实际生成的用车子订单可根据司机的服务次数生成，例如任一个司机需要每天配送两次，连续配送七天，则可针对每一个司机生成14个用车子订单，即一个用车订单包含210个用车子订单。也可以按照服务天数生成用车子订单，即按照服务天数7天，对应每个司机生成7个用车子订单。实际用车子订单的生成方式可根据实际情况进行设定，且根据不同每个用车子订单的生成方式匹配相应每个用车子订单的价格结算方式。

第一接收模块302，用于接收用户端发送的针对任一用车订单的用车管理请求。

可以理解的是，用车订单中包括但不限于每一个中标司机的服务时间、服务天数、服务价格、是否提供搬运、是否到仓等。由于该用车订单是按照计划用车需求进行设定的，因此可能会由于外界天气原因、司机个人原因、用户原因等用车计划临时取消或发生变更，就需要及时进行协调。因此，当用户需要对用车订单及司机进行调度和管理可通过用户端生成用车订单管理请求与司机端的司机进行协调。

用车调度信息生成模块303，用于基于所述用车管理请求生成用车调度信息。

服务端接收到用户端发送的用车管理请求后，根据用车管理请求确定该用车管理请求对应的至少一个司机端，并对应至少一个司机端生成用车调度信息分别发送至相应的司机端。

第一发送模块304，用于将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

可选地，在某些实施例中，所述第一接收模块302具体可以用于：

接收用户端根据用车需求增加发送的针对所述任一用车订单对应的至少一个司机的用车订单增加请求。

如果用户任一用车订单用车需求比预设计划用车需求增多，且增加较少时可申请通过增加已中标司机配送次数或根据已中标司机实际运力增加配送重量或件数等方式进行协调和调度。

可选地，用户端可通过查询已中标司机的运力，确定运力较大的司机，并发送针对确定的运力较大司机生成用车订单增加请求，服务端根据用车订单增加请求生成用车订单增加调度信息，并将该用车订单增加调度信息发送至相应的司机端。

可选地，实际用户生成用车订单增加请求之前还可以预先与已中标的司机或与已中标的司机中确定的运力较大司机进行预先协商，这一协商过程可以由管理人员预先与司机进行协商沟通，或生成加单协调信息由服务端发送至每个待协商的司机端，司机端的司机根据自身情况确认是否同意该加单协调信息，如果同意则发送确认信息至用户端，用户端根据接收到的确认信息，生成针对每一个确认信息对应的用车订单增加请求。

可选地，在某些实施例中，所述用车调度信息生成模块303，具体可以用于：

根据所述任一用车订单对应的至少一个司机及所述用车订单增加请求，生成针对所述任一用车订单对应的至少一个司机的加跑用车订单。

所述第一发送模块304，具体可以用于：

将所述加跑用车订单发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述加跑用车订单进行订单配送。

实际该加跑订单中还可以包括加跑信息，该加跑信息可以包括司机的服务价格，并说明加跑配送的方式，是增加配送次数还是增加配送运力等，如果是增加配送次数，还需要标明增加配送的时间，从而使得该至少一个司机端的司机可以按照加跑订单中的加跑信息执行配送服务。同时加跑信息中还可以包括协定好的服务价格，使得司机在完成加跑订单后按照定好的服务价格进行价格结算。

可选地，在某些实施例中，所述第一接收模块302具体可以用于：

接收用户端根据用车需求减少发送的针对所述任一用车订单对应的至少一个司机的用车订单取消请求。

可选地，在某些实施例中，所述用车调度信息生成模块303具体可以用于：

根据所述任一用车订单对应的至少一个司机及所述用车订单取消请求，生成针对所述任一用车订单对应的至少一个司机的不出车提示信息。

用户可能由于项目取消、时间变更、天气、节假日等原因取消至少一个用车订单。可以理解的是，用户可以根据自身情况直接取消包含多个用车子订单的任一个用车订单，也可以取消任一个用车订单中的至少一个用车子订单。可选地，用户可以通过用户端针对需要取消用车订单对应的司机端生成用车订单取消请求，并生成不出车提示信息提醒司机该用车订单已取消，不需要出车。实际操作中，企业用户可以按照签订的服务协议中规定的违约金额或赔偿金额对该取消订单的司机进行赔偿，如果没有相应规定，则需要与司机预先进行协商，并将协商结果增加到不出车提示信息中。

所第一发送模块304，具体可以用于：

将所述不出车提示信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述不出车提示信息停止相应配送。

实际上，用户或司机均可以提出用车管理请求，同样地，司机端的司机如果存在任何情况无法按照用车订单约定时间进行配送服务可以发出针对任一用车订单的审批请求，通过审批请求与用户进行用车调度协商。

可选地，在某些实施例中，还可以包括：

审批请求接收模块，用于接收任一司机端发送的针对任一用车订单的审批请求；其中，所述审批请求为所述任一司机端的司机触发生成。

审批请求发送模块，用于发送所述审批请求至所述用户端。

审批结果接收模块，用于接收所述用户端针对所述审批请求发送的审批结果，并发送所述审批结果至所述任一司机端，以使所述任一司机端的司机根据所述审批结果进行订单配送。

该审批请求可以是，无法按照任一用车订单约定时间到仓的告假请求，车辆故障需要进行用车协调导致实际司机运力增加或减少，生成的用车订单增加请求或用车订单减少请求等，具体可根据实际需求进行设定，在此不做具体限定。

司机在司机端生成的针对任一用车订单的审批请求，可以是针对任一用车订单的用车订单增加请求，也可以是针对司机端对应的至少一个用车子订单的告假、调度请求等。用户端在接收到司机端针对任一用车订单发送的审批请求后，进行审批并发送审批结果至服务端，由服务端将审批结果发送至司机端。

可以理解的是，如果司机发送的审批请求为用车订单增加请求，则用户在存在用车订单增加需求的时候优先考虑该司机。如果是告假请求可根据约定协议，在对该司机对应的订单进行结算是扣除相应的误工费用。当然还可以使申请调度请求，例如该司机的用车订单的服务时间为周四，司机如果周四无法完成配送服务可以优先申请调度请求，即请求用户根据用车订单将其他司机与该司机进行换班，但如果换班未成功，则在考虑进一步发送订单取消请求，请求用户进行审批。

实际应用中，如果用户端接收到司机端发送的针对任一用车订单的审批请求后，根据审批请求的内容及审批结果判断是否需要对该用车订单进行调度和管理，如果需要则可根据实际需求生成针对任一用车订单的用车管理请求并发送至服务端，由服务端基于所述用车管理请求生成用车调度信息；将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

本申请实施例中，通过接收用户端发送的针对任一用车订单的用车管理请求并基于所述用车管理请求生成用车调度信息。将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。可以及时将用车调度信息及时通知到司机，使得司机按照用车调度信息进行订单配送，此外，司机也可以通过司机端发送针对任一用车订单的审批请求至服务端，有服务端将该审批请求发送至用户端进行审批。用户端将审批结果发送至司机端，从而可自动实现企业用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率。

图4是本发明实施例的一种用车管理装置的另一个实施例的结构示意图。该装置可以包括：

确定模块401，用于确定用户端对应的至少一个用车订单。

第二获取模块402，用于获取任一用车订单对应的司机端的订单配送状态。

可选地，在某些实施例中，所述订单配送状态可以包括：到仓状态、到仓时间、配送完成时间及配送路线中的一个或多个。

一方面司机可以自主输入订单配送状态，另一方面也可以司机端通过GPS定位等定位装置或者用户触发生成订单配送状态。例如，任一用车订单要求司机到仓取货，因此可以在司机到达预定仓库所在地后，生成已到仓配送状态信息。该已到仓配送状态信息可以通过司机触发司机端生成，也可以是司机端中定位装置检测当前位置为预定仓库位置时生成，也可以是用户根据实际司机到仓时间通过用户端生成该司机的已到仓配送状态信息，并发送至服务端。

可以理解的是，到仓时间可以是将生成已到仓配送状态信息的时间作为到仓时间，也可以是在生成到仓配送状态信息的同时输入到仓时间信息。

实际司机在按照任一用车订单在进行配送服务端过程中，司机端会通过定位装置记录司机的配送路线，并根据司机的到仓时间及配送完成时间记录司机的总服务时间。

判断模块403，用于判断所述订单配送状态是否存在异常。

异常标记模块404，用于如果存在异常，将所述任一用车订单标记为异常用车订单。

可选地，在某些实施例中，所述判断模块403具体可以用于：

根据到仓状态及到仓时间判断所述任一用车订单对应的司机端的司机是否存在迟到或旷工。

可选地，在某些实施例中，所述判断模块403具体可以用于：

根据到仓时间、所述配送完成时间及配送路线判断所述任一用车订单对应的司机端的司机是否存在误工。

服务端会及时获取任一用车订单对应的司机端的订单配送状态，根据是否到仓、到仓时间、配送完成时间及配送路线中的一个或多个状态信息，判断是否存在异常用车订单。例如司机未在规定时间内到仓，出现迟到或无故旷工等异常情况；或司机未按照规定配送路线进行配送、或配送完成时间超过规定的完成时间。例如，应该在两个小时完成配送，司机用了四个小时造成拖延误工。异常用车订单包括但不限于上述任一异常情况，且只要存在任一中异常情况即可标记为异常用车订单。

第二接收模块405，用于接收用户端针对所述异常用车订单查询请求。

用户可以通过用户端随时查看任一用车订单的订单配送状态，并可通过生成异常用车订单查询请求查询存在异常的用车订单。

第二发送模块406，用于将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

服务端根据异常用车订单查询请求，将异常用车订单发送至用户端进行显示并根据实时监控信息，更新异常用车订单列表。

可选地，在某些实施例中，还可以包括：

第三接收模块，用于接收所述用户端针对所述异常用车订单的异常处理请求。

异常处理模块，用于基于所述异常处理请求进行异常处理并记录异常处理结果。

结算模块，用于基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

当用户查询异常用车订单是由于，天气原因、道路施工原因或其他因素引起，可将该异常用车订单进行异常处理，即通过协调、调度并未引起客户损失，无需追究司机责任。如果该异常用车订单经用户调查是由于司机个人原因出现迟到、旷工、拖延工时等异常情况时，特别是造成用户出现损失，则需要再对司机进行订单结算时扣除相应的误工费用或财产随时费用。

第一接收模块407，用于接收所述用户端针对所述异常用车订单的用车调度请求。

可以理解的是，在对出现配送状态异常的司机进行惩罚的同时，另一方面用户还可以对异常用车订单进行用车调度，例如确定调度司机替代无故旷工的司机，或者是通过加跑减少由于拖延或迟到造成的时间损失。

用车调度信息生成模块408，用于基于所述用车管理请求生成用车调度信息。

所述用车调度信息生成模块408，可以包括：

调度司机确定单元411，用于基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机。

因此，用户端可以生成针对任一异常用车订单的调度请求，服务端可根据实际情况调配确定调度司机，也可以根据用户要求协调用户中意的调度司机。

用车调度信息生成单元412，用于基于所述异常用车订单及所述调度司机生成调度用车信息。

如果司机出现迟到、旷工、拖延工时等情况时可以生成针对异常用车订单以及调度司机生成加跑用车订单信息，或生成针对调度司机的调度用车订单信息由调度司机完成或协助完成该用车订单对应的配送服务。

第一发送模块409，用于将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

服务端将生成的针对调度司机的加跑用车订单或者调度用车订单发送至该调度司机对应的司机端，及时通知调度司机执行配送服务。可以理解的是，用车调度信息中还可以包含价格信息，在调度司机完成配送服务后按照设定的价格信息进行订单结算。

本身请实施实例中，通过对任一用车订单的订单配送状态进行监测可以及时获得该任一用车订单的订单配送状态，并根据订单配送状态判断该任一用车订单是否存在异常。如果存在异常则对该任一用车订单进行异常标记，标记为异常用车订单。用户可以通过用户端查询异常用车订单，并对异常用车订单进行调度和管理以保证配送任务的正常完成，同时对于造成该任一用车订单异常的司机进行异常处理，例如可以停止该司机之后的用车订单的配送服务，或对该司机按照协议规定进行惩罚措施等。服务端可以根据用户的用车调度请求，确定调度司机，并生成对应该调度司机的用车调度信息，该调度司机可以是一个或多个在此不做具体限定。使得调度司机按照用车调度信息进行订单配送，从而可自动实现企业用户对每一个用车订单对应的司机的调度和管理，大大提高了管理效率，进一步降低用户的损失。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决技术问题，基本达到技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表第一装置可直接电性耦接于第二装置，或通过其他装置或耦接手段间接地电性耦接至第二装置。说明书后续描述为实施本发明的较佳实施方式，然描述乃以说明本发明的一般原则为目的，并非用以限定本发明的范围。本发明的保护范围当视所附权利要求所界定者为准。

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

上述说明示出并描述了本发明的若干优选实施例，但如前，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims (16)

1.一种用车管理方法，其特征在于，包括：

确定用户端对应的至少一个用车订单；

接收所述用户端发送的针对任一用车订单的用车管理请求；

基于所述用车管理请求生成用车调度信息；

将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

2.根据权利要求1所述的方法，其特征在于，还包括：

获取任一用车订单对应的司机端的订单配送状态；

判断所述订单配送状态是否存在异常；

如果存在异常，将所述任一用车订单标记为异常用车订单；

接收用户端针对所述异常用车订单查询请求；

将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

3.根据权利要求2所述的方法，其特征在于，还包括：

接收所述用户端针对所述异常用车订单的异常处理请求；

基于所述异常处理请求进行异常处理并记录异常处理结果；

基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

4.根据权利要求2所述的方法，其特征在于，接收所述用户端发送的针对任一用车订单的用车管理请求包括：

接收所述用户端针对所述异常用车订单的用车调度请求；

所述基于所述用车管理请求生成用车调度信息包括：

基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机；

基于所述异常用车订单及所述调度司机生成用车调度信息。

5.根据权利要求1所述的方法，其特征在于，还包括：接收任一司机端发送的针对任一用车订单的审批请求；其中，所述审批请求为所述任一司机端的司机触发生成；发送所述审批请求至所述用户端；

接收所述用户端针对所述审批请求发送的审批结果，并发送所述审批结果至所述任一司机端，以使所述任一司机端的司机根据所述审批结果进行订单配送。

6.根据权利要求1所述的方法，其特征在于，所述接收用户端发送的针对任一用车订单的用车管理请求包括：

接收用户端根据用车需求增加发送的针对所述任一用车订单对应的至少一个司机的用车订单增加请求。

7.根据权利要求6所述的方法，其特征在于，所述基于所述用车管理请求生成用车调度信息包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单增加请求，生成针对所述任一用车订单对应的至少一个司机的加跑用车订单；

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送包括：

将所述加跑用车订单发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述加跑用车订单进行订单配送。

8.根据权利要求1所述的方法，其特征在于，所述接收用户端发送的针对任一用车订单的用车管理请求包括：

接收用户端根据用车需求减少发送的针对所述任一用车订单对应的至少一个司机的用车订单取消请求。

9.根据权利要求8所述的方法，其特征在于，所述基于所述用车管理请求生成用车调度信息包括：

根据所述任一用车订单对应的至少一个司机及所述用车订单取消请求，生成针对所述任一用车订单对应的至少一个司机的不出车提示信息；

所述将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送包括：

将所述不出车提示信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述不出车提示信息停止相应单配送。

10.根据权利要求2所述的方法，其特征在于，所述订单配送状态包括：到仓状态、到仓时间、配送完成时间及配送路线中的一个或多个。

11.根据权利要求10所述的方法，其特征在于，所述判断所述订单配送状态是否存在异常包括：

根据到仓状态及到仓时间判断所述任一用车订单对应的司机端的司机是否存在迟到或旷工。

12.根据权利要求10所述的方法，其特征在于，所述判断所述订单配送状态是否存在异常包括：

根据到仓时间、所述配送完成时间及配送路线判断所述任一用车订单对应的司机端的司机是否存在误工。

13.一种用车管理装置，其特征在于，包括：

确定模块，用于确定用户端对应的至少一个用车订单；

第一接收模块，用于接收用户端发送的针对任一用车订单的用车管理请求；

用车调度信息生成模块，用于基于所述用车管理请求生成用车调度信息；

第一发送模块，用于将所述用车调度信息发送至所述任一用车订单对应的至少一个司机端，以使所述至少一个司机端的司机按照所述用车调度信息进行订单配送。

14.根据权利要求13所述的装置，其特征在于，还包括：

第二获取模块，用于获取任一用车订单对应的司机端的订单配送状态；

判断模块，用于判断所述订单配送状态是否存在异常；

异常标记模块，用于如果存在异常，将所述任一用车订单标记为异常用车订单；

第二接收模块，用于接收用户端针对所述异常用车订单查询请求；

第二发送模块，用于将所述异常用车订单发送至所述用户端，以在所述用户端进行显示。

15.根据权利要求14所述的装置，其特征在于，还包括：

第三接收模块，用于接收所述用户端针对所述异常用车订单的异常处理请求；

异常处理模块，用于基于所述异常处理请求进行异常处理并记录异常处理结果；

结算模块，用于基于所述异常处理结果对任一用车订单对应的司机端进行订单结算。

16.根据权利要求14所述的方法，其特征在于，还包括：

所述第一接收模块具体用于，接收所述用户端针对所述异常用车订单的用车调度请求；

所述用车调度信息生成模块具体用于：

基于所述用车调度请求，确定与所述异常用车订单匹配的调度司机；

调度用车订单生成模块用于，基于所述异常用车订单及所述调度司机生成调度用车调度信息。