CN116664051A - 一种零售行业多渠道订单合并发货方法及系统 - Google Patents

Abstract

本申请提出了一种零售行业多渠道订单合并发货方法及系统，涉及计算机技术领域。该方法包括：将订单进行收集，根据合并订单发货系统模块进行合并处理判断，若满足合并要求，则合并多条订单使用同一个运单发货，若不满足合并要求，则这些订单进行单独处理包括：指定单笔订单，选择确认发货，选择合并订单发货；通过合并订单发货系统模块进行可合并发货订单筛选；展示符合合并的订单结果，选取后补充物流公司、运单号完成发货；合并订单发货后，发货物流单与订单为多对一的关系。通过零售百货行业订单发货管理，来提高发货效率，合并发货后的物流订单仍按照原有物流线路进行发货，且合并后不会增加额外物流费用成本。

Description

一种零售行业多渠道订单合并发货方法及系统

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种零售行业多渠道订单合并发货方法及系统。

背景技术

在目前的零售百货行业，企业的商城系统每日成交大量订单，尤其是在企业进行营促销活动期间，有些情况下，同一用户为了能够最大享受折扣减免，便会在较短时间内会产生多笔订单，当企业在处理用户订单发货时，会将每笔订单配备对应的物流发货，但多笔订单都是来源自同一用户。基于此情况，便会存在企业要对每笔订单都承担物流的运输成本，每笔订单的物流时效不一致，用户也会在不同时间接收到多个物流包裹。

为此，需要助力企业为其提供更为高效的发货管理功能，有效的提升企业物流运输效率，减轻企业承担的物流成本，同时还能提高买家物流收货体验。

发明内容

本申请的目的在于提供一种零售行业多渠道订单合并发货方法，其能够通过零售百货行业订单发货管理，来提高发货效率，合并发货后的物流订单仍按照原有物流线路进行发货，时效承诺也会保持不变，且合并后不会增加额外物流费用成本，仅是将多个订单的商品合并到同一包裹中进行发货。合并订单的目标不限同门店下的专柜，各专柜只要满足均可合并发货。

本申请的另一目的在于提供一种零售行业多渠道订单合并发货系统，其能够运行一种零售行业多渠道订单合并发货方法。

本申请的实施例是这样实现的：

第一方面，本申请实施例提供一种零售行业多渠道订单合并发货方法，其包括将订单进行收集，根据合并订单发货系统模块进行合并处理判断，若满足合并要求，则合并多条订单使用同一个运单发货，若不满足合并要求，则这些订单进行单独处理包括：指定单笔订单，选择确认发货，选择合并订单发货；通过合并订单发货系统模块进行可合并发货订单筛选；展示符合合并的订单结果，选取后补充物流公司、运单号完成发货；合并订单发货后，发货物流单与订单为多对一的关系。

在本申请的一些实施例中，上述还包括自定义规则确定订单之间的相似性，以确保合并的订单具有相似的特征，将不同渠道的订单数据整合到统一的数据库或数据存储中，以便进行订单合并处理，通过定义好的规则分析订单数据，比较订单之间的相似性，找出可以合并的订单。

在本申请的一些实施例中，上述根据合并订单发货系统模块进行合并处理判断包括订单提取：通过指定单笔订单进行发货，以指定的单笔订单所属的门店、配送方式、送达时间、收货信息进行后续判断。

在本申请的一些实施例中，上述还包括地址提取：使用自然语言处理技术，获取当前订单的收货地址并进行分词处理，提取出省、市、区(且)、街道、详细地址。

在本申请的一些实施例中，上述还包括地址对比：根据提取内容，找到当前待发货订单是否有与该订单相同的收货地址，若存在相同地址则继续判断，若不存在相同地址则不进行合单操作。

在本申请的一些实施例中，上述还包括电话号码对比：根据地址对比结果，从结果中继续判断收件人电话一致，若一致则继续判断，若不一致则不进行合单操作。

在本申请的一些实施例中，上述还包括姓名对比：根据电话号码对比结果，从结果中继续判断收件人姓名一致，若一致则继续判断，若不一致则不进行合单操作。

在本申请的一些实施例中，上述还包括配送方式对比：根据姓名对比结果，从结果中继续判断配送方式一致，包括自提、同城配送、快递配送三种，同城配送时，再次校验用户期望送达时间是否一致，若一致则继续判断，若不一致则不进行合单操作。

第二方面，本申请实施例提供一种零售行业多渠道订单合并发货系统，其包括订单识别和归类模块，用于建立一个系统来识别和归类不同渠道的订单，每个订单应该包含一个唯一的标识符或订单号码，以及订单的详细信息；

判断订单相似性模块，用于判断是否可以合并订单，定义一组规则或条件来确定订单之间的相似性，以确保合并的订单具有相似的特征；

合并订单模块，用于当确定了相似的订单，将相似的订单合并至同一个运单。

第三方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如一种零售行业多渠道订单合并发货方法中任一项的方法。

相对于现有技术，本申请的实施例至少具有如下优点或有益效果：

