CN111985748A - 订单批次处理方法、装置及计算机系统 - Google Patents
订单批次处理方法、装置及计算机系统 Download PDFInfo
- Publication number
- CN111985748A CN111985748A CN201910430952.XA CN201910430952A CN111985748A CN 111985748 A CN111985748 A CN 111985748A CN 201910430952 A CN201910430952 A CN 201910430952A CN 111985748 A CN111985748 A CN 111985748A
- Authority
- CN
- China
- Prior art keywords
- information
- distributors
- batch
- distribution
- orders
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/083—Shipping
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Development Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Marketing (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请实施例公开了订单批次处理方法、装置及计算机系统,所述方法包括:在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。通过本申请实施例,能够提高订单的按时履约率。
Description
技术领域
本申请涉及订单处理技术领域,特别是涉及订单批次处理方法、装置及计算机系统。
背景技术
“新零售”是以信息技术(大数据、物联网、AI等)为驱动,以消费者体验(满足消费者各种各样需求的购物场景)为核心,将线上、线下的人、货、场三要素重构,形成“商品通、会员通、支付通”的全新商业形态。在这种形态下,可以实现线上线下无缝衔接,线上订单主动分配就近门店发货,为用户提供“30分钟送达”等高效的配送服务。
这种“新零售”模式的门店中,具体售卖的商品可以包括生鲜类、水果类、餐品类等等,用户在线上下单后,门店内的作业人员进行进行称重拣货,打包等多个环节,然后才能由配送员进行配送。与传统的“外卖”行业不同,由于这种“新零售”门店内提供的商品数量以及种类比较多,用户集中下单的情况也比较明显,因此,配备了专门的配送员,由门店集中配送,而不是像“外卖”那样,货物分散于各个商户。因此,在配送调度方式上也会有所不同,在“外卖”系统中,是按订单维度去调度,一个订单只有一个用户,而“新零售”门店内是按批次维度进行调度,一个批次会包括多个用户对应的多个订单。也即,对于同一门店收到的多个不同用户的订单,如果地址比较近,要求的配送时间也接近,则可以进行集单,合并为同一批次,并以批次为单位进行拣货,打包等操作,之后再由同一配送员进行配送,甚至同一配送员还可以同时配送多个批次,以提高配送效率。
但是,在实际应用中可能存在以下问题,门店内的订单是陆续产生的,因此,集单的过程通常可以按照一定的周期来进行,对同一周期内接收到的订单进行集单,合并成多个批次。但是,在“新零售”模式下,对门店配送时效的要求通常是比较高的,例如,半小时送达等,因此,如果集单周期太长,会导致同一批次下各个订单的拣货、打包等处理都被延后,可能会因此耽误配送时效。因此,门店可以根据经验等进行控制,例如,每个集单周期不超过某时间阈值,等等,以使得门店仓内的拣货打包等作业能够及时被执行。但是,在实际应用中,具体订单在不同时间的分布情况可能是不同的,因此,按照上述现有技术的方式实现的过程中,可能会出现配送资源分配不够合理的情况,导致大量的订单被延误。尤其是在一些订单并发量非常大的时间段,上述情况更是经常发生。
发明内容
本申请提供了订单批次处理方法、装置及计算机系统,能够提高订单的按时履约率。
本申请提供了如下方案:
一种订单批次处理方法,包括:
在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
一种订单批次处理装置,包括:
第一确定单元,用于在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
时间预估单元,用于根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
第二确定单元,用于根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
一种计算机系统,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:
在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
通过本申请实施例,能够在集单生成批次的过程中,首先可以在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量,并且,可以根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息,然后,根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。这样,可以根据实际批次的配送时间预估情况,实现对具体分配策略的灵活调整,以此提高批次的按时履约率。
在可选的实施方式下,当某个周期内的批次所需的配送员数量大于当前可用的配送员数量时,可以根据配送站关联的当前不可用的配送员创建配送员副本;在具体分配配送任务时,可以向可用配送员以及配送员副本进行分配,并对其回到配送站的时间进行预估,进而可以预估出具体的批次或订单的按时履约率。如果按时履约率符合预置条件,则可以对分配策略进行调整,例如,对每个配送员单次配送的批次数量上限进行调整,使更多的批次能够被当前可用的配送员配送,以提高订单的按时履约率。
另外,在可选的实施方式中,出了可以对具体配送任务分配策略进行灵活调整,还可以对仓内作业内容的下发时机等进行控制,以此实现仓配联动,更好地提升作业效率,降低仓内积压情况,提高按时履约率。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的系统架构的示意图;
图2是本申请实施例提供的方法的流程图;
图3是本申请实施例提供的装置的示意图;
图4是本申请实施例提供的计算机系统的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
在本申请实施例中,为了更灵活的进行订单的批次调度,采用了根据预估情况进行灵活调整的方案,尤其是对于订单短时间内并发数量非常大的情况下,可以通过灵活的调整配送资源分配策略,以期达到提高按时履约率的目的。具体的,在短时间内订单并发数量非常大的情况下,可能会出现以下情况:在针对某集单周期内待处理的订单生成多个批次后,这些批次所需的配送员数量,大于配送站关联的当前可用配送员的数量。以至于其他的批次只能等待其他配送员完成当前的配送任务后再进行配送,此时,就可能导致该批次的订单无法按时履约。因此,在本申请实施例中,可以首先在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量,然后根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息,进而可以根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。例如,如果发现大量的订单将会无法按时履约,则可以调整分配策略,通过将每个批次中的订单数量上限进行调整,对每个配送员每次被分配的批次数量进行调整等方式,来避免大量订单出现无法按时履约的情况。
为了达到能够进行预估的目的,可以有多种方案,例如,在一种方式下,本申请实施例中还可以在所需的配送员数量大于所述目标配送站中处于当前可用状态的配送员(例如,即将回到站内,或者已经在站内等)的数量的情况下,创建配送员副本,这种配送员副本可以是根据配送站中当前不可用状态的配送员(例如,正在执行配送任务)创建的,因此暂时不能被分配新的配送任务,但是,在本申请实施例中,可以首先将无法分配给可用状态配送员的更多批次暂时分配给这种配送员副本。这样,便可以根据这种配送员副本回到站内的预估时间,大致确定出这些批次会在什么时间完成配送,进而可以确定是否会出现无法按时履约的情况。如果发现很多订单都将无法按时履约,则还可以对任务分配策略进行调整,以保证更多的订单能够被按时履约。
另外,具体实现时,由于本申请实施例中涉及到的订单,从下单到配送之间,通常可能还需要涉及到仓内作业的流程,包括分拣、打包等等,该过程也可能会导致部分订单无法按时履约。因此,还可以根据关联的仓内作业系统的作业状态信息对所述多个批次对应的仓内作业完成时间进行预估,然后,根据所述仓内作业对应的时间预估信息以及所述配送员副本对应的时间预估信息,对所述多个批次的按时履约率进行更准确的预估。
其中,本申请实施例涉及到的系统架构可以如图1所示。其中,交易系统具体可以包括服务端、客户端,消费者用户可以通过客户端进行下单,服务端则生成相应的订单。具体生成的订单就可以提交到集单系统,由集单系统进行批次的生成等处理。生成的批次可以通过配送作业系统分配到具体的配送员,另外,由于本申请实施例中所涉及的订单,在配送之前,通常还需要涉及到仓内作业过程,包括拣货、打包,等等。因此,具体的集单系统还可以向仓内作业系统下发仓内作业任务,由仓内作业系统分配到具体的仓内作业人员客户端,等等。其中,在上述过程中,配送作业系统还可以向集单系统反馈配送员的位置、状态等信息,仓内作业系统也可以向集单系统反馈仓内作业人员的状态等信息,包括忙/闲状态,或者被分配到的待处理单量,等等。在本申请实施例中,集单系统还可以根据上述信息,来调整具体的配送任务分配策略,或者,控制具体向仓内作业系统下发任务的时机,以实现仓配联动的集单系统。
下面对本申请实施例提供的具体技术方案进行详细介绍。
实施例一
首先,该实施例一从集单系统的角度,提供了一种订单批次处理方法,参见图2,该方法具体可以包括:
S201:在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
其中,具体的集单周期中待处理的订单可以有多种,在本申请实施例中,可以包括所述当前集单周期中新收集到的订单,以及在历史集单周期中已生成、尚未开始配送的历史批次对应的订单信息。也就是说,假设上一周期中生成了批次A,其中包括订单1、订单2,并将该批次分配给了某配送员,但是,在当前周期到来时,该配送员仍然未回到配送站,以至于该批次A尚未开始配送。在本申请实施例中,可以将上述状态的批次中包括的订单与当前周期中新收集到的订单一起重新进行批次生成。当然,在具体生成批次的过程中,对于之前已经生成了批次的订单,仍然可以在同一个批次中,在此基础上,可以将新收集到的订单追加到这种历史批次中。也就是说,假设前述批次A中包括订单1、2,在当前周期中新收集到了订单3,经过判断,该订单3与订单1、2在配送时间、地点等方面都符合合单条件,则可以将该订单3追加到批次A中。当然,在实际应用中,同一批次包括的订单数量可能会具有一定的上限,因此,可以在符合上述上限条件的前提上,进行追批。另外,对于当前周期中未能追加到历史批次中的订单,则可以生成新的批次。
生成批次后,可以按照第一分配策略,确定为了完成这些批次的配送,所需的配送员的数量。其中,在第一分配策略中,可以对每个批次的订单量上限,每个配送员单次的配送批次数量上限,和/或配送容器的容量上限等进行设定。这样,假设当前集单周期中生成的批次数量为60个,每个配送员每次可配送的最大批次数量为3个,则需要20个配送员完成当前集单周期中生成的配送任务。
S202:根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
在针对当前集单周期中待处理的订单生成多个批次后,可以对所需的配送时间进行估计。具体的,集单系统可以从配送作业系统中获得具体配送员的当前状态信息,进而确定出当前处于可用状态的配送员的数量,另外,还可以确定出当前不可用状态的配送员的位置,任务状态等信息。其中,可用状态的配送员可以包括两个维度的状态,首先是位置维度,可以是当前已经在配送站内,或者正在返回配送站的途中,能够在某时间内回到配送站的配送员;另外是任务分配情况,具体可以是尚未被分配批次,或者,被分配的批次数量尚未达到上限的配送员。在位置维度以及任务分配情况维度上都符合条件的配送员,可以成为当前可用状态的配送员。否则,则可以成为不可用的配送员,例如,正在执行配送任务的途中,或者,已经被分配了批次,且已经达到上限,等等。但是,这些配送员只是在当前时刻不可用,在过一段时间后,会切换为可用状态。
在现有技术中,针对当前集单周期中生成的批次,将其中部分批次分配给当前可用的配送员后,剩余的批次将会等待其他配送员进入可用状态后再进行分配,然后才可能进入到配送状态,此时,就可能会使得这部分订单无法按时履约。
而在本申请实施例中,为了能够使得更多的订单都能够按时履约,还可以在分配配送任务的过程中,实现对未能分配到可用配送员的订单的按时履约情况进行预估,如果发现大量订单都将被延误,则可以通过调整配送任务分配策略的方式,来避免上述情况的发生。
为了能够实现上述预估,首先可以根据所需的配送员数量与目标配送站中处于当前可用状态的配送员的数量之差,以及所述目标配送站关联的当前处于不可用状态的配送员,创建对应数量的配送员副本,并对配送员副本对应的配送员回到目标配送站所需的时间进行预估。其中,具体在对配送员副本对应的配送员回到目标配送站所需的时间进行预估时,可以有多种方式,例如,一种方式下,可以根据具体配送员当前的状态确定出完成已经分配的配送任务所需的时间,还可以根据具体的任务对应的地址,或者,配送员当前所在的位置,配送的速度,熟练度等信息,估算出其回到目标配送站所需的时间。
在创建了配送员副本的情况下,可以首先将具体的批次分配给可用状态的配送员,在可用配送员都已被分配满后,可以将剩余的批次分配给配送员副本。需要说明的是,针对分配给配送员副本的批次,只是用于对其履约时间进行预估,并不代表实际进行了分配,后续在对分配策略进行调整时,可能会分配给实际可用的配送员。
在完成对批次的分配后,对于分配给实际可用的配送员的批次,通常是可以按时完成履约的,但是,对于分配给配送员副本的批次,由于具体的配送员尚未回到站内,或者无法在某时间内回到站内,因此,可能会造成批次的延误。为此,本申请实施例可以对具体批次对应的按时履约情况进行预估,并且可以统计多个批次的按时履约率。
S203:根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
在确定出各个批次的预估时间后,可以确定是否需要对分配策略进行调整。例如,假设经过预估发现,如果按照第一分配策略进行分配,则50%的订单都将无法按时履约,则可以对分配策略进行调整。其中,具体的调整方式可以包括同一批次中的订单数量上限,同一配送员单次可配送的批次数量上限,配送员配备的配送容器容量上限,等等。这样,有机会使更多的批次能够被分配到当前可用的配送员而实现提前配送。具体的,关于第二分配策略,可以是预先设定好的,或者,也可以是根据实际的情况进行的灵活调整,等等。
例如,假设按照原来的分配策略,某周期中的待处理订单共生成了60个批次,需要20个配送员,但是,当前只有8个配送员处于可用状态,只能完成24个批次的配送。剩余的36个批次,通过预估发现,其中有30个批次都可能无法按时履约。此时,由于无法按时履约的比例比较高,因此,就可以对具体的分配策略进行调整。例如,可以通过提高每个配送员单次配送的批次数量上限来实现,假设原来的策略中,每个配送员单次配送的批次数量上限是三个批次,而在这种特殊情况下,则可以调整为五个批次,这样,可以使得更多的批次能够被分配给当前可用的配送员。当然,具体实现时,这种上限也不是可以无限调整的,必要时还可以调整配送员配备的配送容器容量。另外,在该上限值无法再继续调整时,如果仍然会有大量的订单被延误,则还可以触发站内补充运力,等等。
当然,具体实现时,由于具体的订单生成后,还需要进行仓内作业,而仓内作业也是能否按时履约的一个关键点。因此,在具体实现时,还可以根据关联的仓内作业系统的作业状态信息对所述多个批次对应的仓内作业完成时间进行预估;然后,可以根据所述仓内作业对应的时间预估信息以及所述配送员副本对应的时间预估信息,对所述多个批次的按时履约率进行更准确的预估。
具体实现时,对于仓内作业部分,在常规的实现方案中,集单系统生成具体的批次后,可能会立即向仓内作业系统下发仓内作业任务。但是,在订单并发量非常高的情况下,经常会造成仓内任务的积压。因此,在本申请实施例中,可以根据仓内作业系统的状态信息,将被分配到可用状态配送员的批次关联的订单进行仓内作业任务的生成以及下发。如果某时刻仓内作业系统全部处于被占用状态,则可以等待下一集单周期到来并重新生成批次后,再进行仓内作业任务的生成以及下发。也就是说,在本申请实施例中,由于在某个周期中生成的批次,在下一周期或者后续几个周期中还可能被追加新的订单,而同一批次的订单又是由同一配送员进行配送,因此,同一批次中的订单只要能同时或者在相距比较短的时间内完成拣货及打包即可。换言之,对于在比较靠前的周期中生成的订单,即使先进行了拣货或者打包操作,也可能会等到后续周期中追批的订单完成拣货及打包后,才能够被配送,实际上是没有必要的。但是,对于作业系统而言,如果同一批次在多个不同的周期内被下发多次仓内作业任务,则可能会造成资源的更多占用,尤其是在仓内作业系统任务量也很大的情况下,仓内作业资源显得更加宝贵,这种浪费可能会无法容忍。另外,即使在仓内作业系统相对比较空闲的状态下,能够及时处理仓内作业任务,但是,由于需要等待后续的周期中新追加的订单的拣货及打包完成后一起配送,因此,也可能会造成提前打包完成的货品在仓内积压。而在本申请实施例中,通过对向仓内作业系统下发仓内作业任务的时机进行控制,可以降低上述浪费以及仓内积压情况的发生概率。
另外,在具体集单周期中进行批次生成过程中,也可以根据具体的订单作业状态来进行确定,例如,如果某新收集到的订单符合某历史批次的合批规则,且所述历史批次中包括的订单处于未开始进行仓内作业状态,则将该新收集到的订单添加到该历史批次中。
再者,对于被分配到可用状态配送员的批次关联的订单,还可以根据具体批次的配送时间,配送员的状态等信息,确定出期望仓内作业开始时间以及结束时间,然后,可以按照该期望信息进行仓内作业任务的下发。
总之,通过本申请实施例,能够在集单生成批次的过程中,首先可以在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量,并且,可以根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息,然后,根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。这样,可以根据实际批次的配送时间预估情况,实现对具体分配策略的灵活调整,以此提高批次的按时履约率。
在可选的实施方式下,当某个周期内的批次所需的配送员数量大于当前可用的配送员数量时,可以根据配送站关联的当前不可用的配送员创建配送员副本;在具体分配配送任务时,可以向可用配送员以及配送员副本进行分配,并对其回到配送站的时间进行预估,进而可以预估出具体的批次或订单的按时履约率。如果按时履约率符合预置条件,则可以对分配策略进行调整,例如,对每个配送员单次配送的批次数量上限进行调整,使更多的批次能够被当前可用的配送员配送,以提高按时履约率。
另外,在可选的实施方式中,出了可以对具体配送任务分配策略进行灵活调整,还可以对仓内作业内容的下发时机等进行控制,以此实现仓配联动,更好地提升作业效率,降低仓内积压情况,提高按时履约率。
与前述实施例提供的订单批次处理方法相对应,本申请实施例还提供了一种订单批次处理装置,参见图3,该装置可以包括:
第一确定单元301,用于在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
时间预估单元302,用于根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
第二确定单元303,用于根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
其中,时间预估单元具体可以包括:
状态信息确定子单元,用于确定所述目标配送站关联的配送员的状态信息;
副本创建子单元,用于如果所述所需的配送员数量大于所述目标配送站中处于当前可用状态的配送员的数量,则根据两者差值,创建对应数量的配送员副本,并对配送员副本对应的配送员回到目标配送站所需的时间进行预估;
预分配子单元,用于按照所述第一分配策略,将所述多个批次分配给所述可用状态的配送员以及所述配送员副本;
预估子单元,用于根据所述配送员副本对应的时间预估信息,确定配送预估时间信息。
其中,所述第一分配策略与第二分配策略之间,每个批次的订单量上限,每个配送员单次的配送批次数量上限,和/或配送容器的容量上限不同。
其中,所述预估子单元具体可以包括:
第一预估子单元,用于根据关联的仓内作业系统的作业状态信息对所述多个批次对应的仓内作业完成时间进行预估;
第二预估子单元,用于根据所述仓内作业对应的时间预估信息以及所述配送员副本对应的时间预估信息,对所述多个批次的按时履约率进行预估。
其中,所述待处理的多个订单的信息包括:
当前集单周期中新收集到的订单,以及在历史集单周期中已生成、尚未开始配送的历史批次对应的订单信息。
所述第一确定单元具体可以包括:
订单添加子单元,用于将所述新收集到的订单添加到所述历史批次中;
新批次生成子单元,用于对于无法添加到历史批次中的订单,生成新的批次。
其中,所述订单添加子单元具体可以用于:
如果某新收集到的订单符合某历史批次的合批规则,且所述历史批次中包括的订单处于未开始进行仓内作业状态,则将该新收集到的订单添加到该历史批次中。
另外,该装置还可以包括:
任务下发单元,用于根据仓内作业系统的状态信息,将被分配到可用状态配送员的批次关联的订单进行仓内作业任务的生成以及下发。
另外,该装置还可以包括:
等待单元,用于如果仓内作业节点全部处于被占用状态,则等待下一集单周期到来并重新生成批次后,再进行仓内作业任务的生成以及下发。
其中,对于被分配到可用状态配送员的批次关联的订单,确定期望仓内作业开始时间以及结束时间,并按照该期望信息进行仓内作业任务的下发。
另外,本申请实施例还提供了一种计算机系统,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:
在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
其中,图4示例性的展示出了电子设备的架构,具体可以包括处理器410,视频显示适配器411,磁盘驱动器412,输入/输出接口413,网络接口414,以及存储器420。上述处理器410、视频显示适配器411、磁盘驱动器412、输入/输出接口413、网络接口414,与存储器420之间可以通过通信总线430进行通信连接。
其中,处理器410可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本申请所提供的技术方案。
存储器420可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器420可以存储用于控制电子设备400运行的操作系统421,用于控制电子设备400的低级别操作的基本输入输出系统(BIOS)。另外,还可以存储网页浏览器423,数据存储管理系统424,以及订单批次处理系统425等等。上述订单批次处理系统425就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之,在通过软件或者固件来实现本申请所提供的技术方案时,相关的程序代码保存在存储器420中,并由处理器410来调用执行。
输入/输出接口413用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口414用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线430包括一通路,在设备的各个组件(例如处理器410、视频显示适配器411、磁盘驱动器412、输入/输出接口413、网络接口414,与存储器420)之间传输信息。
另外,该电子设备400还可以从虚拟资源对象领取条件信息数据库441中获得具体领取条件的信息,以用于进行条件判断,等等。
需要说明的是,尽管上述设备仅示出了处理器410、视频显示适配器411、磁盘驱动器412、输入/输出接口413、网络接口414,存储器420,总线430等,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本申请方案所必需的组件,而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的订单批次处理方法、装置及计算机系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。
Claims (12)
1.一种订单批次处理方法,其特征在于,包括:
在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
2.根据权利要求1所述的方法,其特征在于,
所述根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息,包括:
确定所述目标配送站关联的配送员的状态信息;
如果所述所需的配送员数量大于所述目标配送站中处于当前可用状态的配送员的数量,则根据两者差值,创建对应数量的配送员副本,并对配送员副本对应的配送员回到目标配送站所需的时间进行预估;
按照所述第一分配策略,将所述多个批次分配给所述可用状态的配送员以及所述配送员副本;
根据所述配送员副本对应的时间预估信息,确定配送预估时间信息。
3.根据权利要求2所述的方法,其特征在于,
所述第一分配策略与第二分配策略之间,每个批次的订单量上限,每个配送员单次的配送批次数量上限,和/或配送容器的容量上限不同。
4.根据权利要求2所述的方法,其特征在于,
所述根据所述配送员副本对应的时间预估信息,确定配送预估时间信息,包括:
根据关联的仓内作业系统的作业状态信息对所述多个批次对应的仓内作业完成时间进行预估;
根据所述仓内作业对应的时间预估信息以及所述配送员副本对应的时间预估信息,对所述多个批次的按时履约率进行预估。
5.根据权利要求1所述的方法,其特征在于,
所述待处理的多个订单的信息包括:
当前集单周期中新收集到的订单,以及在历史集单周期中已生成、尚未开始配送的历史批次对应的订单信息。
6.根据权利要求5所述的方法,其特征在于,
所述确定多个批次,包括:
将所述新收集到的订单添加到所述历史批次中;
对于无法添加到历史批次中的订单,生成新的批次。
7.根据权利要求6所述的方法,其特征在于,
所述将所述新收集到的订单添加到所述历史批次中,包括:
如果某新收集到的订单符合某历史批次的合批规则,且所述历史批次中包括的订单处于未开始进行仓内作业状态,则将该新收集到的订单添加到该历史批次中。
8.根据权利要求7所述的方法,其特征在于,还包括:
根据仓内作业系统的状态信息,将被分配到可用状态配送员的批次关联的订单进行仓内作业任务的生成以及下发。
9.根据权利要求8所述的方法,其特征在于,还包括:
如果仓内作业节点全部处于被占用状态,则等待下一集单周期到来并重新生成批次后,再进行仓内作业任务的生成以及下发。
10.根据权利要求8所述的方法,其特征在于,
对于被分配到可用状态配送员的批次关联的订单,确定期望仓内作业开始时间以及结束时间,并按照该期望信息进行仓内作业任务的下发。
11.一种订单批次处理装置,其特征在于,包括:
第一确定单元,用于在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
时间预估单元,用于根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
第二确定单元,用于根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
12.一种计算机系统,其特征在于,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:
在第一分配策略下,根据目标配送站待处理的多个订单的信息,确定多个批次以及所需的配送员数量;
根据所述目标配送站对应的配送员的数量以及所需的配送员数量,确定配送预估时间信息;
根据配送预估时间信息,确定是否采用第二分配策略,处理所述待处理的多个订单的信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910430952.XA CN111985748A (zh) | 2019-05-22 | 2019-05-22 | 订单批次处理方法、装置及计算机系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910430952.XA CN111985748A (zh) | 2019-05-22 | 2019-05-22 | 订单批次处理方法、装置及计算机系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111985748A true CN111985748A (zh) | 2020-11-24 |
Family
ID=73435984
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910430952.XA Pending CN111985748A (zh) | 2019-05-22 | 2019-05-22 | 订单批次处理方法、装置及计算机系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111985748A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112529506A (zh) * | 2020-12-22 | 2021-03-19 | 拉扎斯网络科技(上海)有限公司 | 信息交互方法、装置、存储介质和电子设备 |
CN112837128A (zh) * | 2021-02-19 | 2021-05-25 | 拉扎斯网络科技(上海)有限公司 | 订单指派方法、装置、计算机设备及计算机可读存储介质 |
CN113393086A (zh) * | 2021-05-18 | 2021-09-14 | 阿里巴巴新加坡控股有限公司 | 配送任务信息处理方法及装置 |
CN113822615A (zh) * | 2021-02-04 | 2021-12-21 | 北京京东振世信息技术有限公司 | 订单配送方法、装置及可读存储介质和电子设备 |
CN114997781A (zh) * | 2022-05-31 | 2022-09-02 | 广西盖德科技有限公司 | 基于物流状态的碎片化派单方法及装置 |
WO2022245295A3 (en) * | 2021-05-19 | 2023-01-19 | Grabtaxi Holdings Pte. Ltd | System and method for predicting delivery time for batch orders |
CN116308215A (zh) * | 2023-05-17 | 2023-06-23 | 云账户技术(天津)有限公司 | 一种组批出款信息的生成方法、装置及相关设备 |
-
2019
- 2019-05-22 CN CN201910430952.XA patent/CN111985748A/zh active Pending
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112529506A (zh) * | 2020-12-22 | 2021-03-19 | 拉扎斯网络科技(上海)有限公司 | 信息交互方法、装置、存储介质和电子设备 |
CN113822615A (zh) * | 2021-02-04 | 2021-12-21 | 北京京东振世信息技术有限公司 | 订单配送方法、装置及可读存储介质和电子设备 |
CN112837128A (zh) * | 2021-02-19 | 2021-05-25 | 拉扎斯网络科技(上海)有限公司 | 订单指派方法、装置、计算机设备及计算机可读存储介质 |
CN112837128B (zh) * | 2021-02-19 | 2023-04-28 | 拉扎斯网络科技(上海)有限公司 | 订单指派方法、装置、计算机设备及计算机可读存储介质 |
CN113393086A (zh) * | 2021-05-18 | 2021-09-14 | 阿里巴巴新加坡控股有限公司 | 配送任务信息处理方法及装置 |
CN113393086B (zh) * | 2021-05-18 | 2023-12-01 | 阿里巴巴新加坡控股有限公司 | 配送任务信息处理方法及装置 |
WO2022245295A3 (en) * | 2021-05-19 | 2023-01-19 | Grabtaxi Holdings Pte. Ltd | System and method for predicting delivery time for batch orders |
CN114997781A (zh) * | 2022-05-31 | 2022-09-02 | 广西盖德科技有限公司 | 基于物流状态的碎片化派单方法及装置 |
CN116308215A (zh) * | 2023-05-17 | 2023-06-23 | 云账户技术(天津)有限公司 | 一种组批出款信息的生成方法、装置及相关设备 |
CN116308215B (zh) * | 2023-05-17 | 2023-07-21 | 云账户技术(天津)有限公司 | 一种组批出款信息的生成方法、装置及相关设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111985748A (zh) | 订单批次处理方法、装置及计算机系统 | |
CN109426898B (zh) | 作业任务分配方法、装置及计算机系统 | |
US20210056482A1 (en) | Inventory scheduling method and device and non-transitory computer readable storage medium | |
US20190026691A1 (en) | Method, apparatus, and system for scheduling logistic resources | |
CN109583800A (zh) | 物流仓库包裹分拣方法、装置和系统 | |
CN111353840A (zh) | 订单信息处理方法、装置及电子设备 | |
CN108154298B (zh) | 配送任务分配方法、装置、电子设备及计算机存储介质 | |
Ran et al. | A Polling‐Based Dynamic Order‐Picking System considering Priority Orders | |
US20140279660A1 (en) | Overnight productivity dashboard | |
CN109902975A (zh) | 调度方法、系统、装置以及计算机可读存储介质 | |
CN111242555A (zh) | 库存数据处理方法、装置及系统 | |
CN113191713A (zh) | 仓库缺货转仓方法、装置、设备及存储介质 | |
CN109118310A (zh) | 订单处理方法和装置 | |
CN110796402A (zh) | 订单批次调度方法、装置及计算机系统 | |
CN110363476A (zh) | 货物入仓分配处理方法及装置 | |
WO2020144879A1 (ja) | 入出庫管理装置、入出庫管理システム、入出庫管理方法およびプログラム | |
CN114091988A (zh) | 一种目标物品的仓间调度方法和系统 | |
CN112241868A (zh) | 任务处理方法、装置、电子设备及计算机可读存储介质 | |
CN109840815B (zh) | 用于订单处理的系统及方法 | |
CN111950830A (zh) | 一种任务分配方法和装置 | |
CN109493178A (zh) | 一种云零售订单分解方法及系统 | |
CN113159467B (zh) | 一种派车单处理方法和装置 | |
CN108268313A (zh) | 数据处理的方法和装置 | |
CN112541610A (zh) | 机器人的控制方法、装置、电子设备及存储介质 | |
US20160019493A1 (en) | Overnight productivity dashboard |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |