界面显示方法、配送订单分配方法和装置与流程

文档序号:11459116阅读:185来源:国知局
界面显示方法、配送订单分配方法和装置与流程

本发明涉及互联网技术领域,尤其涉及一种界面显示方法、配送订单分配方法和装置。



背景技术:

随着互联网技术的快速发展,基于互联网的应用越来越多,例如外卖类应用、购物类应用。基于这些应用,用户足不出户即可获取自己所需的物品。这些应用在便利用户的同时,也面临着物品配送问题,于是物流调度系统应运而生。物流调度系统的主要任务是将配送订单分配给合适的配送人员。

目前的物流调度策略是:物流调度系统预先将配送人员按照所属商圈进行了固定划分,配送人员只能被动地接受物流调度系统分配给其的所属商圈内的配送订单。



技术实现要素:

现有物流调度策略下,配送人员只能根据物流调度系统的分配,配送分配给自己的、属于归属商圈内的配送订单。这可能导致的问题包括:从配送人员角度,如果其所属的商圈内配送订单量较少,将很可能导致该配送人员运力闲置,配送体验较差;从整体物流调度系统角度,很有可能此时其他商圈的配送订单量过多,其他商圈处于供需不平衡的状态,此时该商圈内运力资源的闲置与其他商圈内运力资源的不足使得整体运力资源的利用率不高,等等。

由于现有配送人员的被动接单的调度方式,在实际应用中出现各种各样的弊端,为此,发明人尝试转变物流调度思路,变被动为主动,即使得配送人员由被动接单的状态转为主动发现订单的状态。

为了让配送人员能够主动决策自己去往哪个商圈区域,需要提供给配送人员决策所需的参考信息,因此,本发明实施例中通过以各商圈对应的订单量信息作为一种参考信息提供给配送人员,以供配送人员据此主动地决策前往的配送区域。

基于上述实现原理,第一方面,本发明实施例提供一种界面显示方法,包括:

在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素;

响应于对具有不同的所述配送订单量信息的配送区域的选择,在选择的配送区域中定位配送人员节点。

可选地,所述界面元素包括:表征订单压力程度的第一界面元素,和/或表征订单量分布状况的第二界面元素。

相应地,本发明实施例还提供一种界面显示装置,包括:

显示模块,用于在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素;

定位模块,用于响应于对具有不同的所述配送订单量信息的配送区域的选择,在选择的配送区域中定位配送人员节点。

本发明实施例提供的界面显示方法和装置,在配送人员的客户端中,以订单热力图的方式,显示多个配送区域对应的反映配送订单量信息的界面元素,从而使得配送人员能够基于该反应不同配送区域各自对应的配送订单量信息的界面元素,直观而全面地了解多个配送区域的订单量情况,从而能够方便地主动做出想要去往哪个配送区域的选择决策,提高配送人员的配送灵活性。

第二方面,本发明实施例提供一种配送订单处理方法,实现于服务器侧,包括:

获取多个配送区域各自的配送订单量信息;

将所述多个配送区域各自的配送订单量信息发送至客户端。

可选地,所述配送订单量信息中包括订单压力程度,以及,所述配送订单量信息的获取步骤包括:

根据所述多个配送区域各自的未完成配送订单量,确定所述多个配送区域各自的订单压力;

根据所述多个配送区域各自的订单压力与压力程度阈值的比较结果,确定所述多个配送区域各自的订单压力程度。

可选地于,所述配送订单量信息中包括订单量分布状况,以及,所述配送订单量信息的获取步骤包括:

统计所述多个配送区域各自对应的所有服务提供方在预设历史时间段内分别对应的日平均订单量;

根据所述日平均订单量,确定所述多个配送区域各自的订单量分布状况。

对应地,本发明实施例还提供一种配送订单处理装置,包括:

获取模块,用于获取多个配送区域各自的配送订单量信息;

发送模块,用于将所述多个配送区域各自的配送订单量信息发送至客户端。

本发明实施例提供的配送订单处理方法和装置,服务器可以基于一定的主动的推送策略或者基于客户端的请求,而获取多个配送区域各自的配送订单量信息,进而将获得的多个配送区域各自的配送订单量信息发送至客户端,以供客户端在界面上比如以订单热力图的方式显示该多个配送区域各自的配送订单量信息,以便于配送人员基于该多个配送区域各自的配送订单量信息,自主选择去往哪个配送区域承接配送订单,有助于提高配送人员的配送体验,提高其完成的配送订单量,也有助于充分利用配送人员的配送运力,保证配送订单的配送效率、准时率。

第三方面,本发明实施例提供另一种配送订单处理方法,实现于服务器侧,包括:

获取配送区域内的待分配订单组;

从所述配送区域内的至少一个配送人员中选择已有配送订单与所述待分配订单组之间满足订单聚合条件的配送人员;

将所述待分配订单组分配给选择出的配送人员。

可选地,所述方法还包括:

若选择出多个配送人员,则根据所述多个配送人员分别满足所述订单聚合条件的程度,从所述多个配送人员中选择出目标配送人员;

以及,所述待分配订单组的分配步骤包括:

将所述待分配订单组分配给所述目标配送人员。对应地,本发明实施例还提供另一种配送订单处理装置,包括:

获取模块,用于获取配送区域内的待分配订单组;

选择模块,用于从所述配送区域内的至少一个配送人员中选择已有配送订单与所述待分配订单组之间满足订单聚合条件的配送人员;

分配模块,用于将所述待分配订单组分配给选择出的配送人员。

本发明实施例提供的配送订单处理方法和装置,针对某配送区域内的任一待分配订单组来说,在为其分配对应的配送人员时,基于该配送区域内的各配送人员的已有配送订单与待分配订单组之间的订单聚合程度来选择配送人员,即从各配送人员中选择已有配送订单与该待分配订单组之间满足订单聚合条件的配送人员。不同于现有技术中仅依据配送人员与待分配订单组的匹配程度来选择配送人员,本方案中,还进一步结合配送人员已有配送订单与待分配订单组的聚合程度来选择配送人员,以进一步提高配送人员承接的配送订单的配送效率。

附图说明

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

图1为本发明实施例提供的界面显示方法实施例一的流程图;

图1a-图1c为图1所示实施例中一种订单热力图显示过程的界面示意图;

图2为本发明实施例提供的界面显示方法实施例二的流程图;

图2a为图2所示实施例对应的一种未完成订单的展示界面示意图;