通过零售百货行业订单发货管理，来提高发货效率，合并发货后的物流订单仍按照原有物流线路进行发货，时效承诺也会保持不变，且合并后不会增加额外物流费用成本，仅是将多个订单的商品合并到同一包裹中进行发货。合并订单的目标不限同门店下的专柜，各专柜只要满足均可合并发货。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的订单合并发货方法模块化示意图；

图2为本申请实施例提供的一种零售行业多渠道订单合并发货方法详细步骤示意图；

图3为本申请实施例提供的一种零售行业多渠道订单合并发货系统模块示意图；

图4为本申请实施例提供的一种电子设备。

图标：101-存储器；102-处理器；103-通信接口。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的各个实施例及实施例中的各个特征可以相互组合。

实施例1

合并发货的必要条件：发货方地址为同一地址，即同一门店下的订单。不同门店的订单，直接过滤掉，不允许参与合并订单。

对符合发货条件订单提取：订单的状态判定，仅限实物线上订单，需要完成复核，即达到可发货条件的订单，且是未发货的订单；同一订单内已拆包裹发货的订单不能再参与合并发货；货仓的准备工作：发货的物品已完成拣货，打好包，并已确认物品质量完好。

3.对订单地址进行提取：通过对订单地址分词处理，解析出省市区县街道及详细地址，例如北京市朝阳区小关街道渔阳置业大厦A510室，将分词为省为北京、市为北京市、区为朝阳区、街道为小关街道、详细地址为渔阳置业大厦A510室。

对订单地址进行对比：通过提取订单地址，找到收货地址完全符合的其它订单，必需完全一致，若另一订单四级地址均一致，但详细地址中“A510室”写为“a510室”，由于大小写不同，则视为不能参与合并发货。

对收件人电话号码进行对比：通过提取收件人的电话号码，找到电话号码完全符合的其它订单，必需完全一致，如号码都是13800138000。

对收件人姓名进行对比：通过提取收件人的姓名，找到姓名完全符合的其它订单，必需完全一致，如姓名都是“张三”，若有姓名为“张-三”，则视为不能参与合并发货。

对订单配送方式进行对比：通过提取订单的配送方式，找到配送方式完全符合的其它订单，必需完全一致，如虽然收货地址、电话号码、姓名相同，但订单分别是需要“快递配送”和“同城配送”两种，则视为不能合并发货。且即便均为“同城配送”，但用户期望送达的时间分别是“12：00”与“13：00”，则视为不能合并发货。

请参阅图1和图2，图1为本申请实施例提供的订单合并发货方法模块化示意图，图2为本申请实施例提供的一种零售行业多渠道订单合并发货方法详细步骤示意图，其如下所示：

在一些实施方式中，首先，要根据一笔订单的信息作为识别判断的依据，后续一切判断均依赖该笔订单的信息；

其次，通过建立订单合并发货管理系统，该系统将基于订单状态、订单信息自动提取允许合并的订单；

最后，根据分析计算出提取结果，由操作人员对订单进行发货，确保业务顺利运行。

整个提取过程，就是需要对每一订单的特征属性与所指定的订单特征属性相一致

在一些实施方式中，可以采用设计模式来实现订单合并的功能：

1.策略模式：将不同的合并策略封装到不同的策略类中，并在运行时动态选择合适的策略。(1.收货人信息相同：如果同一会员购买多个商品，但是收货人信息相同，则可以考虑将多笔订单合并为一笔订单。2.收货地址相同：即使收货人不同，但是收货地址相同，也可以将多笔订单合并发货，以提高物流效率。3.配送方式相同：如果会员使用相同的配送方式(例如快递、同城配等)，则可以将多笔订单合并为一笔订单。)

2.职责链模式：将多个订单合并处理的功能拆分成多个处理类，每个处理类对应一种合并条件，并将处理类以链式结构组织起来，让请求在链上依次流转并交由合适的处理类处理。

3.工厂模式：根据订单的属性(例如收货人信息、收货地址等)创建不同的订单对象，然后将这些订单对象传递给一个订单合并工厂，由工厂根据一定的合并规则进行合并。

实施例2

请参阅图3，图3为本申请实施例提供的一种零售行业多渠道订单合并发货系统模块示意图，其如下所示：

订单识别和归类模块，用于建立一个系统来识别和归类不同渠道的订单，每个订单应该包含一个唯一的标识符或订单号码，以及订单的详细信息；

判断订单相似性模块，用于判断是否可以合并订单，定义一组规则或条件来确定订单之间的相似性，以确保合并的订单具有相似的特征；

合并订单模块，用于当确定了相似的订单，将相似的订单合并至同一个运单。

在一些实施方式中，需要建立一个系统来识别和归类不同渠道的订单。每个订单应该包含一个唯一的标识符或订单号码，以及订单的详细信息，例如产品、数量、价格和客户信息等。

为了判断是否可以合并订单，需要定义一组规则或条件来确定订单之间的相似性。这些规则可能包括订单号码的格式、订单中的产品和数量、客户信息等。可以根据实际情况确定这些规则，以确保合并的订单具有相似的特征。

一旦确定了相似的订单，可以将它们合并至同一个运单。在合并过程中，需要处理以下几个方面：

