CN117132179A - 一种订单配送处理方法和装置 - Google Patents

Abstract

本发明公开了一种订单配送处理方法和装置，涉及仓储物流领域。该方法的一具体实施方式包括：响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；获取第一订单中的收货人信息，从剩余待配送订单集中查找与收货人信息对应的订单集合，从订单集合中，查找入站操作时间点早于当前收货操作时间点的第二订单；将第一订单和第二订单的信息发给终端设备，以使得配送员对第一订单和第二订单进行配送处理。该实施方式严格按照配送员收货时同时在站的计算原则，与配送员的配送频次绑定作为计费计算依据，与车辆到达批次无关，以此实现公平性、操作过程透明性，同时具备实时提醒功能，以避免订单漏操作。

Description

一种订单配送处理方法和装置

技术领域

本发明涉及仓储物流领域，尤其涉及一种订单配送处理方法和装置。

背景技术

现有物流配送操作，主要涉及货物在站(解封车、验货等)、配送员收货、流程完结(包括妥投、拒收等)，这三大类操作对应货物的三种状态。货物状态的变更涉及到配送员工作的效率，而当前并没有一种提醒的方式来规范配送员的操作，导致反复配送、丢货落货的情况时有发生。另外，现有主要按照收货截止时间点，通过人为划分配送员配送次数，缺乏公平性。

发明内容

有鉴于此，本发明实施例提供一种订单配送处理方法和装置，至少能够解决现有技术划分配送方式不合理、缺乏订单分配提醒的问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种订单配送处理方法，包括：

响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理。

可选的，还包括：

模拟第一目标池，将所述订单集合存入所述第一目标池；以及模拟第二目标池，将所述第二订单存入所述第二目标池；

在将所述第一订单和所述第二订单的信息发给所述终端设备之后，还包括：

响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

可选的，在对所述第一订单和所述第二订单做闭环处理之后，还包括：

基于所述第一订单和所述第二订单生成目标订单组，统计目标订单组的数量，以确定支付给所述配送员的配送费用；其中，目标订单组包括同一收货人、同一收货地址和同一站点，且满足配送员收货时同时在站的多个订单。

可选的，还包括：对待配送订单集中每个订单的收货人信息进行哈希处理；

所述获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，包括：获取所述第一订单的哈希值，从剩余待配送订单集中查找与所述哈希值相同的订单集合。

可选的，还包括：

实时更新每个订单的状态数据，按照流程节点和状态数据的对应关系，将不同状态数据的订单划分到不同流程节点上；以及

根据订单号，对属性流中订单的收货人信息与状态流中的订单状态数据进行关联，以生成订单记录。

为实现上述目的，根据本发明实施例的另一方面，提供了一种订单配送处理装置，包括：

确定模块，用于响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

查找模块，用于获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

分配模块，用于将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理。

可选的，还包括模拟模块，用于：

模拟第一目标池，将所述订单集合存入所述第一目标池；以及模拟第二目标池，将所述第二订单存入所述第二目标池；

所述装置还包括闭环处理模块，用于：

响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

可选的，所述装置还包括计费模块，用于：

基于所述第一订单和所述第二订单生成目标订单组，统计目标订单组的数量，以确定支付给所述配送员的配送费用；其中，目标订单组包括同一收货人、同一收货地址和同一站点，且满足配送员收货时同时在站的多个订单。

可选的，还包括哈希处理模块，用于：

对待配送订单集中每个订单的收货人信息进行哈希处理；

获取所述第一订单的哈希值，从剩余待配送订单集中查找与所述哈希值相同的订单集合。

可选的，所述装置还包括预处理模块，用于：

实时更新每个订单的状态数据，按照流程节点和状态数据的对应关系，将不同状态数据的订单划分到不同流程节点上；以及

根据订单号，对属性流中订单的收货人信息与状态流中的订单状态数据进行关联，以生成订单记录。

为实现上述目的，根据本发明实施例的再一方面，提供了一种订单配送处理电子设备。