图2b为图2所示实施例对应的另一种未完成订单的展示界面示意图;

图3为本发明实施例提供的配送订单处理方法实施例一的流程图;

图3a为图3所示实施例中步骤301的一种可选实现方式的流程图;

图3b为图3所示实施例中步骤301的另一种可选实现方式的流程图;

图4为本发明实施例提供的配送订单处理方法实施例二的流程图;

图5为本发明实施例提供的配送订单处理方法实施例三的流程图;

图6为本发明实施例提供的界面显示装置实施例一的结构示意图;

图7为本发明实施例提供的配送订单处理装置实施例一的结构示意图;

图8为本发明实施例提供的配送订单处理装置实施例二的结构示意图。

具体实施方式

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

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

应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。

应当理解,尽管在本发明实施例中可能采用术语第一、第二、第三等来描述xxx,但这些xxx不应限于这些术语。这些术语仅用来将xxx彼此区分开。例如,在不脱离本发明实施例范围的情况下,第一xxx也可以被称为第二xxx,类似地,第二xxx也可以被称为第一xxx。

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

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

图1为本发明实施例提供的界面显示方法实施例一的流程图,本实施例提供的该界面显示方法可以由一界面显示装置来执行,该界面显示装置可以实现为软件,或者实现为软件和硬件的组合,该界面显示装置可以集成设置在用户的终端设备中,比如智能手机、平板电脑等,该用户是指配送人员。如图1所示,该方法包括如下步骤:

步骤101、在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素。

步骤102、响应于对具有不同的所述配送订单量信息的配送区域的选择,在选择的配送区域中定位配送人员节点。

在物流配送的一种场景中,比如同城配送场景,对一个城市划分为若干配送区域(在某些实际应用场景中,也称为商圈),从而,基于配送区域进行配送订单的调度管理。具体来说,配送人员在初始时,被基于其经常的活动区域而被固定划分到某个配送区域中,称为其归属配送区域,从而,后续负责配送其归属配送区域对应的配送订单。其中,该归属配送区域对应的配送订单,一般是指配送订单的发货方地址位于该归属配送区域内的配送订单。因为一般来说,一个配送订单具有发货地址和收获地址两个地址,这两个地址可能位于同一配送区域内,也可能位于不同的配送区域内,一般以发货方地址所位于的配送区域来确定该配送订单所对应的是哪个配送区域。

本实施例中,可选地,上述步骤101中的多个配送区域可以是某城市的全部或部分配送区域。在一种可选方式中,服务器可以主动向各客户端发送上述多个配送区域各自对应的配送订单量信息,在另一种可选方式中,服务器可以基于客户端的请求,而向该客户端发送多个配送区域各自对应的配送订单量信息。

举例来说,比如针对某个客户端来说,可以在该客户端被配送人员开启时,服务器主动向客户端发送多个配送区域的配送订单量信息。再比如,客户端基于配送人员在界面中的对某个控件的触发,而请求服务器发送该多个配送区域的配送订单量信息。

一般来说,针对任一配送人员,考虑到该配送人员可能更加关注于其附近的几个配送区域的配送订单量情况,因为更远的配送区域需要花费更多的时间前往,而且该配送人员往往对更远的配送区域熟悉度比较低,不便于进行配送订单的高效配送,因此,上述多个配送订单主要是配送人员附近的几个配送区域。

因此,服务器可以基于从客户端获得的配送人员的当前位置,来确定该配送人员当前所处的第一配送区域,以及与该第一配送区域临近的至少一个第二配送区域作为上述多个配送区域。

其中,配送人员的当前位置可以基于配送人员的终端设备中的定位装置来确定,客户端被开启时,可以将该位置信息发送至服务器,以使得服务根据该位置信息确定上述多个配送区域,或者,客户端在基于配送人员的触发而向服务器请求获得多个配送区域的配送订单量信息时,将配送人员的位置信息携带于请求消息中发至服务器,以使得服务根据该位置信息确定上述多个配送区域。服务器在确定上述多个配送区域后,分别获得上述多个配送区域各自对应的配送订单量信息,并下发至客户端。其中,配送订单量信息的获取过程将在后续实施例中说明,本实施例中仅说明,客户端可以通过服务器获取多个配送区域各自对应的配送订单量信息。

本实施例中,当客户端接收到服务器发送的多个配送区域各自的配送订单量信息后,可以以订单热力图的方式显示这些配送订单量信息。具体地,客户端可以在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素。

本实施例中,订单热力图的含义可以理解为是以热力图的方式显示订单信息,该订单信息主要是指配送订单量信息。热力图的显示方式,比如是以特殊高亮的方式显示多个配送区域的配送订单量信息,也就是说,针对各配送区域的配送订单量信息的不同,以不同的颜色高亮显示各配送区域所对应的配送订单量信息,比如对于订单量大于一定数量阈值的配送区域,以蓝色高亮的方式显示,对于订单量小于一定数量阈值的配送区域,以绿色高亮的方式显示,从而,上述界面元素可以是不同的颜色。

基于上述的介绍,上述多个配送区域包括配送人员当前所在的第一配送区域,以及与第一配送区域临近的第二配送区域,因此,客户端在进行多个配送区域对应的界面元素的显示时,可以首先在订单热力图中定位第一配送区域,从而在订单热力图中提供反映第一配送区域的配送订单量信息的界面元素;进而与第一配送区域关联地显示反映第二配送区域的配送订单量信息的界面元素。

具体地,服务器在将多个配送区域各自的配送订单量信息发送给客户端时,可以是以配送区域标识与配送订单量信息的对应关系的方式下发给客户端的,并且,对根据配送人员的位置信息而确定的配送区域的标识可以额外附加一个标记,用于标记该配送区域标识为配送人员当前所在的配送区域。从而,客户端基于该标记,从多个配送区域标识中确定第一配送区域,以根据其对应的配送订单量信息在订单热力图中的该第一配送区域内显示相应的界面元素。

可以理解的是,订单热力图可以视为由两个图层构成的,底层是地图图层,其中包含有多个配送区域,每个配送区域可以以区域边界线和配送区域名称来表征;上层是订单图层,包含配送订单量信息的界面元素,还可以进一步包括图例信息,即每种界面元素对应的含义,以便于配送人员理解该订单热力图。

