商品对象信息处理方法、装置及系统
技术领域
本申请涉及商品对象信息处理技术领域,特别是涉及商品对象信息处理方法、装置及系统。
背景技术
O2O(Online To Offline,线上到线下),是指将线下的商务机会与互联网结合,让互联网成为线下交易的平台。随着服务性电子商务模式的升级,完善了商品(服务)、下单、支付等流程,把之前简单的电商模块,转移到更加高频和生活化场景中来。由于传统的服务行业一直处在一个低效且劳动力消化不足的状态,因此,在新模式的推动下,出现了O2O的狂欢热潮,于是上门送餐(俗称“外卖”)、上门生鲜、上门化妆等各种O2O模式开始层出不穷。
一个典型的O2O系统通常由三部分组成:销售渠道提供方(简称发布渠道服务器,例如,淘点点、口碑外卖等)、商家、消费者。在传统模式下,商家可以选择发布渠道服务器,安装该发布渠道服务器的商家客户端,并进行注册,之后便可以利用自己的账户信息向平台中发布其商品;消费者可以通过发布渠道服务器的消费者客户端(例如,移动终端设置中安装的App等)浏览各商家发布的商品,并且可以对指定商家中的指定商品进行下单、支付、选择送货时间、填写送货地址等等。之后,发布渠道服务器便可以将相关的订单信息发送到对应的商家客户端,商家可以准备对应的商品,然后将准备好的商品按照消费者指定的时间配送到指定的地址。其中,配送服务可以是由商家自行提供,为了规范配送流程,提高配送效率,有些发布渠道服务器为商家提供统一的配送服务,也即,在消费者下单后,发布渠道服务器除了向商家客户端发送订单信息,还可以指派专门的配送人员,由配送人员去商家门店收取商品,与自己接收到的订单信息进行核对无误后,派送到消费者指定的收货地址。
在O2O模式下,商品的销量以及订单的履约情况(是否按时送达等)是商家关注的重点。为了提高销量,商家可以选择与多个发布渠道服务器合作,例如,同一家餐厅,可以选择与“口碑外卖”合作,同时还可以选择与其他的发布渠道服务器合作。这就意味着,商家的终端设备上需要安装多个发布渠道服务器的客户端应用,不同的发布渠道服务器能够提供的服务类型、服务流程等可能都会有所不同,这种现象的存在容易影响订单的正常履约,严重影响用户体验。
发明内容
本申请提供了商品对象信息处理方法、装置及系统,能够保证订单的按时履约,提高履约效率。
本申请提供了如下方案:
一种商品对象信息处理系统,包括:
商品对象信息提交模块,用于向多个发布渠道服务器提交商品对象信息,以便所述发布渠道服务器发布商品对象信息后,根据第一用户的操作指令生成交易订单;
订单路由处理模块,用于接收所述发布渠道服务器中生成的交易订单,对交易订单进行处理后,生成加工制作任务以及派送任务,并将所述加工制作任务发送到加工终端,将所述派送任务发送到派送终端;所述加工任务中包括至少一个交易订单中关联的商品对象;
所述加工终端用于根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象进行货品加工制作;
所述派送终端用于根据接收到的派送任务提供派送指示信息,以便针对所述至少一个交易订单进行派送。
一种商品对象信息处理方法,包括:
订单路由处理模块接收所述多个发布渠道服务器中生成的交易订单;其中,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
对交易订单进行处理后,生成加工制作任务以及派送任务;所述加工制作任务中包括至少一个交易订单中关联的商品对象;
将所述加工制作任务发送到加工终端,以便按照所述加工终端提供的加工制作指示信息进行加工制作;
将所述派送任务发送到派送终端,以便按照所述派送终端提供的派送指示信息进行派送。
一种商品对象信息处理方法,包括:
加工终端接收订单路由处理模块发送的加工制作任务,其中,所述订单路由处理模块在接收到多个发布渠道服务器中生成的交易订单,并对交易订单进行处理后,生成的所述配货任务,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象进行加工制作,并将加工制作完成的商品对象通过预置的悬挂链以及输送轨道,输送至指定的位置。
一种商品对象信息处理装置,应用于订单路由处理模块,包括:
交易订单接收单元,用于接收所述多个发布渠道服务器中生成的交易订单;其中,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
任务生成单元,用于对交易订单进行处理后,生成加工制作任务以及派送任务;所述加工制作任务中包括至少一个交易订单中关联的商品对象;
加工制作任务发送单元,用于将所述加工制作任务发送到加工终端,以便按照所述加工终端提供的加工制作指示信息进行加工制作;
派送任务发送单元,用于将所述派送任务发送到派送终端,以便按照所述派送终端提供的派送指示信息进行派送。
一种商品对象信息处理装置,应用于加工终端,包括:
加工制作任务接收单元,用于接收订单路由处理模块发送的加工制作任务,其中,所述订单路由处理模块在接收到多个发布渠道服务器中生成的交易订单,并对交易订单进行处理后,生成的所述配货任务,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
加工制作指示信息提供接收单元,用于根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象进行加工制作,并将加工制作完成的商品对象通过预置的悬挂链以及输送轨道,输送至指定的位置。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
通过本申请实施例,可以提供统一的多渠道信息投放以及订单管理,对于从各个渠道服务器中接收到的交易订单,可以统一进行解析,并生成相应的配货任务以及派送任务,通过这种集中式的订单管理,可以实现订单履约过程中的标准化,保证订单的按时履约,提高履约效率。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的系统的示意图;
图2是本申请实施例提供的第一方法的流程图;
图3是本申请实施例提供的第二方法的流程图;
图4是本申请实施例提供的第一装置的示意图;
图5是本申请实施例提供的第二装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
实施例一
在本申请实施例一中,从商家的角度提供了一种商品对象信息处理系统。该系统可以与合作的多个销售发布渠道服务器进行对接,向多个发布渠道服务器发布了商品对象信息后,在消费者下单的过程中,该系统可以从发布渠道服务器的订单接口获取到具体的交易订单,之后,该系统可以对交易订单进行的解析管理,生成统一加工制作任务以及派送任务,分别提供给加工终端以及派送终端。
具体实现时,参见图1,本申请实施例一提供的商品对象信息处理系统,其特征在于,包括:
商品对象信息提交模块101,用于向多个发布渠道服务器提交商品对象信息,以便所述发布渠道服务器发布商品对象信息后,根据第一用户的操作指令生成交易订单;所述商品对象包括快餐类商品对象;具体的,所述商品对象可以包括生鲜类商品对象,例如水果、海鲜等等;
订单路由处理模块102,用于接收所述发布渠道服务器中生成的交易订单,对交易订单进行处理后,生成加工制作任务以及派送任务,并将所述加工制作任务发送到加工终端,将所述派送任务发送到派送终端;所述加工任务中包括至少一个交易订单中关联的商品对象;
所述加工终端103根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象进行货品加工制作;
所述派送终端104用于根据接收到的派送任务提供派送指示信息,以便针对所述至少一个交易订单进行派送。
具体实现时,商品对象信息提交模块在向多个发布渠道服务器提交商品对象信息时,还可以根据线下店铺中可提供的商品对象库存数量,确定同一商品对象分配到各发布渠道服务器中销售的库存数量,在向发布渠道服务器提交商品对象信息时,还提交对应的库存数量信息,以便各个发布渠道服务器内按照对应的库存数量进行销售。
例如,某商品对象在某门店共有100件库存,共有三个合作的发布渠道服务器,于是向发布渠道服务器A铺货40件,向发布渠道服务器B铺货30件,向发布渠道服务器C铺货30件等。
对于上述存在库存信息的情况下,参见图1,该系统中还可以包括库存管理模块105,用于对各个商品对象在各个发布渠道服务器中的库存数量进行记录及更新。具体的,可以在商品对象信息提交模块向多个发布渠道服务器提交商品对象信息时,记录各个商品对象在各个发布渠道服务器中的库存数量信息,在订单路由处理模块接收到所述发布渠道服务器中生成的交易订单时,确定交易订单关联的商品对象信息以及发布渠道服务器信息,并将对应商品对象在对应发布渠道服务器中的库存数量进行更新。
例如,可以对对应发布渠道服务器的库存数量进行扣减等。如果门店中针对某商品对象追加了新的库存,也可以向各个发布渠道服务器追加相应的铺货数量等等。也就是说,库存管理模块105中保存的信息可以如以下表1所示:
表1
在实际应用中可能存在以下情况:发布渠道服务器A由于开展优惠促销活动等,使得其中的商品对象销售的比较快,而发布渠道服务器B、C中的销售速度则相对较慢。此时,会出现不同发布渠道服务器之间可售数量不能有效体现出商品库存的现象。例如,某消费者用户在使用发布渠道服务器A的客户端查看时,发现某商品对象已无货,而在使用发布渠道服务器A的客户端查看时,却发现该商品对象还有很多的可售库存,此时,这不仅影响商品对象的销售速度,而且影响到消费者的体验,容易使消费才对对商品的真实性的产生质疑等。
为此,在本申请实施例中,库存信息服务器105还可以用于对同一商品对象在各个发布渠道服务器中的库存数量进行监控,以用于在各个发布渠道服务器之间进行库存数量的调配。例如,某时刻发现发布渠道服务器A中的库存数量明显少于另外两个发布渠道服务器A中的库存数量,则可以增加发布渠道服务器A中的可售库存数量,相应的,减少发布渠道服务器B、C中的可售库存数量,并保证调配前后总的可售库存数量保持不变。这样可以促使商品对象以更快的速度售完,并且避免出现同一商品对象在不同发布渠道服务器中的可售信息出现不一致的现象。
具体实现时,生鲜类商品对象对应的线下店铺可以称为“超市”,超市内可以开设多个档口,例如,可以包括水果档口、海鲜档口等等。各个档口中的具体货品可以是预先采购进入超市的。与快餐类商品对象不同的是,生鲜类的商品对象通常不具有“盒饭”那种标准化的包装,例如,商品对象是苹果,消费者在下单时,可能会指定购买的公斤数,等等,超市在收到订单后,通常需要先进行称重,之后,再进行打包等操作。因此,对于生鲜类商品对象,通常都是在收到订单之后,再根据订单指定的规格进行加工制作,加工制作的过程可以包括货品的称重等操作。加工制作完成值之后再进行打包,并等待派送。为了便于提高拣货效率,可以部署一悬挂链输送系统106,该悬挂链输送子货架系统包括输送轨道以及悬挂链,其中,在货品加工完成后,通过所述悬挂链以及输送轨道,输送至预置的位置处(例如,打包处,等等)。其中,如果线下店铺内包括多个区域,也即,多个档口,则每个档口都可以具有能够输送到统一的打包处等位置的输送轨道,每个输送轨道上都可以带有多个悬挂链。也即,输送轨道为多条,每条输送轨道的输送起点与一个区域所在的位置对应,各条输送轨道具有相同的输送终点。在接收到加工制作任务后,某个档口在对对应的货品进行称重等操作后,可以装入预置的输送袋中,并挂到悬挂链上。之后,对应的输送轨道就可以自动将装有对应货品的输送袋输送到打包处,在打包处进行打包等操作,再由派送员进行派送。这样,加工员只需要进行称重、将货品悬挂到悬挂链上等操作即可,而不需要将货品从档口送到打包处,因此,可以提高拣货效率。
关于提供派送服务的派送方,可以采用“自营”或者与第三方配送服务方合作等方式。可以预先为派送员配备本申请实施例中的派送终端104,通过该派送终端104,派送员可以接收任务委派、状态报告、位置报告等等。这样,从商品对象的加工制作(主要包括菜品的加工制作等)到配货(主要包括拣货、打包等),再到后续的派送,都可以实现统一的管理,因此,可以实现服务的标准化,也可以更好的履行订单。
其中,关于加工制作任务以及派送任务的具体生成方式,在后续的实施例三中会进行详细的介绍。
需要说明的是,在本申请实施例中涉及到的各个模块,在具体实现时,可以分别由单独的服务器实现,或者也可以是作为一个服务器的一部分存在,可以根据实际业务的需要进行灵活配置。
总之,通过本申请实施例,可以提供统一的多渠道信息投放以及订单管理系统,通过该系统可以实现标准化,保证订单的按时履约,提高履约效率。下面对该系统的具体实现方式进行详细介绍。
下面分别对系统中涉及到的各个实体的角度,对本申请实施例进行介绍。
实施例二
该实施例二主要从订单路由处理服务器的角度,提供了商品对象信息处理方法,参见图2,该方法可以包括以下步骤:
S201:订单路由处理模块接收所述多个发布渠道服务器中生成的交易订单;其中,所述多个发布渠道服务器根据商品对象信息提交模块提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
具体实现时,各个发布渠道服务器通常会开放一些接口,其中就包括订单接口,通过该接口,发布渠道服务器可以将消费者下单后生成的订单推送到订单路由处理服务器,订单路由处理服务器通过接收到的推送信息,即可获取到发布渠道服务器中生成的交易订单。或者,在另一种实现方式下,订单路由处理服务器也可以采用对发布渠道服务器订单接口进行轮询的方式,从各个发布渠道服务器拉取交易订单,例如,订单路由处理服务器可以每一分钟发起一次轮询,等等。总之,消费者在具体的发布渠道服务器中下单后,发布渠道服务器生成对应的交易订单,之后,该交易订单可以通过多种方式被订单路由处理服务器接收到,由订单路由处理服务器进行后续的处理。
S202:对交易订单进行处理后,生成加工制作任务以及派送任务;所述加工制作任务中包括至少一个交易订单中关联的商品对象;
由于不同的发布渠道服务器对订单格式的定义可能不同,因此,在本申请实施例中,订单路由处理模块可以预先获知各个合作的发布渠道服务器的订单格式信息,在获取到交易订单后,可以首先按照对应的订单格式进行解析,读取中其中的订单信息,例如,可以包括门店信息、商品对象信息、订单类型信息、送达时间信息、收货地址信息,等等。
在实际应用中,发布渠道服务器产生的交易订单可能会存在异常订单的情况,例如,可能是订单价格异常、订单超量、联系方式不全、订单地址异常、配送时间异常、截单后的订单(例如,某门店的午餐订单在15:00截单,如果某订单生成于15:00之后,则会被判定为异常),等等。为此,订单路由处理服务器还可以预先配置并保存异常检测规则,在获取到交易订单后,可以利用这些规则首先对交易订单进行异常检测,如果没有异常,再按照正常的流程进行处理。存在异常的交易订单可以有多种处理方式,例如,可以对异常订单进行修改,或者,将异常订单拒单,或者,还可以跳过异常检测,直接进行接单,等等。
在解析出订单信息后,可以生成加工制作任务以及派送任务,分别发送给加工终端以及派送终端,由加工制作员进行加工制作,并由派送员进行派送。
具体实现时,为了更好的实现订单履约,本申请实施例还可以在前述系统的基础上进行进一步的优化。首先,考虑到实际应用中可能会出现以下情况:派送员数量有限,不可能做到每个交易订单到来时,都有配送员空闲,如果派送员按照交易订单生成的先后顺序进行配送,派送完一个交易订单,再返回门店,取下一个交易订单的商品对象,再派送,则经常会造成一些交易订单无法按时履行,尤其是在多渠道投放、交易订单数量非常大甚至并发的情况下,无法按时履约的订单数量会比较多。针对这种情况,本申请实施例中,在对一个交易订单进行解析后,可以不是直接生成加工制作任务,而是先在订单路由处理服务器进行保存,在接收到其他的交易订单后,确定出可合成为同一批次的至少一个交易订单,并根据该至少一个交易订单关联的商品对象集合生成加工制作任务,在该加工制作任务中记录关联的商品对象信息,以及与各个交易订单之间的关联关系。然后,可以将加工制作任务提供给加工终端,以便进入加工制作流程,这样,可以针对同一批次的各交易订单进行同时加工制作以及派送。也就是说,订单路由处理模块获取到的交易订单,可以一批一批地提供给加工员,这样,可以对同一批次的交易订单同时进行加工制作、打包等操作,并且可以由同一个派送员同时进行派送。
其中,具体在确定哪些交易订单能够成为同一批次时,可以有多种方式,例如,其中一种方式下,可以考虑门店信息、订单类型、送达时间信息等因素,首先,对应同一家门店的交易订单,才可以成为一个批次。在满足该条件后,可以考虑送达时间信息,关于该信息,由于在消费者下单时,可以选择即时送达,或者指定时间点送达,针对两种情况可以有不同的处理方式。其中,针对预约在指定时间点送达的交易订单,可以根据指定的送达时间信息以及预置的履约时效信息(包括订单生产过程中加工制作、打包等操作所需的时间长度,以及配送所需的时间长度),确定出开始加工制作时间。然后,将开始加工制作时间相同,并且收货地址信息符合预置条件(例如距离比较近,等)的至少一个交易订单确定为可合成为同一批次。之后,在到达所述开始加工制作时间时,根据对应批次的交易订单生成加工制作任务,并发送到加工终端。
例如,订单路由处理模块在11:00中接收到交易订单A,该订单的送达时间信息为指定在12:00送达,根据预先配置的履约时效信息可知,配货过程的履约时效为10分钟(主要包括分拣、打包等操作),从当前门店到指定的收货地址所需的时效为20分钟,因此,可以确定出该交易订单A的加工制作开始时间为11:30,因此,暂时先不将该交易订单A的信息发送给配货终端,而是在订单路由处理服务器等待。在等待的过程中,如果接收到新的交易订单B,同样也针对同一家门店,并且计算出加工制作开始时间也是11:30,并且两个订单的收货地址距离比较近,则可以将交易订单A与交易订单B确定为同一批次。类似的,在11:30之前可能还会收到其他满足上述条件的交易订单,因此,可以将这些满足条件的交易订单都作为同一批次。在到达11:30分时,就可以根据该批次包含的各个交易订单,生成加工制作任务,主要是提取出各个交易订单包含的商品对象信息,进行汇总后,生成加工制作任务,并发送到加工终端,加工员就可以按照加工制作任务的信息进行加工制作操作。
另外,对于要求即时送达的交易订单,则可以穿插到最近的批次中,也即,在接收到需即时送达的交易订单时,可以将该交易订单添加到加工制作开始时间最近的批次中。例如,在12:25分接收到一个需要即时送达的交易订单,最近的批次是将会在12:30开始加工制作的批次,因此,就可以将该交易订单添加到该批次中。当然,如果最近的批次距离接收到当前需即时送达的交易订单的时间间隔超过了某阈值,例如20分钟等,则为了避免影响到对即时送达订单的按时履约,也可以直接将该即时送达订单单独作为一个批次。或者,设定一等待时间,例如,等待10分钟等,在该等待时间内如果接收到新的即时送达订单,则也可以将这些即时送达订单作为一个批次。
需要说明的是,在生成批次的过程中,还可以考虑配送中心的运力等问题。也就是说,由于同一批次的订单通常是由同一个派送员进行派送,而同一个派送员一次派送的能力是有限的,尤其是在派送车辆配备有标准的派送箱等设备的情况下,一个派送箱中能够容纳的包裹数量有限,因此,在生成批次的过程中,也不能无限制地向同一批次中增加交易订单的数量。具体实现时,可以在每次向同一批次添加一个交易订单后,对该批次中的商品对象的体积/重量是否超出运力范围进行判断,如果超出,则不再向该批次中添加新的交易订单。其中,关于派送运力信息可以是预先配置的,例如,可以通过一次能够派送的商品对象体积/重量等进行配置,订单路由处理服务器在进行判断时,可以对商品对象的体积进行预估,将预估出的一个批次中的商品对象总体积,与运力能够支持的体积/重量进行比较,等等。
另外,在实际应用中,有些商品对象可能具有比较大件(例如体积/重量超出预置的阈值等)的特点,例如10公斤一袋的面粉、5公斤一桶的食用油,等等,这种商品对象通常难以与其他商品对象一起打包派送,为此,可以预先为体积/重量大于预置阈值的商品对象添加预置标识。例如,保存商品对象信息时可以如下保存:
表2
商品对象标识 |
包装盒规格 |
商品对象重量(kg) |
是否为大件 |
100001 |
大号 |
10 |
是 |
100002 |
中号 |
0.5 |
否 |
…… |
…… |
…… |
…… |
这样,在接收到交易订单后,可以通过判断所述交易订单中是否存在带有所述预置标识的商品对象,判断是否存在大件商品对象。如果发现订单中关联的商品对象包括大件商品对象,则可以将该交易订单单独形成一个批次,单独进行打包派送。其中,如果一个交易订单中同时包括大件商品对象以及其他的普通商品对象,则可以进行拆单操作,将其中的大件商品对象提取出来,单独作为一个批次,并生成第二订单。交易订单中剩余的普通商品对象,则可以按照前述的方式与其他交易订单形成批次。对于这种情况,同一交易订单中不同类型的商品对象可能会由不同的派送员进行派送,但是都会按照消费者指定的送达时间进行履约。
在实际应用中,为了使得订单路由处理模块可以更直观地体现出交易订单的信息,还可以将交易订单的收货地址信息映射到电子地图系统中的坐标,并通过“气球”、“气泡”等形状的图形来标示。另外,在地图上标示各个坐标时,还可以将消费者指定的送达时间、开始配货时间、开始派送时间等时间信息展示到电子地图系统中,从而可以直观的显示出交易订单集中出现的位置、时间等,便于在各个位置之间进行运力调配等操作。
总之,通过上述方式,可以分批次地进行订单的加工制作以及派送,从而使得要求送达时间相近、地理位置相近的交易订单可以并行配送,因此,可以更好的保证交易订单的按时履约。
S203:将所述加工制作任务发送到加工终端,以便按照所述加工终端提供的加工制作指示信息进行加工制作;
S204:将所述派送任务发送到派送终端,以便按照所述派送终端提供的派送指示信息进行派送。
实施例三
该实施例四是从加工终端的角度提供了一种商品对象信息处理方法,参见图3,该方法可以包括以下步骤:
S301:加工终端接收订单路由处理模块发送的加工制作任务,其中,所述订单路由处理模块在接收到多个发布渠道服务器中生成的交易订单,并对交易订单进行处理后,生成的所述配货任务,所述多个发布渠道服务器根据商品对象信息提交模块提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
S302:根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象同时进行加工制作,并将加工制作完成的商品对象通过预置的悬挂链以及输送轨道,输送至指定的位置。
需要说明的是,关于前述实施例三,是与前述实施例相对应的,只是描述角度有所不同,因此,相关的具体实现可以参见前述实施例中的记载,这里不再赘述。
与实施例二相对应,本申请实施例还提供了一种商品对象信息处理装置,该装置可以应用于订单路由处理模块,参见图4,该装置可以包括:
交易订单接收单元401,用于接收所述多个发布渠道服务器中生成的交易订单;其中,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
任务生成单元402,用于对交易订单进行处理后,生成加工制作任务以及派送任务;所述加工制作任务中包括至少一个交易订单中关联的商品对象;
加工制作任务发送单元403,用于将所述加工制作任务发送到加工终端,以便按照所述加工终端提供的加工制作指示信息进行加工制作;
派送任务发送单元404,用于将所述派送任务发送到派送终端,以便按照所述派送终端提供的派送指示信息进行派送。
其中,所述任务生成单元可以包括:
批次合成子单元,用于根据接收到的各交易订单的信息确定可合成为同一批次的多个交易订单;
生成子单元,用于根据所述多个交易订单生成加工制作任务以及派送任务。
所述批次合成子单元包括:
时间确定子单元,用于针对预约在指定时间点送达且对应同一线下店铺的交易订单,根据指定的送达时间信息以及预置的履约时效信息,确定开始加工制作时间;
合成子单元,用于将开始加工制作时间相同且收货地址信息符合预置条件的至少一个交易订单确定为可合成为同一批次,以便在到达所述开始加工制作时间时,将针对对应批次生成的加工制作任务发送到加工终端。
具体实现时,该装置还可以包括:
第一添加单元,用于接收到需即时送达的交易订单时,将该交易订单添加到同一线下店铺内开始加工制作时间最近的批次中。
运力信息保存单元,用于预先保存各个商品对象的体积/重量属性信息,以及配送的运力信息;
运力判断单元,用于在将一个交易订单添加到一批次中之前,判断添加该交易订单后,该批次内商品对象的总体积/重量是否超出配送运力;
第二添加单元,用于如果未超出,则将该交易订单添加到该批次中。
标识添加单元,用于预先为体积/重量大于预置阈值的商品对象添加预置标识;
标识判断单元,用于在接收到所述交易订单后,判断所述交易订单中是否存在带有所述预置标识的商品对象;
单独批次生成单元,用于如果存在,则将该商品对象单独生成为一个批次,以便单独对该商品对象进行加工制作以及派送。
优先级信息确定单元,用于根据同一批次内关联的各个交易订单的送达时间信息以及收货地址信息,确定该批次内各交易订单的派送优先级信息;
路径生成单元,用于根据所述配送优先级生成该批次内的派送路径;
路径提供单元,用于将所述派送路径信息提供给所述派送终端。
与实施例三相对应,本申请实施例还提供了一种商品对象信息处理装置,应用于加工终端,参见图5,该装置可以包括:
加工制作任务接收单元501,用于接收订单路由处理模块发送的加工制作任务,其中,所述订单路由处理模块在接收到多个发布渠道服务器中生成的交易订单,并对交易订单进行处理后,生成的所述配货任务,所述多个发布渠道服务器根据商品对象信息提交服务器提交的商品对象信息进行信息发布,并根据第一用户的操作指令生成所述交易订单;
加工制作指示信息提供接收单元502,用于根据接收到的加工制作任务提供加工制作指示信息,以便对所述至少一个交易订单中关联的商品对象进行加工制作,并将加工制作完成的商品对象通过预置的悬挂链以及输送轨道,输送至指定的位置。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的商品对象信息处理方法、装置及系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。