本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的订单配送处理方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的订单配送处理方法。

根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：在内存计算中，利用Flink哈希流的内存隔离，模拟出订单从入站到闭环的所有流程节点，并将数据实时呈现在配送员终端设备中，所有过程数据实时展现，做到可追溯、可验证，减少因为离线操作导致的信任问题，对站点的操作实施动态化管理，做到科学、透明、公平、合理，以此提升管理效率，降低各方损失。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1(a)是现有业务流程配送员损失示意图；

图1(b)是现有业务流程公司损失示意图；

图2根据本发明实施例的一种订单配送处理方法的主要流程示意图；

图3是本方案的具体业务实施流程图；

图4是依据Flink的订单配送处理方法的主要流程示意图；

图5是根据本发明实施例的一种基于Flink的订单配送处理方法架构图；

图6(a)是本发明实施例的一种基于Flink的订单配送处理方法的数据流程图；

图6(b)是本发明实施例的一种基于Flink的订单配送处理方法的新业务场景图例；

图7是根据本发明实施例的一种订单配送处理装置的主要模块示意图；

图8是本发明实施例可以应用于其中的示例性系统架构图；

图9是适于用来实现本发明实施例的移动设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

现有的计费规则，参见图1(a)所示，满足同一收货地址、同一收货人姓名、同一验货批次(0-13:00、13:00-19:00、19:00-24:00)的订单按单批次计算费用，会造成如果同一验货批次到货多车，配送员需要来回多次配送的问题，若只按照单批次计算费用，会导致配送员少拿计提费用。但如果在验货批次截止时间点前后到车多辆，配送员只配送了一次，却按多批次计算费用也给公司造成了损失，导致成本多支出，参见图1(b)所示。另外，计费都是通过后台逻辑处理的，而配送员并不了解具体计算逻辑，过程缺乏透明性。

参见图2，示出的是本发明实施例提供的一种订单配送处理方法的主要流程图，包括如下步骤：

S201：响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

S202：获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

S203：将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理；

S204：响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理。

上述实施方式中，本发明仅仅对订单分配规则做了变更处理，用以为后续给配送员计费提供数据基础，但并不涉及具体费用计算。首先对本方案涉及的二同订单和三同订单做解释如下：二同订单：同一收货人、同一收货地址的多个订单称为二同订单；三同订单：同一收货人、同一收货地址、同一站点，并且满足“配送员收货时同时在站”的多个订单，称为三同订单。

需要说明的是，有些订单上填写的收货地址可能不够详细，如仅填写到单元楼，而不会具体到层、门牌号，因而考虑收货地址的同时，还需考虑收货人姓名等具备与他人区别的信息，使得订单配送准确性更高。

对于步骤S201～S202，对于上述“配送员收货时同时在站”，由配送员在站点扫描任一个订单(即第一订单)时触发，此时首先记录当前收货操作时间点以及第一订单中的收货人信息。

假定原待配送订单集中包含订单1和其他订单，在配送员扫描订单1后，需根据订单1中的收货人信息，从剩余待配送订单集中查找与该收货人信息相同的其他订单，即订单集合，与订单1组成二同订单。

实际操作中，系统在用户下单生成订单时、或将订单分配给配送站点之前，已经对订单中的收货人信息做了hash处理，即每个订单都有各自的hash值，同一收货人信息的不同订单的hash值相同，不同收货人信息的订单的hash值也不同，以此实现二同订单的划分。因此，此处也可以直接根据订单1的hash值，从剩余待配送订单集中查找与该hash值相同的订单集合。

本方案优选使用hash处理，此时仅仅比对一个数值即可，无需一一比对收货人信息中的各级行政区域，以此加快查找订单集合的速度。

需要说明的是，此处的“当前收货操作时间点”与二同订单对应，不同二同订单所对应的当前收货操作时间点不同。假设站点包含3组二同订单，分别为：

二同订单组1：订单1、订单2、订单3、订单4

二同订单组2：订单5、订单6、订单7、订单8