另外,本实施例中,关于配送订单量信息的含义,可选地,其可以包括订单压力程度和/或订单量分布状况。因为从实际应用的角度来说,配送人员更加希望去往订单量比较多,且配送人员相对紧缺的配送区域。因此,相应可选地,上述界面元素包括:表征订单压力程度的第一界面元素,和/或表征订单量分布状况的第二界面元素。

其中,订单压力程度比如可以是反映配送区域中配送人员人均未完成订单量多少的;订单量分布状况则是反映配送区域内不同子区域的订单量多少的。

其中,配送区域与子区域的含义,可以通过如下的实际举例来理解:

配送区域假设为某个商圈,该商圈内一般包含有多个商户,在一种极端的情况下,可以将每个商户地址视为一个子区域,则此时某个商户对应的订单量即为其对应的子区域的订单量,从而,该商圈内全部商户各自的订单量情况构成了该商圈的订单量分布状况。在另一种情况下,可以预先将该商圈基于一定策略划分为多个子区域,每个子区域对应的订单量由该子区域内全部商户的订单量总和表征。

可选地,上述第一界面元素与第二界面元素可以是不同类型的元素,也可以是相同类型不同属性的元素。举例来说,第一界面元素比如是颜色,即以不同的颜色表示不同的订单压力程度;第二界面元素比如是图形形状,即以不同形状的图形表示不同的订单量多少。

在通过前述方式显示了订单热力图后,配送人员基于多个配送区域对应的界面元素的含义,可以从多个配送区域中选择其想要去往的配送区域,以触发客户端在其选择的配送区域中定位配送人员节点。

其中,配送人员的选择操作比如可以是通过在要选择的配送区域中的点击操作而实现的。可选地,配送人员节点可以默认定位在该选择的配送区域中订单量最多的子区域中,或者,定位在该选择的配送区域中距离配送人员当前位置最近的某位置,等。

为了更加直观地理解上述介绍的客户端对订单热力图的显示过程,下面结合图1a-图1c来举例说明。

假设配送人员初始启动的订单热力图如图1a所示,其中仅显示了多个配送区域,即仅显示了地图图层,比如仅显示了配送区域1和配送区域2。图1a中还包含了一个触发控件,该触发控件是触发显示多个配送区域对应的反映配送订单量信息的界面元素的控件,即是触发显示订单图层的控件。可选地,如图1a所示,在该初始的订单热力图中,还可以基于配送人员的当前位置,在其所处的配送区域1中定位显示配送人员节点,以带有你字样的圆圈来表示。

响应于配送人员对上述触发控件的触发,显示如图1b所示的订单热力图,该订单热力图中包含了订单图层,即包含了配送区域1和配送区域2对应的反各自的配送订单量信息的界面元素,以及图例。图1b中示意了配送订单量信息包括订单压力程度和订单量分布状况,相应的,结合图例所示,不同的订单压力程度对应不同的颜色,不同的订单量以不同的图形形状表示。

假设配送人员触发了选择配送区域2的操作,如图1c所示,在订单热力图的配送区域2中,定位配送人员节点。

值得说明的是,上述图1a的界面示意图仅为了容易理解或者描述方便而举例的,实际应用中,可能不显示仅含有地图图层的订单热力图,比如仅在某个界面中显示上述触发控件,响应于该控件的触发,直接显示图1b示意的订单热力图。

本实施例中,在配送人员的客户端中,以订单热力图的方式,显示多个配送区域对应的反映配送订单量信息的界面元素,从而使得配送人员能够基于该反应不同配送区域各自对应的配送订单量信息的界面元素,直观而全面地了解多个配送区域的订单量情况,从而能够方便地主动做出想要去往哪个配送区域的选择决策。基于该配送区域的主动选择策略,可以使配送人员前往更多订单量的配送区域,从配送人员的角度来说,可以提供配送人员的配送订单量,从全局来看,可以充分利用配送人员的配送运力完成更多配送订单的及时配送,提高整体配送效率以及配送运力的利用率。

可以理解的是,服务平台侧近乎实时地将接收到的配送订单下发至对应配送区域内的配送人员,从而,每个配送区域对应的配送订单量信息是实时变化的,该实时变化可以在客户端的订单热力图中得到反映,以便于各配送人员基于自身的位置、各配送区域的实时配送订单量信息而做出客观的选择,避免盲目前往订单量多的距离其较远的配送区域。

而且,值得说明的是,本实施例中,主要强调的是客户端侧能够以订单热力图的方式显示多个配送区域的配送订单量信息供配送人员做出主动的配送区域选择决策,以转变现有的配送人员被动在某配送区域内接收配送订单的模式为主动决定去往某个配送区域内接收配送订单的模式。而对于某配送人员作出主动选择后,是否允许该配送人员前往其选择的配送区域进行配送订单的配送,不是本实施例的关注重点,后续实施例中会以举例的方式说明。比如可以依据配送人员距离其选择的配送区域的距离,其选择的配送区域在一定时间段内的配送订单量变化趋势,等等,进行是否允许配送人员前往选择的配送区域的判定。

图2为本发明实施例提供的界面显示方法实施例二的流程图,如图2所示,在图1所示实施例基础上,步骤102之后,还可以包括如下步骤:

步骤201、向服务器发送订单分配请求,订单分配请求中包括选择的配送区域的标识。

当配送人员基于上述订单热力图选择了某个配送区域后,其前往该配送区域,后续可接收来自该配送区域的配送订单。

本实施例中,假设该配送人员已经来到其选择的配送区域,在一种可选方式中,该配送人员可以主动触发向服务器请求分配其配送订单,在另一种可选方式中,该配送人员可以被动接受服务器的分配,以获得配送订单,因此,上述步骤201是可选步骤。

在配送人员主动请求的情况下,配送人员可以基于在客户端界面上对某个控件的操作而触发上述订单分配请求。其中,该订单分配请求中的配送区域标识可以是实时的基于配送人员的位置定位,根据定位到的位置确定获得的。

在配送人员被动接受配送订单的情况下,客户端可以将配送人员的当前位置上报服务器,服务器基于接收到的位置信息,当确定该配送人员已经位于其选择的配送区域内时,如果当前有适宜分配给该配送人员的配送订单,则将配送订单发送给该配送人员。可以理解的是,该情况下,在配送人员基于订单热力图选择某个配送区域时,客户端将该配送人员的标识与选择的配送区域的标识上报服务器,以使得服务器存储有该对应关系,以便基于该对应关系确定该配送人员是否已经位于其选择的配送区域内。

