基于路顺计划确定运输线路的方法和装置

技术领域

本申请涉及电子商务配送领域，具体而言，涉及一种基于路顺计划确定运输线路的方法和装置、电子设备以及非瞬时性计算机可读存储介质。

背景技术

在电子商务配送领域，干线运输存在距离远、车型大以及运输费用高等特点。对于干线正向运输，由中心仓运输至网格仓，某些场景下会串点多个网格仓。在串点的场景下，存在绕行可能性。例如，当把中心仓串点送货至A和B网格仓时，先送到A网格仓再到B网格仓与先送至B网格仓再到A网格仓相比，后者总里程更加远，则认为后者为绕行。对于绕行场景，运输费用更高。

本方案通过提前识别线路绕行不合理性，通过重新计算线路最优解，进而达到节约成本的目的。

发明内容

本申请旨在提出一种基于路顺计划确定运输线路的方法和装置、电子设备以及非瞬时性计算机可读存储介质，以解决商品在运输过程中，存在的绕行问题。

根据本申请的一方面，提出一种基于路顺计划确定运输线路的方法，包括：A.响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划；以及B.当所述路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划。

根据一些实施例，在响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划之前，所述方法还包括：根据预设的约束条件确定所述路顺计划；响应于用户的调整指令，对所述路顺规划进行调整，以生成调整后的路顺计划；其中，所述预设的约束条件包括货物信息、车辆信息和/或配送点位置。

根据一些实施例，在响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划之前，所述方法还包括：响应于来自用户的路顺计划生成指令，基于临时计划，生成所述路顺计划。

根据一些实施例，评估所述路顺计划是否为最优计划，包括：根据所述路顺计划的运行里程、履约时效和/或所述配送点的断档时间，评估所述路顺计划是否为最优计划。

根据一些实施例，所述方法还包括：将所述最优路顺计划作为提示信息发送至用户，使得所述用户能够按照所述最优路顺计划调整路顺计划，以避免在执行所述路顺计划时绕行。

根据一些实施例，所述方法还包括：若所述路顺计划调整失败，记录调整失败原因，以便于所述路顺计划的后续审计操作。

根据一些实施例，所述方法还包括：若所述路顺计划调整成功，返回执行步骤A。

根据本申请的一方面，提出一种基于路顺计划确定运输线路的装置，包括：评估单元，用于响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划；以及最优路顺计划生成单元，用于当所述路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划。

根据本申请的一方面，提出一种电子设备，包括：处理器；以及存储器，存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行如前任一项所述的方法。

根据本申请的一方面，提出一种非瞬时性计算机可读存储介质，其上存储有计算机可读指令，当所述指令被处理器执行时，使得所述处理器执行如前任一实施例所述的方法。

根据本申请的实施例，通过对路顺计算进行评估，并当路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划，规避了运输员在运输过程中的不合理操作，避免了在将中心仓货物运输至网格仓的干线运输过程中存在的绕行问题，从而节约了运输成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。通过参照附图详细描述其示例实施例，本申请的上述和其他目标、特征及优点将变得更加显而易见。

图1示出了根据本申请示例实施例的一种基于路顺计划确定运输线路的方法流程图。

图2示出了根据本申请示例实施例的一种生成最优路顺计划的过程示意图。

图3示出了根据本申请示例实施例的另一种生成最优路顺计划的过程示意图。

图4示出了根据本申请示例实施例的基于路顺计划确定运输线路的装置框图。

图5示出根据本申请示例性实施例的一种电子设备。

具体实施方式

现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本申请将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图显示表示相同或类似的部分，因而将省略对它们的重复描述。

本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有这些特定细节中的一个或更多，或者可以采用其它的方式、组元、材料、装置或操作等。在这些情况下，将不详细示出或描述公知结构、方法、装置、实现、材料或者操作。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