订单信息：将相似订单中的产品和数量进行合并，并确保合并后的订单信息准确无误。

客户信息：如果相似订单属于同一客户，可以将客户信息合并到单个订单中，或者选择一个主订单，并将其他订单的客户信息更新为主订单的客户信息。

渠道信息：保留主订单的渠道信息，或者选择一个主要渠道来表示合并后的订单的来源渠道。

更新库存和支付信息：合并订单后，需要相应地更新库存和支付信息。确保从库存中扣除合并订单中的产品数量，并更新付款记录，以反映合并后的订单金额。

在一些实施方式中，数据整合：将不同渠道的订单数据整合到一个统一的数据库或数据存储中，以便进行订单合并处理。

数据分析和匹配算法：使用算法和规则来分析订单数据，比较订单之间的相似性，找出可以合并的订单。

后端开发：使用编程语言和框架来实现订单合并的逻辑，包括订单识别、相似性判断、订单合并和数据更新等功能。

数据库操作：使用数据库操作语言(如SQL)来查询和更新订单数据，以完成订单合并的操作。

接口和集成：如果您使用的是多个渠道的订单管理系统，可以探索是否存在接口或集成工具，用于将订单数据导入到统一的系统中进行处理。

如图4所示，本申请实施例提供一种电子设备，其包括存储器101，用于存储一个或多个程序；处理器102。当一个或多个程序被处理器102执行时，实现如上述第一方面中任一项的方法。

还包括通信接口103，该存储器101、处理器102和通信接口103相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器101可用于存储软件程序及模块，处理器102通过执行存储在存储器101内的软件程序及模块，从而执行各种功能应用以及数据处理。该通信接口103可用于与其他节点设备进行信令或数据的通信。

其中，存储器101可以是但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器102可以是一种集成电路芯片，具有信号处理能力。该处理器102可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请所提供的实施例中，应该理解到，所揭露的方法及系统，也可以通过其它的方式实现。以上所描述的方法及系统实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的方法及系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

另一方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器102执行时实现如上述第一方面中任一项的方法。所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

综上所述，本申请实施例提供的一种零售行业多渠道订单合并发货方法及系统，通过零售百货行业订单发货管理，来提高发货效率，合并发货后的物流订单仍按照原有物流线路进行发货，时效承诺也会保持不变，且合并后不会增加额外物流费用成本，仅是将多个订单的商品合并到同一包裹中进行发货。合并订单的目标不限同门店下的专柜，各专柜只要满足均可合并发货。

以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims (10)

1.一种零售行业多渠道订单合并发货方法，其特征在于，将订单进行收集，根据合并订单发货系统模块进行合并处理判断，若满足合并要求，则合并多条订单使用同一个运单发货，若不满足合并要求，则这些订单进行单独处理包括：

指定单笔订单，选择确认发货，选择合并订单发货；

通过合并订单发货系统模块进行可合并发货订单筛选；

展示符合合并的订单结果，选取后补充物流公司、运单号完成发货；

合并订单发货后，发货物流单与订单为多对一的关系。

2.如权利要求1所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括

自定义规则确定订单之间的相似性，以确保合并的订单具有相似的特征，将不同渠道的订单数据整合到统一的数据库或数据存储中，以便进行订单合并处理，通过定义好的规则分析订单数据，比较订单之间的相似性，找出可以合并的订单。

3.如权利要求1所述的一种零售行业多渠道订单合并发货方法，其特征在于，所述根据合并订单发货系统模块进行合并处理判断包括订单提取：

通过指定单笔订单进行发货，以指定的单笔订单所属的门店、配送方式、送达时间、收货信息进行后续判断。

4.如权利要求3所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括地址提取：

使用自然语言处理技术，获取当前订单的收货地址并进行分词处理，提取出省、市、区、街道、详细地址。

5.如权利要求4所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括地址对比：

根据提取内容，找到当前待发货订单是否有与该订单相同的收货地址，若存在相同地址则继续判断，若不存在相同地址则不进行合单操作。

6.如权利要求5所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括电话号码对比：

根据地址对比结果，从结果中继续判断收件人电话一致，若一致则继续判断，若不一致则不进行合单操作。

7.如权利要求6所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括姓名对比：

根据电话号码对比结果，从结果中继续判断收件人姓名一致，若一致则继续判断，若不一致则不进行合单操作。

8.如权利要求7所述的一种零售行业多渠道订单合并发货方法，其特征在于，还包括配送方式对比：

根据姓名对比结果，从结果中继续判断配送方式一致，包括自提、同城配送、快递配送三种，同城配送时，再次校验用户期望送达时间是否一致，若一致则继续判断，若不一致则不进行合单操作。

9.一种零售行业多渠道订单合并发货系统，其特征在于，包括：

订单识别和归类模块，用于建立一个系统来识别和归类不同渠道的订单，每个订单应该包含一个唯一的标识符或订单号码，以及订单的详细信息；

判断订单相似性模块，用于判断是否可以合并订单，定义一组规则或条件来确定订单之间的相似性，以确保合并的订单具有相似的特征；

合并订单模块，用于当确定了相似的订单，将相似的订单合并至同一个运单。

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