步骤202、响应于对订单展示模式控件的触发,以对应的展示模式展示配送人员在选择的配送区域中的至少一个未完成订单。

假设服务器已经为上述配送人员分配了与其选择的配送区域对应的配送订单,在该配送人员进行订单配送的过程中,本实施例还提供了订单查看功能。

在客户端侧可以提供一种或多种订单展示模式,以便于配送人员可以以不同的展示模式查看订单,相应的,在客户端界面中,包含一种或多种展示模式对应的订单展示模式控件。

可选地,订单展示模式控件包括列表展示模式子控件和地图展示模式子控件,相应的,配送人员可以以列表的模式查看订单,也可以以地图的模式查看订单。

可选地,当配送人员以列表的模式查看订单时,可以查看的订单可以包括该配送人员已经配送完成的订单,以及未完成配送的订单。

针对查看未完成订单,下面分别针对上述两种展示模式,结合附图来示意说明:

如图2a所示,当配送人员从左侧图中示意的包含有列表和地图两种展示模式控件的界面中,触发对列表展示控件的选择时,可以在右侧图中示意的界面中,以列表的形式展示未完成订单。在以列表形式展示未完成订单时,可以对应显示每个未完成订单当前所处的配送状态,比如取货、送货、接单等。

如图2b所示,当配送人员从左侧图中示意的包含有列表和地图两种展示模式控件的界面中,触发对地图展示控件的选择时,客户端可以根据配送人员当前未完成的该至少一个未完成订单对应的多个地址信息,在地图上定位多个订单节点,并在地图上显示导航路径,以关联多个订单节点,如图2b中右侧图所示。

本实施例中,上述导航路径是与至少一个未完成配送订单对应的,即当未完成订单数量为多个时,是与多个未完成订单对应的,用于指导配送人员按照什么路径完成多个订单的配送。

实际应用中,服务器侧可以预先针对该至少一个未完成配送订单进行了配送地址的排序,比如假设有3个未完成订单,每个配送订单有两个地址,分别为取货地址和送货地址,且假设这3个订单的地址各不相同,则总共有6个配送地址。排序的结果是这6个地址被赋予了不同的位置编号,即形成了地址序列,将该地址序列和这3个配送订单信息一并发送至客户端。其中,排序策略比如为按照下单时间先后顺序、所对应商圈/对应地址所属的位置区域优先级、对应取货方订单繁忙情况等因素中的一种或多种综合设定。

客户端进而可以调用电子地图的导航功能,将地址序列输入至电子地图,以使得电子地图规划出一条导航路径由客户端显示。

另外,如图2b右侧图中所示,导航路径中显示的每个订单节点,可以以其对应的地址的取送属性来表示,而且,每个订单节点是可被操作的节点,当配送人员触发对某个订单节点的点击操作时,可以显示出与该订单节点对应的配送订单信息,比如标记为取的订单节点被点击时,可以显示取货方名称、取货地址等信息。

本实施例中,提供多种订单查看模式,以便于配送人员在配送订单的过程中查看订单信息。尤其,在地图模式下,将多个配送订单视为一个整体而同时进行多个配送订单的导航路径规划,使得配送员能够同时总览多个配送订单的导航路径规划信息,有助于提高配送效率。

图3为本发明实施例提供的配送订单处理方法实施例一的流程图,本实施例提供的该配送订单处理方法可以由一配送订单处理装置来执行,该配送订单处理装置可以实现为软件,或者实现为软件和硬件的组合,该配送订单处理装置可以集成设置在物流调度平台侧设备中,比如服务器中。如图3所示,该方法包括如下步骤:

步骤301、结合配送人员的位置信息,获取多个配送区域各自的配送订单量信息,其中,多个配送区域包括配送人员当前所在的第一配送区域以及与第一配送区域临近的至少一个第二配送区域。

步骤302、将多个配送区域各自的配送订单量信息发送至客户端,以供客户端显示。

本实施例中,在一种可选场景中,获取多个配送区域各自的配送订单量信息中的多个配送区域可以是所有配送区域,也就是说,服务器可以向每个配送人员的客户端推送全部配送区域各自的配送订单量信息,此时,与配送人员的位置信息无关,因此上述步骤301基于配送人员的位置确定多个配送区域仅为可选方式。

参考图1所示实施例中的介绍,服务器可以基于配送人员的请求而触发获取上述多个配送区域的配送订单量信息的过程,比如接收配送人员的客户端发送的包括配送人员位置信息的获取请求,基于该位置信息,确定其当前所在的第一配送区域,进而,基于各配送区域的相互位置关系,确定与第一配送区域临近的至少一个第二配送区域。之后,分别获取第一配送区域以及至少一个第二配送区域各自对应的配送订单量信息。

在获得第一配送区域以及至少一个第二配送区域各自对应的配送订单量信息之后,将这些配送订单量信息与对应的配送区域标识关联,发送至客户端,以供客户端显示。其中,客户端的显示过程可以参见图1所示实施例,在此不赘述。

上述配送订单量信息,可选地,可以包括订单压力程度和/或订单量分布状况。下面分别针对这两种具体的信息的获取过程进行说明。

图3a为图3所示实施例中步骤301的一种可选实现方式的流程图,如图3a所示,包括如下步骤:

步骤3011、根据多个配送区域各自的未完成配送订单量,确定多个配送区域各自的订单压力。

步骤3012、根据多个配送区域各自的订单压力与压力程度阈值的比较结果,确定多个配送区域各自的订单压力程度。

本实施例中,针对订单压力程度的获取过程进行详细说明。

具体地,上述订单压力的确定步骤包括:

根据多个配送区域各自的未完成配送订单量所位于的订单量阈值区间,确定多个配送区域各自的订单压力计算公式;

获取多个配送区域各自的计算参数;

根据多个配送区域各自的计算参数和订单压力计算公式,确定多个配送区域各自的订单压力。

其中,计算参数包括订单量参数和环境参数,其中,环境参数比如包括交通拥堵参数,天气参数,温度参数,等等,这些环境参数可以是基于从对应的监控平台获取的实时环境数据而确定的。其中,订单量参数比如包括未完成订单量、待分配订单量、未接单订单量等。

本实施例中,未完成订单量由未接单订单量、待分配订单量、取货状态的订单量和送货状态的订单量组成。