二同订单组3：订单9、订单10、订单11、订单12、订单13

配送员到达站点后，首先通过终端设备对订单1做扫描操作，确定当前收货操作时间点1，并依据订单1中的收货人信息或hash值，找到二同订单组1中的其他订单。之后对订单5做扫描操作，获取到一个新的当前收货操作时间点2，同上述步骤，最终查找到二同订单组 2中的其他订单。配送员继续扫描收货订单9，获取到一个新的当前收货操作时间点3，同上述步骤，最终查找到二同订单组3中的其他订单。

对于步骤S203，三同订单的判定是基于二同订单进行的，同一收货人、同一收货地址通常在下单的时候就已经确定了，相当于一个预处理，以此减少后续三同判定的复杂性，提高性能。

对于配送员而言仅考虑收货操作，而二同订单中可能有些订单的状态并不是“入站”，且考虑数据接受可能有延迟，为避免造成乱序，若要满足收货时同时在站，需以“当前收货操作时间点”为依据，确定二同订单中入站操作时间点早于当前收货操作时间点的订单集合。

如前述“二同订单1：订单1、订单2、订单3、订单4”，订单集合包括订单2、订单3、订单4，而订单4由于站点分配错误等原因导致未入站，即其入站操作时间点位于当前收货操作时间点1之后，因此第三订单仅为订单2和订单3。之后将“订单1、订单2、订单3”的订单信息发给配送员的终端设备中，用以配送员清点货物提醒，避免漏操作造成配送员的损失。

对于步骤S204，配送员收货之后开始配送处理，在对任一个订单配送完毕并上传系统后，系统会将与该订单关联的三同订单做闭环处理。如上述“订单1、订单2、订单3”，订单2距离站点最近，在配送订单2完毕之后，直接对“订单1、订单2、订单3”做闭环处理，并不考虑配送员配送订单1和订单3的实际操作情况。

具体参见图3所示，对于场景1，车辆到达并验货入站后，配送员开始收货处理，通过订单A1查找到订单A2，此时如果没有其他车辆到达，配送员也没有再进行收货操作，这时的三同订单是不会改变的， A1+A2作为一个三同订单分配给配送员进行配送处理，在配送A1完毕之后，对A1和A2做闭环处理，锁定生成一个三同组A1+A2。

对于场景2，第一车辆到达并验货入站后，配送员开始收货处理，通过订单A3查找到订单A4，但此时配送员处于休息状态因此不进行分配操作。第二辆车辆到达后配送员又进行收货操作，此时两辆车中同一收货人姓名、同一收货地址的订单，就会被归纳到同一个二同订单组中。假定根据订单A5查找到A6以及原先的A3+A4， A3+A4+A5+A6组成一个新的三同订单分配给配送员进行配送处理，在配送A3完毕之后，对A3+A4+A5+A6做闭环处理，锁定生成一个三同组。

需要说明的是，三同池(即第二目标池)里放的是符合三同条件的订单，且数据是会实时变化的，三同组是闭环锁单后的三同池，组里的数据不会变化。

后续给配送员计费时，可以将三同组的数量作为后续支付依据。如上述场景1和场景2均支付一次。但场景2较为限制，A3+A4+A5+A6 处于三同组，实际操作中会出现不同三同组的情况，例如配送员在11:10 收货10个订单但未配送，休息了一段时间后，在11:40继续收货5个订单，之后开始配送，此时虽然这10个订单和5个订单分属不同的三同订单，但由于收货5个订单时前10个订单并不处于“闭环”状态，因此此时仅支付一次。本方案优选以三同组的数量作为支付依据方式。

或者，从配送员配送角度而言，若配送员一直不去送货妥投锁单，后续即使来车多辆都会归纳为一组三同，总体体现的原则是多送多得，提高时效同时也提升顾客的购物体验。本方案按照配送员收货时同时在站去划分，配送员收货、配送妥投一次就算一个批次，和现有一天内三个批次形成对比，配送多送多得，以此提高配送员的配送积极性。