如前所述，在将中心仓货物运输至网格仓的干线运输过程中，存在距离远、车型大以及运输费用高等特点。而在某些场景下，往往会串行多个网格仓。因此，多个网格仓的配送顺序，将直接影响到整个运输费用。

在一些实际的应用场景中，在系统根据货物的配送量、车辆信息以及配送的网格仓位置生成路顺计划后，配送员往往会根据自己的配送习惯或道路要求等原因对路顺计划进行调整。如果调整后的路顺计划大于调整前的运送里程，或者调整后的路顺计划大于调整前的运送时间，则不仅会影响整个货物的运送时效，而且会带来运送成本的增加。因此，在实际作业时，需要对运输员的路顺计划调整行为进行监管，以避免运输员不合理的调整操作带来的运输费用的增加问题。

根据本申请的实施例，通过对路顺计算进行评估，并当路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划，避免了在将中心仓货物运输至网格仓的干线运输过程中存在的绕行问题，从而节约了运输成本。

根据另一些实施例，路顺计划根据每天的预测货量和车辆信息确定，最优路顺计划根据串行多个网格仓的位置确定。

在描述本申请的实施例之前，首先对本申请中出现的术语进行解释。

中心仓：物流网络仓的根节点，中心仓规模较大，中心仓分拣后，货物被运输至网格仓。

网格仓：网格仓规模小于中心仓，中心仓货物运送至网格仓后，网格仓需要进行二次分拣。

绕行：通过人为干预线路，调整路顺计划，导致司机按照新的线路行进，距离更远。

路顺信息：配送点的配送顺序。例如，若需要将货物从A点，配送至B和C点。B点和C点的配送顺序即为路顺信息。假设配送顺序为A->B->C，此时路顺信息即为A为1，B为2，C为3。

断档时间：配送点的作业空闲时间。例如，在实际作业中，首先，根据配送点的作业习惯和/或配送点的人力配置，计算出配送点的产能；然后，结合需要送至该配送点的货量，计算出该配送点的作业时长。比如，第一车货物在凌晨一点到达该配送点，计算的该配送点的产能是凌晨两点半作业完成，那么该配送站点的断档时间即为凌晨两点半。

串点规则：生成路顺信息时需要遵循的业务规则，例如，业务规则规定站点B的履约时效需要早于站点C，所以生成路顺信息时，需要将站点B的配送时间配置为早于站定C的配送时间。

下面结合附图，对根据本申请的具体实施例进行详细说明。

图1示出了根据本申请示例实施例的一种基于路顺计划确定运输线路的方法流程图，根据本申请的实施例，图1所示的方法应用于在将中心仓的货物运动到多个网格仓的场景。图1所示的方法包括步骤S101和步骤S103。如图1所示，在步骤S101，响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划。

在步骤S101，在评估所述路顺计划是否为最优计划，评估依据包括但不限于根据运行里程、履约时效、配送点的断档时间和/或在包括某些配送点存在固定配送顺序的条件下按照运行里程或运行时间评估所述路顺计划是否为最优计划。

在步骤S103，当所述路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划。

例如，在需要将中心仓的货物运输到配送点A、B、C和D时，且按照ABCD的运输顺序运送时，运输里程最短，则认为按照ABCD的运输顺序为最优的路顺计划。

又例如，在需要将中心仓的货物运输到配送点A、B、C和D时，即使其运输里程最短的顺序为ABCD，但由于需要先配送到网格仓B，然后再配送到配送点A，且BACD的运输里程相较于BADC的运输里程短，因此，最后生成的最优路顺计划为BACD。

根据本申请的实施例，在步骤S103之后，将生成的所述最优路顺计划作为提示信息发送至用户，使得所述用户能够按照所述最优路顺计划调整路顺计划，以避免在执行所述路顺计划时绕行。

在一些实施例，为了保证用户按照生成的最优路顺计划进行调整，还对调整结果进行监控。