另外,本实施例中,对于任一配送区域对应的订单压力的计算,需要根据该配送区域对应的未完成订单量位于哪个订单量阈值区间,而确定采用哪种具体的计算公式来计算该配送区域的订单压力。其中,可以设置多个订单量阈值区间,每个阈值区间表征订单量超出可用的配送人员的配送运力的程度,可以形象称为爆单程度。

下面举例说明任一配送区域的订单压力的计算过程:

首先,需要获得该配送区域对应的如下订单量参数:

该配送区域对应的未分配订单总数:x待分配订单量

该配送区域对应的未接单订单总数:x未接单订单量

该配送区域对应的未完成订单总数:x未完成订单量

该配送区域的一级爆单阈值:z一级

该配送区域的二级爆单阈值:z二级

该配送区域的三级爆单阈值:z三级

其次,需要获得该配送区域对应的如下环境参数:

该配送区域交通拥堵系数:c

该c的取值小于1,取值越大表明该配送区域越拥堵,可以从交通平台获得该配送区域当前对应的交通拥堵情况,基于不同拥堵情况对应的系数设置而确定当前c的取值。

该配送区域的天气系数:

w天气系数=d恶劣天气参数×t天气温度系数

其中,t天气温度系数根据该配送区域当前半小时的温度:t(℃)而确定。

具体地,当天气温度t≤5℃时,当天气温度t≥30℃时,其他温度时,t天气温度系数=1。

其中,d恶劣天气参数根据该配送区域的天气恶劣程度而确定。

具体地,当天气属于中度恶劣天气时,d恶劣天气参数=0.45,当天气属于重度恶劣天气时,d恶劣天气参数=0.8,其他天气为d恶劣天气参数=0.2。

其中,中度恶劣天气包括:

{大风,烈风,阵雨,强阵雨,雷阵雨,小雨,中雨,小雪,中雪,阵雪,霾,扬沙}

重度恶劣天气包括:

在获得配送区域对应的上述订单量参数和环境参数后,可以基于其中的未完成订单总数确定用于计算订单压力的计算公式,进而根据该订单量参数和环境参数得到对应的订单压力值:

如果,x未完成订单量≤z一级,则该配送区域的订单压力p订单压力为:

如果,z一级<x未完成订单量≤z二级,则该配送区域的订单压力p订单压力为:

如果,z二级<x未完成订单量≤z三级,则该配送区域的订单压力p订单压力为:

如果,z三级<x未完成订单,则该配送区域的订单压力p订单压力为:

在根据某个订单压力计算公式得到配送区域的订单压力值后,可以基于该订单压力值与压力程度阈值的比较结果,确定订单压力程度:

低:p订单压力≤0.27

中:0.27<p订单压力≤0.62

高:0.62<p订单压力

本实施例中,可以将订单压力程度划分为上述三种程度。

图3b为图3所示实施例中步骤301的另一种可选实现方式的流程图,如图3b所示,包括如下步骤:

步骤3013、统计多个配送区域各自对应的所有服务提供方在预设历史时间段内分别对应的日平均订单量。

步骤3014、根据所有服务提供方分别对应的日平均订单量,确定多个配送区域各自的订单量分布状况。

本实施例中,针对订单量分布状况的获取过程进行详细说明。

本实施例中,针对上述多个配送区域中的任一配送区域来说,该配送区域的订单量分布状况,主要是用于度量该配送区域内的各服务提供方的往日平均订单量。针对任一服务提供方来说,该往日平均订单量以一定历史时间段内该服务提供方的日平均订单量表征。该历史时间段可以是连续的几天,也可以是间隔的历史某几天。

举例来说,比如当前一天是周六,为了获得当前这天多个配送区域中任一配送区域的订单量分布状况,针对该配送区域内的任一服务提供方来说,可以从历史订单数据库中,查询获得该服务提供方在上个周六、周日,上上个周六、周日,以及上上上个周日,这五天的总订单量,以这五天的总订单量除以五,得到日平均订单量,作为当前这天该服务提供方对应的日平均订单量。

基于此,能够获得多个配送区域中全部服务提供方的日平均订单量,根据每个配送区域内所有服务提供方的日平均订单量,可以得到该配送区域的订单量分布状况,比如可以知道哪些服务提供方的日平均订单量比较多,或者哪块子区域内的服务提供方的日平均订单量比较多。

本实施例中,以服务提供方的历史日平均订单量情况,作为当前一天该服务提供方的订单量的预估结果,用于进行对应配送区域的订单量分布状况的确定。

综上,本发明实施例提供的上述配送订单处理方法,服务器可以基于一定的主动的推送策略或者基于客户端的请求,而获取多个配送区域各自的配送订单量信息,进而将获得的多个配送区域各自的配送订单量信息发送至客户端,以供客户端在界面上比如以订单热力图的方式显示该多个配送区域各自的配送订单量信息,以便于配送人员基于该多个配送区域各自的配送订单量信息,自主选择去往哪个配送区域承接配送订单,有助于提高配送人员的配送体验,提高其完成的配送订单量,也有助于充分利用配送人员的配送运力,保证配送订单的配送效率、准时率。

图4为本发明实施例提供的配送订单处理方法实施例二的流程图,如图4所示,在图3所示实施例基础上,步骤302之后,还可以包括如下步骤:

步骤401、接收客户端发送的订单分配请求,订单分配请求中包括从至少一个第二配送区域中选择的目标配送区域的标识。

服务器发送多个配送区域的配送订单量信息至客户端后,客户端可以以订单热力图的方式显示这些配送订单量信息,以供配送人员做出配送区域的选择。

一般来说,由于在客户端界面上已经基于配送人员的位置信息定位了配送人员当前所在的第一配送区域,因此,如果配送人员仍想要继续留在其当前所在的配送区域,则可以不触发选择操作,从而,如果一定时间内没有接收到配送人员触发的选择操作,默认该配送人员选择了其当前所在的第一配送区域为目标配送区域。

而如果配送区域想要离开当前所在的配送区域,前往周围的其他配送区域,则可以通过在第一配送区域临近的至少一个第二配送区域中触发选择操作,以选择想要前往的目标配送区域。

本实施例中,不论配送人员是选择第一配送区域为目标配送区域,还是选择了某个第二配送区域为目标配送区域,其被分配该目标配送区域内的配送订单,可以是基于自己主动请求而被分配的,也可以是被动接受服务器的分配,参见图2实施例中的介绍。