上述实施例所提供的方法，严格按照配送员收货时同时在站的计算原则，与配送员的配送频次绑定作为三同订单计算依据，与车辆到达批次无关，以此实现公平性、操作过程透明性，同时具备实时提醒功能，避免订单漏操作。

参见图4，示出了根据本发明实施例的一种基于Flink的订单配送处理方法流程示意图，包括如下步骤：

S401：响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

S402：获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合；

S403：模拟第一目标池，将所述订单集合存入所述第一目标池；

S404：从所述第一目标池的所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

S405：模拟第二目标池，将所述第二订单存入所述第二目标池；

S406：将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理；

S407：响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

上述实施方式中，对于步骤S401和S402可参见图2所示描述，在此不再赘述。

对于步骤S403～S407，本方案基于Flink的数据流进行。数据流具有低延迟、高并发等众多优点，在配送操作中能够做到实时处理、秒级延迟。Flink，是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。State是Flink的一种状态机制，用于存放过程数据。

本方案将基于Flink的订单数据流分为状态流和属性流(流：数据流)，其中，状态流用于存储订单的状态数据，包括入站、收货、闭环，而属性流用于存储订单的收货人信息，如收货人姓名、收货地址、站点等，当收货地址确定时相应站点也确定。当订单初始入站时，其状态数据为入站，之后配送员收货订单，则其状态更新为收货，最后配送员将货物配送到客户后，其状态更新为闭环。

由于订单在配送站中有很多状态，而且也存在漏操作情况，比如只取验货，这会造成很多漏验货的订单没有被计算。因此，当站点同时收到多个订单的信息时，首先根据不同订单的状态，按照主要流程节点统一划分到入站、收货、闭环三大节点中，此处划分的意义在于同一类的操作都能代表这一环节的操作。划分之后，按照订单号对状态流中的订单状态数据与属性流中的订单收货人信息进行关联，统一为一条订单记录，如订单1-入库，在收货后更新为订单1-入库-收货，以此类推，直至到闭环为止。

入站操作，利用Flink的State模拟在站池(即第一目标池)，一个站点会设置一个或多个在站池，以将二同订单放入在站池中。需要说明的是，State是Flink中的状态，Flink有个特性，在做检查点时会将State保存起来，该特性保证了数据不会丢失。State只是个工具，其中的数据在失效之前或者手动删除之前是不会丢失的，具备安全性质。本方案模拟配送站操作，须选择安全介质来存储过程数据，因此优选 Flink的State。“模拟在站池”本质是在State中开辟一段空间，以将二同订单数据在闭环之前都保存起来，便于后续操作。

收货操作，在State中开辟新的空间以模拟三同池(即第二目标池)，确定在站池中入站操作时间点小于当前收货操作时间点的第二订单，以将第二订单从在站池中遍历出来放入三同池中。

需要说明的是，存入在站池之前的订单，已根据收货人、收货地址进行分组，因此存入在站池中的订单已是同一收货地址和同一收货人并且同一个站点。相应的，存入同一个三同池的所有订单，是同一收货地址、同一收货人并且同一个站点，已在State中独立开来，所以只需再满足收货时同时在站该条件即可。不同收货人信息的三同池之间也相互独立。

闭环操作，在收到配送员通过终端设备发送的对任一订单的配送完成信息后，对相对应三同池中的所有订单进行闭环处理，该批订单组成一个三同订单组，用作后续计费基数，同时清空当前收货人信息位于在站池和三同池中的数据。

以此三点循环处理，按照配送员操作动作作为划分批次的依据，并用作计费底数，合理合单，规避刷单行为，降低配送损失。

上述实施例所提供的方法，严格按照配送员收货时同时在站的计算原则，与配送员的配送频次绑定作为三同订单计算依据，与车辆到达批次无关，同时配合提醒业务流程，能够在配送员进行收货操作时，提醒配送员在站池还有哪些订单，减少缺货少货导致重复配送的情况。