例如，若所述路顺计划调整失败，记录调整失败原因，以便于所述路顺计划的后续审计操作，以核实调整失败的原因。

又例如，若所述路顺计划调整成功，则返回执行步骤101。对用户调整后的路顺计划进行进一步评估，以确定用户调整后的路顺计划是否为最优的路顺计划。

根据图1所示的实施例，通过对路顺计算进行评估，并当路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划，规避了运输员在运输过程中的不合理操作，避免了在将中心仓货物运输至网格仓的干线运输过程中存在的绕行问题，从而节约了运输成本。

根据本申请的实施例，在图1所示的步骤S101之前，图1所示的方法还包括根据预设的约束条件确定所述路顺计划。预设的约束条件包括但不限于货物信息、车辆信息和/或配送点位置。生成的路顺计划包括路顺信息和配送站点的配送顺序。

根据一些实施例，货物信息是系统根据每天的成交数据和/商品的物流信息确定。因此，每天的货物运输量会有不同，故需要的运输车辆每天也会变化。

由于车辆信息根据每天的运输任务也会不同，因此，需要综合考虑每天的货物信息、车辆信息和/或配送点位置等信息确定每天的路顺计划。

由于路顺计划是基于系统算法生成的，运输员往往会根据以往的运输经验或者当日的路况信息，对生成的路顺计划进行调整，因此，在根据预设的约束条件确定所述路顺计划后，图1所示的方法还包括并响应于用户的调整指令，对所述路顺规划进行调整，以生成调整后的路顺计划。

图2示出了根据本申请示例实施例的一种生成最优路顺计划的过程示意图，如图2所示，首先系统根据预测货量、车辆信息以及基础资料，采用系统算法生成派车建议。其中，基础资料包括配送点名称、配送点编码、配送点地址和/或经纬度。车辆信息包括车型、车辆牌照、车辆可承载重量和/或车辆尺寸信息。

根据一些实施例，此时生成的派车建议包括路顺信息、串点规则以及分配的运输员司机。

由于生成的路顺信息可能没有参考配送里程、当前路况等信息，导致生成的路顺计划可能不是最优的路顺计划，因此，需要运输员司机对其进行调整。

在运输员司机对生成的派车建议进行调整后，调整后的路顺计划仅是基于运输员司机的运输经验或运输习惯得到的，存在的一定的局限性。因此，调整后的路顺计划可能不是最优的路顺计划。因此，为了对运输员司机的调整行为进行约束或者对调整的路顺计划进行优化，需要对调整后的路顺计划进行评估，以判断其是否最优的路顺计划。

根据一些实施例，评估依据包括但不限于根据运行里程、履约时效、配送点的断档时间和/或在包括某些配送点存在固定配送顺序的条件下按照运行里程或运行时间评估所述路顺计划是否为最优计划。

例如，在需要将中心仓的货物运输到配送点A、B、C和D时，系统算法生成派车建议为ABCD。运输员司机基于以往的运输经验或配送习惯，在将运输顺序调整后ACBD后，需要对调整后的配送顺序进行评估。若调整后ACBD和之前的派送顺序ABCD的运输里程的差值在预设的距离阈值范围内，则采纳该调整建议。否则，提示用户最佳的路顺选择。根据一些实施例，提示信息包括最优的路顺信息以及最佳的路顺信息和运输员司机调整后的路顺信息的距离差异信息，并引导用户按照最佳的路顺信息调整。

为了保证用户按照生成的最优路顺计划进行调整，还需要对调整结果继续进行监控。例如，对用户调整后的派车建议进行进一步评估，以判断是否为最优的路顺计划。

因为最优的路顺计划不一定是可执行的，例如，最优的路顺计划线路上可能存在道路管制。如果仍然按照当前的路顺计划执行，可能会导致履约超时，进而引发客诉舆情。在这种场景下，则允许按照用户选择不按照生成的最优的路顺计划调整。因此，为了应对这种场景，加强整个配送过程的监管，根据本申请的实施例，若调整失败，则需要记录调整失败原因，以便于后续审计，以核实调整失败的原因，从而对运输员司机的调整行为进行监管。