本实施例中,仅特别说明如果配送人员选择了某个第二配送区域作为目标配送区域,意味着该配送人员想要从当前所在的第一配送区域切换至目标配送区域,此时,其向服务器发送的订单分配请求中包括目标配送区域的标识,可选的,还可以包括第一配送区域的标识,已告知服务器其从哪个配送区域切换到哪个配送区域。

可选的,如果上述订单分配请求中不包括第一配送区域的标识,服务器也可以基于对配送人员实时位置的监测来获得该第一配送区域的标识。

本实施例中,虽然配送人员主观地做出了从第一配送区域切换到目标配送区域的决定,但是有可能该配送人员在第一配送区域内未完成的配送订单量较多。该未完成配送订单量多,一定程度上反映第一配送区域内可能运力紧张,此时如果该第一配送区域内的运力即配送人员转移到其他配送区域,对第一配送区域内配送订单的配送效率影响较大。因此,本实施例中,当配送人员想要从第一配送区域切换到目标配送区域而触发了对目标配送区域的选择操作时,需要进行是否允许其选择该目标配送区域的判定,具体如下述步骤。

步骤402、根据配送人员在第一配送区域内的未完成配送订单量和目标配送区域对应的订单压力,判断是否允许选择目标配送区域。

其中,目标配送区域对应的订单压力的计算过程,可以参见前述实施例中的介绍,在此不赘述。

其中,配送人员在第一配送区域内的未完成配送订单量,可以基于该配送人员被分配的第一配送区域内的所有订单的配送状态来获取,即获取配送状态指示取货、送货、接单状态的配送订单的数量,即为该配送人员在第一配送区域内的未完成配送订单量。

本实施例中,可以设定若配送人员在第一配送区域内的未完成配送订单量小于一定倍数的目标配送区域对应的订单压力,则判定允许该配送人员选择目标配送区域,该倍数比如为6倍,可以根据实际情况而设定。

步骤403、若允许选择目标配送区域,则为配送人员分配目标配送区域内的待分配订单组。

本实施例中,当配送人员行至其选择的目标配送区域后,如果该目标配送区域内存在待分配订单组,则该配送人员与该目标配送区域内的其他配送人员一样,作为备选配送人员,参与待分配订单组的分配。

值得说明的是,目前,同一配送区域的配送订单的分配多是基于分组的方式被分配到配送人员的,往往是基于不同配送订单之间的相似度来划分订单组的,相似度比如包括发货方地址距离比较近等。而且,目前对任一订单组来说,从配送区域内的所有配送人员中选择与该订单组对应的配送人员的方式,一般是基于各配送人员与该订单组的匹配度来选择的,该匹配度比如包括各配送人员距离订单组中第一个配送订单发货地址的距离,等。

本实施例中,为了进一步提高配送效率,对于目标配送区域对应的任一待分配订单组来说,在选择其对应的配送人员时,主要考虑该待分配订单组与各配送人员已有配送订单间的聚合程度。

以上述选择切换到目标配送区域的配送人员为例,下面具体说明待分配订单组能否被分配给该配送人员的判定过程,具体为:

确定待分配订单组与该配送人员的已有配送订单之间是否满足订单聚合条件,其中,已有配送订单是该配送人员在目标配送区域内已经被分配到的配送订单;

若满足订单聚合条件,则将待分配订单组分配给该配送人员。

可选地,假设由上述待分配订单组和该配送人员的已有配送订单组成全部配送订单,上述订单聚合条件包括:

全部配送订单彼此的期望送达时间间隔小于x1分钟,且全部配送订单的期望送达时间小于x2分钟,x1小于x2;

全部配送订单的收货地址poi数量大于或等于k1时,全部配送订单的服务提供方数量小于n1,且服务提供方彼此间的距离小于y1;

全部配送订单的收货地址poi数量小于k1时,全部配送订单的服务提供方数量小于n2,且服务提供方彼此间的距离小于y2,其中,n1小于或等于n2,y1小于y2;

全部配送订单的订单总数小于z;

全部配送订单的订单总金额小于m。

上述订单聚合条件中涉及到的比如期望送达时间、收货地址poi、服务提供方及其地址、订单金额等信息,可以从配送订单中提取获得。

其中,期望送达时间是从时间聚合程度的角度来衡量配送人员的已有配送订单是否与待分配订单组之间具有较高的聚合性。具体的,期望送达时间间隔要求假设若待分配订单组分配给该配送人员,则任一两个配送订单之间的期望送达时间的间隔小于x1分钟,以保证配送人员的配送时间得到充分利用;全部配送订单的期望送达时间小于x2分钟,以保证配送人员能够自比较集中的时间内完成更多订单的配送。

其中,收货地址poi、服务提供方数量、服务提供方彼此间的距离是从空间聚合程度的角度来衡量配送人员的已有配送订单是否与待分配订单组之间具有较高的聚合性。一般来说,配送订单具有发货方即服务提供方地址和收货地址两种地址,概况来说,为了保证配送人员被分配到的所有配送订单具有更高的空间聚合性,需要需求发货方、收货方之间的平衡。具体来说,如果发货方为多个时,收货方尽量保证比较集中、比较少,则有利于提高配送效率;相反的,如果收货方地址比较分散、比较多时,发货方尽量保证比较集中、比较少,有利于提高配送效率。

本实施例中,收货方以收货地址poi(pointofinformation,信息点)来表示。简单来理解,就是假设两个配送订单的收货地址不同,比如楼号、单元号不同,但是这两个收货地址比如在同一个小区中,则认为这两个收货地址具有相同的地址poi。

则本实施例中,要求在全部配送订单的收货地址poi数量大于或等于k1时,全部配送订单的服务提供方数量小于n1,且服务提供方彼此间的距离小于y1,是为了在收货地址poi较多即收货地址比较分散时,要保证服务提供方比较集中,该集中表现为服务提供方数量比较少、彼此间距离比较近。相反的,要求在全部配送订单的收货地址poi数量小于k1时,全部配送订单的服务提供方数量小于n2,且服务提供方彼此间的距离小于y2,n1小于或等于n2,y1小于y2,是为了在收货地址poi较小即收货地址比较集中时,可以适当放宽对服务提供方数量比较、彼此间距离的要求。

另外,还从订单总数、订单总金额的角度来衡量配送人员的已有配送订单是否与待分配订单组之间具有较高的聚合性。

本实施例中,如果配送人员的已有配送订单与待分配订单组之间满足上述聚合条件,则说明该配送人员比较适合承接该待分配订单组,可以将该待分配订单组分配给该配送人员。