参见图5，示出了根据本发明实施例的一种基于Flink的订单配送处理方法架构图，包括：

数据源：包括状态流和属性流，状态流用于存储订单的状态数据，如入站、收货和闭环，属性流用于存储订单的收货人姓名、收货地址、哈希值、站点等。

JDQ：一种消息队列，为数据流的承载体，可视为数据流的一种格式。

ES(Elasticsearch)：一个基于Lucene的搜索服务器，提供了一个分布式多用户能力的全文搜索引擎，功能相当于数据库，主要用于存档使用，目标订单判定完后同时也要更新ES，用于后期数据核对。

在站池(即第一目标池)：通过Flink的State模拟得到，用以存放二同订单。

三同池(即第二目标池)：同样通过Flink的State模拟得到，以二同订单为基础，存放入站操作时间点早于配送员当前收货操作时间点的订单。

配送终端工具：用以将配送员扫描的订单和查找到的订单信息，一同发送给配送员的终端设备中进行提醒，告知配送员第一目标池中还有哪些订单未收货，减少缺货少货导致重复配送的情况。

参见图6(a)，示出了本发明实施例的一种基于Flink的订单配送处理方法的数据流程图，包括：

1、通过状态流和属性流，建立订单和状态之间的关联关系；

2、同一收货人信息的订单，在入站时被归属到同一第一目标池中；

3、在配送员收货时，根据初次扫描的订单中的收货人信息，从第一目标池中进行订单筛选；

4、对筛选出的订单，继续筛选入站操作时间点早于当前收货操作时间点的订单，并存入第二目标池中；

5、将第二目标池中的订单信息，发给配送员的终端设备中进行提醒；

6、配送员配送订单，在配送上述任一订单完毕后，对所扫描的订单和第二目标池中的订单进行闭环处理，锁定生成一个目标订单组，作为后续计费依据。

参见图6(b)，示出了本发明实施例的一种基于Flink的订单配送处理方法的新业务场景图例，包括：

1、在确定三同订单后，配送员开始收货(此处并不涉及配送)，例如上述“订单1、订单2和订单3”，在收货订单1和订单2后，系统自动更新这两个订单的状态，如从原先的入站更新为收货，并会自动判断是否还有与之关联的订单未收货，若存在，则触发提醒操作；

2、配送员开始配送订单，在配送上述任一订单完毕后，自动将“订单1、订单2和订单3”的状态由收货更新为闭环，并对三同池中的订单信息进行清除处理。

本发明实施例所提供的方法，相对于现有技术至少存在如下有益效果：

1、由订单收货地址、收货操作时间点作为划分批次的依据，具备公平性原则。

2、规则计算结果、逻辑、过程统一展现在配送员的终端设备中，解决现有分配不透明性问题。

3、实时提醒，告知配送员第二目标池中还有哪些订单待操作，减少误操作、漏操作导致重复配送的情况。

参见图7，示出了本发明实施例提供的一种订单配送处理装置700 的主要模块示意图，包括：

确定模块701，用于响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

查找模块702，用于获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

分配模块703，用于将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理。

本发明实施装置还包括模拟模块，用于：

模拟第一目标池，将所述订单集合存入所述第一目标池；以及模拟第二目标池，将所述第二订单存入所述第二目标池；

所述装置还包括闭环处理模块，用于：

响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

本发明实施装置所述装置还包括计费模块，用于：

基于所述第一订单和所述第二订单生成目标订单组，统计目标订单组的数量，以确定支付给所述配送员的配送费用；其中，目标订单组包括同一收货人、同一收货地址和同一站点，且满足配送员收货时同时在站的多个订单。

本发明实施装置还包括哈希处理模块，用于：

对待配送订单集中每个订单的收货人信息进行哈希处理；

获取所述第一订单的哈希值，从剩余待配送订单集中查找与所述哈希值相同的订单集合。

本发明实施装置所述装置还包括预处理模块，用于：

实时更新每个订单的状态数据，按照流程节点和状态数据的对应关系，将不同状态数据的订单划分到不同流程节点上；以及