根据本申请的另一些实施例，当现场货量超预期时，例如，预测的货量和实际差距较大，使得实际的运输作业超过预期，则需要用户进行人工干预，新建临时计划。因此，在图1所示的步骤S101之前，图1所示的方法还包括响应于来自用户的路顺计划生成指令，基于临时计划，生成所述路顺计划。

图3示出了根据本申请示例实施例的另一种生成最优路顺计划的过程示意图，如图3所述，调度员根据当前的运输作业状态手动创建临时计划。其中，该临时计划包括路顺信息和运输员司机信息。

由于调度员人工创建的路顺信息可能非最优的路顺信息，且运输员司机信息可能对该路顺信息进行调整。因此，需要对最终调整后的路顺信息进行评估，以判断其是否最优的路顺计划。

如前所述，为了保证用户按照生成的最优路顺计划进行调整，还需要对调整结果进行监控。例如，对用户调整后的派车建议进行进一步评估，以判断是否为最优的路顺计划。若调整失败，则需要记录调整失败原因，以便于后续审计，以核实调整失败的原因，从而对运输员司机的调整行为进行监管。

上面主要从方法的角度对本申请实施例进行了介绍。本领域技术人员应该很容易意识到，结合本文中所公开的实施例所描述的各示例的操作或步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。本领域技术人员可以对每个特定的操作或方法使用不同方式来实现所描述的功能，这种实现不应认为超出本申请的范围。

下面描述本申请的装置实施例。对于本申请装置实施例中未说明的细节，可参照本申请方法实施例。

图4示出了根据本申请示例实施例的基于路顺计划确定运输线路的装置框图，如图4所述的装置包括评估单元401和最优路顺计划生成单元403。其中，评估单元401，用于响应于路顺计划的评估指令，评估所述路顺计划是否为最优计划；以及最优路顺计划生成单元403，用于当所述路顺计划不是最优计划时，基于与所述路顺计划相关联的配送点的位置，生成最优路顺计划。

图5示出根据本申请示例性实施例的一种电子设备。下面参照图5来描述根据本申请的这种实施方式的电子设备200。图5显示的电子设备200仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图5所示，电子设备200以通用计算设备的形式表现。电子设备200的组件可以包括但不限于：至少一个处理单元210、至少一个存储单元220、连接不同系统组件(包括存储单元220和处理单元210)的总线230、显示单元240等。

其中，存储单元存储有程序代码，程序代码可以被处理单元210执行，使得处理单元210执行本说明书描述的根据本申请各种示例性实施方式的方法。例如，处理单元210可以执行如图1中所示的方法。

存储单元220可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)2201和/或高速缓存存储单元2202，还可以进一步包括只读存储单元(ROM)2203。

存储单元220还可以包括具有一组(至少一个)程序模块2205的程序/实用工具2204，这样的程序模块2205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线230可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备200也可以与一个或多个外部设备300(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备200交互的设备通信，和/或与使得该电子设备200能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口250进行。并且，电子设备200还可以通过网络适配器260与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。网络适配器260可以通过总线230与电子设备200的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、或者网络设备等)执行根据本申请实施方式的上述方法。

软件产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该计算机可读介质实现前述功能。

本领域技术人员可以理解上述各模块可以按照实施例的描述分布于装置中，也可以进行相应变化唯一不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

根据本申请的实施例，提出一种计算机程序，包括计算机程序或指令，该计算机程序或指令被处理器执行时，可以执行以上描述的方法。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明仅用于帮助理解本申请的方法及其核心思想。同时，本领域技术人员依据本申请的思想，基于本申请的具体实施方式及应用范围上做出的改变或变形之处，都属于本申请保护的范围。综上所述，本说明书内容不应理解为对本申请的限制。