本实施例中,当配送人员想要切换至另一个配送区域时,通过对是否允许该切换进行判定,以保证切换前配送区域的配送需求。另外,在为该配送人员分配待分配订单组时,基于待分配订单组与其已有配送订单间的聚合性来确定是否为其分配该待分配订单组,能够保证配送人员被分配到的配送订单之间具有很高的聚合性,有助于提高配送人员的配送效率。

图5为本发明实施例提供的另一配送订单处理方法实施例一的流程图,本实施例提供的该配送订单处理方法可以由一配送订单处理装置来执行,该配送订单处理装置可以实现为软件,或者实现为软件和硬件的组合,该配送订单处理装置可以集成设置在物流调度平台侧设备中,比如服务器中。如图5所示,该方法包括如下步骤:

步骤501、获取配送区域内的待分配订单组。

该待分配订单组是指配送区域内的任一待分配订单组。

步骤502、从配送区域内的至少一个配送人员中选择已有配送订单与待分配订单组之间满足订单聚合条件的配送人员。

具体地,可以基于配送人员的位置,获得该配送区域内的至少一个配送人员,基于对已经分配的配送订单的配送订单状态的监控,可以获得该至少一个配送人员分别对应的已有配送订单。

可选地,针对上述至少一个配送人员中的任一配送人员来说,假设由待分配订单组和该配送人员的已有配送订单组成全部配送订单,则订单聚合条件包括:

全部配送订单彼此的期望送达时间间隔小于x1分钟,且全部配送订单的期望送达时间小于x2分钟,x1小于x2,所述;

全部配送订单的收货地址poi数量大于或等于k1时,全部配送订单的服务提供方数量小于n1,且服务提供方彼此间的距离小于y1;

全部配送订单的收货地址poi数量小于k1时,全部配送订单的服务提供方数量小于n2,且服务提供方彼此间的距离小于y2,其中,n1小于或等于n2,y1小于y2;

全部配送订单的订单总数小于z;

全部配送订单的订单总金额小于m。

上述聚合条件的作用请参加前述实施例中的说明,在此不赘述。

本实施例中,分别针对上述至少一个配送人员进行其已有配送订单与待分配订单组之间是否满足订单聚合条件的度量,从中筛选出满足该条件的配送人员。

步骤503、将待分配订单组分配给选择出的配送人员。

在一种情况下,如果筛选出的满足上述订单聚合条件的配送人员的数量为1个,则直接将待分配订单组分配给选择出的该配送人员。

在另一种情况下,若选择出多个配送人员都满足上述订单聚合条件,则根据多个配送人员分别满足订单聚合条件的程度,从多个配送人员中选择出目标配送人员,以将待分配订单组分配给该目标配送人员。

其中,满足订单聚合条件的程度,举例来说,比如是,具有更小的期望送达时间间隔;具有更短的整体期望送达时间;具有更少的收货地址poi的同时,具有更少的服务提供方,服务提供方地址彼此间距更小,等等。

在另一种情况下,如果没有选择出满足订单聚合条件的配送人员,则可以适当放宽订单聚合条件,该放宽是指可以不用全部满足上述举例出的五种条件,比如可以满足其中的4种、3种即可。实际应用中,可以根据重要程度或者说优先级,对上述举例的五种条件进行排序,从而,在五种条件不能被全部配送人员满足时,可以按照优先级,以优先级排在前面的部分条件作为订单聚合条件重新筛选符合该订单聚合条件的配送人员。

本实施例中,针对某配送区域内的任一待分配订单组来说,在为其分配对应的配送人员时,基于该配送区域内的各配送人员的已有配送订单与待分配订单组之间的订单聚合程度来选择配送人员,即从各配送人员中选择已有配送订单与该待分配订单组之间满足订单聚合条件的配送人员。不同于现有技术中仅依据配送人员与待分配订单组的匹配程度来选择配送人员,本方案中,还进一步结合配送人员已有配送订单与待分配订单组的聚合程度来选择配送人员,以进一步提高配送人员承接的配送订单的配送效率。

以下将详细描述本发明的一个或多个实施例的界面显示装置。这些界面显示装置可以被实现在终端设备的基础架构中。本领域技术人员可以理解,这些笔界面显示装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图6为本发明实施例提供的界面显示装置实施例一的结构示意图,如图6所示,该界面显示装置包括:显示模块11、定位模块12。

显示模块11,用于在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素。

定位模块12,用于响应于对具有不同的所述配送订单量信息的配送区域的选择,在选择的配送区域中定位配送人员节点。

可选地,所述多个配送区域包括配送人员当前所在的第一配送区域,以及,所述显示模块11具体用于:

在所述订单热力图中提供反映所述第一配送区域的所述配送订单量信息的界面元素;

关联地显示反映第二配送区域的所述配送订单量信息的界面元素,所述第二配送区域为所述第一配送区域的临近配送区域。

可选地,所述界面元素包括:表征订单压力程度的第一界面元素,和/或表征订单量分布状况的第二界面元素。

可选地,该装置还包括:

获取模块13,用于通过服务器获取所述多个配送区域各自对应的所述配送订单量信息。

可选地,该装置还包括:

发送模块14,用于向服务器发送订单分配请求,所述订单分配请求中包括所述选择的配送区域的标识。

可选地,所述显示模块11还用于:

响应于对订单展示模式控件的触发,以对应的展示模式展示所述配送人员在所述选择的配送区域中的至少一个未完成订单。

其中可选地,所述订单展示模式控件包括列表展示模式子控件和地图展示模式子控件。

具体地,所述显示模块11还用于:

响应于对所述地图展示模式控件的触发,根据所述至少一个未完成订单对应的多个地址信息,在地图上定位多个订单节点。

在所述地图上显示导航路径,以关联所述多个订单节点。

图6所示装置可以执行图1、图2所示实施例的方法,本实施例未详细描述的部分,可参考对图1、图2所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1、图2所示实施例中的描述,在此不再赘述。

以上描述了界面显示装置的内部功能和结构,实际中,该界面显示装置可实现为终端设备,包括:显示器、处理器;

所述显示器,用于在订单热力图中,显示多个配送区域对应的反映配送订单量信息的界面元素;

所述处理器,耦合到所述显示器,用于响应于对具有不同的所述配送订单量信息的配送区域的选择,控制所述显示器在选择的配送区域中定位配送人员节点。