根据订单号，对属性流中订单的收货人信息与状态流中的订单状态数据进行关联，以生成订单记录。

另外，在本发明实施例中所述装置的具体实施内容，在上面所述方法中已经详细说明了，故在此重复内容不再说明。

图8示出了可以应用本发明实施例的示例性系统架构800，包括终端设备801、802、803，网络804和服务器805(仅仅是示例)。

终端设备801、802、803可以是具有显示屏并且支持网页浏览的各种电子设备，安装有各种通讯客户端应用，用户可以使用终端设备 801、802、803通过网络804与服务器805交互，以接收或发送消息等。

网络804用以在终端设备801、802、803和服务器805之间提供通信链路的介质。网络804可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

服务器805可以是提供各种服务的服务器，用于执行模拟站池、三同池，筛选二同订单，在二同订单基础上筛选三同订单，实时提醒三同订单哪些配送员未收货操作。

需要说明的是，本发明实施例所提供的方法一般由服务器805执行，相应地，装置一般设置于服务器805中。

应该理解，图8中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图9，其示出了适于用来实现本发明实施例的终端设备的计算机系统900的结构示意图。图9示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908 加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/ 输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元 (CPU)901执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括确定模块、查找模块和分配模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，分配模块还可以被描述为“订单分配模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括执行本方案订单配送处理方法。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (10)

1.一种订单配送处理方法，其特征在于，包括：

响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理。

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

模拟第一目标池，将所述订单集合存入所述第一目标池；以及模拟第二目标池，将所述第二订单存入所述第二目标池；

在将所述第一订单和所述第二订单的信息发给所述终端设备之后，还包括：

响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

3.根据权利要求2所述的方法，其特征在于，在对所述第一订单和所述第二订单做闭环处理之后，还包括：

基于所述第一订单和所述第二订单生成目标订单组，统计目标订单组的数量，以确定支付给所述配送员的配送费用；其中，目标订单组包括同一收货人、同一收货地址和同一站点，且满足配送员收货时同时在站的多个订单。

4.根据权利要求1所述的方法，其特征在于，还包括：对待配送订单集中每个订单的收货人信息进行哈希处理；

所述获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，包括：获取所述第一订单的哈希值，从剩余待配送订单集中查找与所述哈希值相同的订单集合。

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

实时更新每个订单的状态数据，按照流程节点和状态数据的对应关系，将不同状态数据的订单划分到不同流程节点上；以及

根据订单号，对属性流中订单的收货人信息与状态流中的订单状态数据进行关联，以生成订单记录。

6.一种订单配送处理装置，其特征在于，包括：

确定模块，用于响应于配送员通过终端设备对第一订单的扫描收货操作，确定当前收货操作时间点；

查找模块，用于获取所述第一订单中的收货人信息，从剩余待配送订单集中查找与所述收货人信息对应的订单集合，从所述订单集合中，查找入站操作时间点早于所述当前收货操作时间点的第二订单；

分配模块，用于将所述第一订单和所述第二订单的信息发给所述终端设备，以使得所述配送员对所述第一订单和所述第二订单进行配送处理。

7.根据权利要求6所述的装置，还包括模拟模块，用于：

模拟第一目标池，将所述订单集合存入所述第一目标池；以及模拟第二目标池，将所述第二订单存入所述第二目标池；

所述装置还包括闭环处理模块，用于：

响应于收到所述配送员通过所述终端设备发送的对所述第一订单或所述第二订单已完成配送的信息，对所述第一订单和所述第二订单做闭环处理，并清空所述第一目标池和所述第二目标池中的所述第二订单。

8.根据权利要求7所述的装置，所述装置还包括计费模块，用于：

基于所述第一订单和所述第二订单生成目标订单组，统计目标订单组的数量，以确定支付给所述配送员的配送费用；其中，目标订单组包括同一收货人、同一收货地址和同一站点，且满足配送员收货时同时在站的多个订单。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的方法。

10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-5中任一所述的方法。