可选地,所述处理器还用于执行上述图1、图2所示方法步骤中的全部或部分步骤。

图7为本发明实施例提供的配送订单处理装置实施例一的结构示意图,如图7所示,该装置还包括:。

获取模块21,用于获取多个配送区域各自的配送订单量信息;

发送模块22,用于将所述多个配送区域各自的配送订单量信息发送至客户端。

可选地,所述多个配送区域包括配送人员当前所在的第一配送区域以及与所述第一配送区域临近的至少一个第二配送区域。

可选地,所述配送订单量信息中包括订单压力程度,以及,所述获取模块21包括:第一获取子模块211。

第一获取子模块211,用于根据所述多个配送区域各自的未完成配送订单量,确定所述多个配送区域各自的订单压力;根据所述多个配送区域各自的订单压力与压力程度阈值的比较结果,确定所述多个配送区域各自的订单压力程度。

可选地,所述配送订单量信息中包括订单量分布状况,所述获取模块21包括:第二获取子模块212。

第二获取子模块212,用于统计所述多个配送区域各自对应的所有服务提供方在预设历史时间段内分别对应的日平均订单量;根据所述日平均订单量,确定所述多个配送区域各自的订单量分布状况。

其中,所述第一获取子模块211具体用于:

根据所述多个配送区域各自的未完成配送订单量所位于的订单量阈值区间,确定所述多个配送区域各自的订单压力计算公式;

获取所述多个配送区域各自的计算参数;

根据所述多个配送区域各自的计算参数和订单压力计算公式,确定所述多个配送区域各自的订单压力。

可选地,所述计算参数包括订单量参数和环境参数。

可选地,所述装置还包括:接收模块23、判断模块24、分配模块25。

接收模块23,用于接收所述客户端发送的订单分配请求,所述订单分配请求中包括从所述至少一个第二配送区域中选择的目标配送区域的标识。

判断模块24,用于根据所述配送人员在所述第一配送区域内的未完成配送订单量和所述目标配送区域对应的订单压力,判断是否允许选择所述目标配送区域;

分配模块25,用于若允许选择所述目标配送区域,则为所述配送人员分配所述目标配送区域内的待分配订单组。

可选地,所述分配模块25具体用于:

确定所述待分配订单组与所述配送人员的已有配送订单之间是否满足订单聚合条件,所述已有配送订单是所述配送人员在所述目标配送区域内已经被分配到的配送订单;

若满足所述订单聚合条件,则将所述待分配订单组分配给所述配送人员。

可选地,所述订单聚合条件包括:

全部配送订单彼此的期望送达时间间隔小于x1分钟,且所述全部配送订单的期望送达时间小于x2分钟,x1小于x2,所述全部配送订单由所述待分配订单组和所述已有配送订单组成;

所述全部配送订单的收货地址poi数量大于或等于k1时,所述全部配送订单的服务提供方数量小于n1,且服务提供方彼此间的距离小于y1;

所述全部配送订单的收货地址poi数量小于k1时,所述全部配送订单的服务提供方数量小于n2,且服务提供方彼此间的距离小于y2,其中,n1小于或等于n2,y1小于y2;

所述全部配送订单的订单总数小于z;

所述全部配送订单的订单总金额小于m。

图7所示装置可以执行图3、图4所示实施例的方法,本实施例未详细描述的部分,可参考对图3、图4所示实施例的相关说明。该技术方案的执行过程和技术效果参见图3、图4所示实施例中的描述,在此不再赘述。

以上描述了配送订单处理装置的内部功能和结构,实际中,该配送订单处理装置可实现为服务器,包括:存储器、处理器,其中,存储器中存储有计算机程序,处理器调用该计算机程序,以执行如下步骤:

获取多个配送区域各自的配送订单量信息;

将所述多个配送区域各自的配送订单量信息发送至客户端。

可选地,所述处理器还用于执行上述图3、图4所示方法步骤中的全部或部分步骤。

图8为本发明实施例提供的配送订单处理装置实施例二的结构示意图,如图8所示,该装置还包括:获取模块31、第一选择模块32、分配模块33。

获取模块31,用于获取配送区域内的待分配订单组。

第一选择模块32,用于从所述配送区域内的至少一个配送人员中选择已有配送订单与所述待分配订单组之间满足订单聚合条件的配送人员。

分配模块33,用于将所述待分配订单组分配给选择出的配送人员。

可选地,该装置还包括:第二选择模块34。

第二选择模块34,用于若选择出多个配送人员,则根据所述多个配送人员分别满足所述订单聚合条件的程度,从所述多个配送人员中选择出目标配送人员。

相应地,所述分配模块33具体用于:将所述待分配订单组分配给所述目标配送人员。

可选地,所述订单聚合条件包括:

全部配送订单彼此的期望送达时间间隔小于x1分钟,且所述全部配送订单的期望送达时间小于x2分钟,x1小于x2,所述全部配送订单由所述待分配订单组和所述已有配送订单组成;

所述全部配送订单的收货地址poi数量大于或等于k1时,所述全部配送订单的服务提供方数量小于n1,且服务提供方彼此间的距离小于y1;

所述全部配送订单的收货地址poi数量小于k1时,所述全部配送订单的服务提供方数量小于n2,且服务提供方彼此间的距离小于y2,其中,n1小于或等于n2,y1小于y2;

所述全部配送订单的订单总数小于z;

所述全部配送订单的订单总金额小于m。

图8所示装置可以执行图5所示实施例的方法,本实施例未详细描述的部分,可参考对图5所示实施例的相关说明。该技术方案的执行过程和技术效果参见图5所示实施例中的描述,在此不再赘述.

以上描述了笔迹校正装置的内部功能和结构,实际中,该笔迹校正装置可实现为终端设备,包括:存储器、处理器,其中,存储器中存储有计算机程序,处理器调用该计算机程序,以执行如下步骤:

获取配送区域内的待分配订单组;

从所述配送区域内的至少一个配送人员中选择已有配送订单与所述待分配订单组之间满足订单聚合条件的配送人员;

将所述待分配订单组分配给选择出的配送人员。

可选地,所述处理器还用于执行上述图5所示方法步骤中的全部或部分步骤。

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

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以产品的形式体现出来,该计算机产品可以存储在计算机可读存储介质中,如rom/ram、磁碟、光盘等,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)执行各个实施例或者实施例的某些部分所述的方法。

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1