一种订单拆分方法和装置.pdf

本发明提供一种订单拆分方法和装置，能够在有特殊的商品需要单拆分出来的时候，无需进行特殊的逻辑处理，只要在已有的业务逻辑上增加新拆分要求即可，克服了需要不断修改已有业务逻辑的缺点，减少了已有业务逻辑出现崩溃的风险，提高了系统的稳定性，有利于系统和业务的扩展。本发明的订单拆分方法包括：在已有的拆分维度节点中，保存根据业务需求增加的拆分维度节点；在已有的拆分模型基础上，加入包括所述增加的拆分维度节点的拆分模型，以构造得到动态业务拆分模型；根据订单中的商品信息以及所述动态业务拆分模型，对订单进行拆分。

1.  一种订单拆分方法，其特征在于，包括：
在已有的拆分维度节点中，保存根据业务需求增加的拆分维度节 点；
在已有的拆分模型基础上，加入包括所述增加的拆分维度节点的 拆分模型，以构造得到动态业务拆分模型；
根据订单中的商品信息以及所述动态业务拆分模型，对订单进行 拆分。

2.  根据权利要求1所述的方法，其特征在于，所述拆分维度节点 包括如下一种或多种：库房号、商家标识、机构号、商品类型、以及 库存状态。

3.  根据权利要求1或2所述的方法，其特征在于，所述根据业务 需求增加的拆分维度节点包括商品通用维度标识。

4.  根据权利要求3所述的方法，其特征在于，所述商品通用维度 标识为多位的字符串，每一位用于标识不同的业务需求。

5.  根据权利要求1或2所述的方法，其特征在于，
所述增加的拆分维度节点的拆分模型为：一个单独包括已增加拆 分维度节点的拆分模型；
或者，所述增加的拆分维度节点的拆分模型为：既包括已增加的 拆分维度节点，又包括订单中的商品信息所含有的维度节点的拆分模 型。

6.  一种订单拆分装置，其特征在于，包括：
保存模块，用于在已有的拆分维度节点中，保存根据业务需求增 加的拆分维度节点；
构造模块，用于在已有的拆分模型基础上，加入包括所述增加的 拆分维度节点的拆分模型，以构造得到动态业务拆分模型；
拆分模块，用于根据订单中的商品信息以及所述动态业务拆分模 型，对订单进行拆分。

7.  根据权利要求6所述的装置，其特征在于，所述拆分维度节点 包括如下一种或多种：库房号、商家标识、机构号、商品类型、以及 库存状态。

8.  根据权利要求6或7所述的装置，其特征在于，所述根据业务 需求增加的拆分维度节点包括商品通用维度标识。

9.  根据权利要求8所述的方法，其特征在于，所述商品通用维度 标识为多位的字符串，每一位用于标识不同的业务需求。

10.  根据权利要求6或7所述的方法，其特征在于，
所述增加的拆分维度节点的拆分模型为：一个单独包括已增加拆 分维度节点的拆分模型；
或者，所述增加的拆分维度节点的拆分模型为：既包括已增加的 拆分维度节点，又包括订单中的商品信息所含有的维度节点的拆分模 型。

一种订单拆分方法和装置
技术领域
本发明涉及计算机技术领域，特别地涉及一种订单拆分方法和装 置。
背景技术
随着电子商务的发展不断的复杂和扩大，订单拆分成为大型电子 商务公司订单生产过程中不可缺少的一个环节，对于开放式B2C电子 商务来说用户下了不同商家的订单是需要拆分来开的，对于自营式B2C 电子商务来说更是如此。
比如，用户下了一个混合订单，订单中有书，有手机，有衣服等 不同品类(图书、3C、百货)的商品，而事实上这些商品根据库房划 分的不同会存放在不同地理位置和区域中，比如书，可能会是在图书 仓库，手机在3C仓库，衣服又在百货仓库，而这些仓库在实际情况中 不一定是在同一个区域，那么这样就需要系统在订单到达库房进行生 产之前按照库房分布不同进行拆分，以便保证来自不同库房商品的订 单能够正确流转到下游的对应的库房或者第三方商家中进行生产打包 和配送。
上面说的其实只是用户下单后需要根据订单中商品的商家不同库 房分布不同进行订单拆分的情况，就是按照商家维度、库房的维度进 行订单拆分，就是说商家标识、库房号是订单进行拆分的不同维度， 而在实际的订单生产流程中会有很多的自身条件需要对订单进行拆 分，比如机构号，商品是否是现货等物理条件进行限制，而系统就是 通过这些条件将订单拆分开来。
对于订单拆分，现有的技术方案通常采用基于固定拆分维度技术 方案进行拆分：
通过相关业务要求去构建一个拆分模型，这个模型中包含了基本 拆分固有维度，这个拆分固有维度是指本身对于拆分而言是有实际意 义，比如商品的库房号，商品的库存状态这都是有意义的；通过对订 单中的每个商品进行遍历，进行填充该拆分模型所包含的拆分维度， 这样每个商品都有了自己的拆分模型的实例，最后系统进行模型实例 的比对，如果模型实例相同则是一单，反之会有多单。其工作流程如 图1所示：
订单原始信息模块：主要进行订单拆分之前的数据整理，这里系 统会从用户下的原始订单中得到一些订单数据详情，比如商品及数量， 使用的优惠以及金额等等，这些数据中会包含拆分所关注的一些直接 维度，比如库房号，商家编号等信息，为订单拆分做准备；
商品的拆分模型构造模块：主要是进行构建每个商品的拆分模型 实例，根据相关人员定义好的拆分模型和系统得到的每个商品的信息 进行填充拆分模型，为下一步准备；
商品的模型对比模块：主要是对上一步形成的一个每个商品的拆 分模型实例进行比较，如果一样的话就是一堆，否则会有很多堆；
拆分结果的确定模块：根据上一步的分堆的结果，进行拆分结果 的构造和确定。
随着订单业务的不断发展，系统除了需要按照商品本身具备的属 性进行拆分后，同时也需要按照很多业务上的规则对订单进行拆分， 比如要求某种商品只能是一个商品是一单的，还有同一个订单不同商 品的配送方式不一样，甚至是商家特殊的促销也是需要进行拆分的等 等情况。
如按照现有技术方案对订单进行拆分会存在这样的问题，就是固 有的拆分维度无法适应满足新的业务扩展：因为固有的拆分模型不会 考虑到新的业务将会带来的拆分维度，而且每个业务所定义的维度也 不可能是相同意义的。而随着业务不断增加和扩展，对于拆分的逻辑 也在趋于复杂和拆分粒度会更大，就是可能会存在这样的问题：对于 原来拆分完的一个订单，新的业务会导致该订单的进一步拆分，比如 一个订单有两本书，一个手机这三个商品，按照现有的方式进行拆分 的话，根据库房不同会拆分成两单，两本书在同一个库房是一单，手 机是一单，但可能存在一个业务或者特殊要求其中的一本图书必须是 一单一货，也就是说系统还需要将这两本书拆分开，最后是三单。那 么对于上面这种情况按照已有维度是无法拆分处理的，不能拆分到底 的，显然已有的拆分方案无法很好的解决这样的问题，这样就需要系 统在拆分结果的基础上对订单再次进行特殊的处理，比如上面的情况 如果发现订单中有特殊的商品需要单拆分出来，进行特殊的逻辑处理， 需要在已有的业务逻辑上增加新拆分要求，就会存在不断修改已有业 务逻辑的缺点，会增加已有业务逻辑出现崩溃的风险，会降低系统的 稳定性，不利于系统和业务的扩展。
发明内容
有鉴于此，本发明提供一种订单拆分方法和装置，能够在有特殊 的商品需要单拆分出来的时候，无需进行特殊的逻辑处理，只要在已 有的业务逻辑上增加新拆分要求即可，克服了需要不断修改已有业务 逻辑的缺点，减少了已有业务逻辑出现崩溃的风险，提高了系统的稳 定性，有利于系统和业务的扩展。
为实现上述目的，根据本发明的一个方面，提供了一种订单拆分 方法。
本发明的订单拆分方法包括：在已有的拆分维度节点中，保存根 据业务需求增加的拆分维度节点；在已有的拆分模型基础上，加入包 括所述增加的拆分维度节点的拆分模型，以构造得到动态业务拆分模 型；根据订单中的商品信息以及所述动态业务拆分模型，对订单进行 拆分。
可选地，所述拆分维度节点包括如下一种或多种：库房号、商家 标识、机构号、商品类型、以及库存状态。
可选地，所述根据业务需求增加的拆分维度节点包括商品通用维 度标识。
可选地，所述商品通用维度标识为多位的字符串，每一位用于标 识不同的业务需求。
可选地，所述增加的拆分维度节点的拆分模型为：一个单独包括 已增加拆分维度节点的拆分模型；
或者，所述增加的拆分维度节点的拆分模型为：既包括已增加的 拆分维度节点，又包括订单中的商品信息所含有的维度节点的拆分模 型。
根据本发明的另一方面，提供了一种订单拆分装置。
本发明的订单拆分装置包括：保存模块，用于在已有的拆分维度 节点中，保存根据业务需求增加的拆分维度节点；构造模块，用于在 已有的拆分模型基础上，加入包括所述增加的拆分维度节点的拆分模 型，以构造得到动态业务拆分模型；拆分模块，用于根据订单中的商 品信息以及所述动态业务拆分模型，对订单进行拆分。
可选地，所述拆分维度节点包括如下一种或多种：库房号、商家 标识、机构号、商品类型、以及库存状态。
可选地，所述根据业务需求增加的拆分维度节点包括商品通用维 度标识。
可选地，所述商品通用维度标识为多位的字符串，每一位用于标 识不同的业务需求。
可选地，所述增加的拆分维度节点的拆分模型为：一个单独包括 已增加拆分维度节点的拆分模型；
或者，所述增加的拆分维度节点的拆分模型为：既包括已增加的 拆分维度节点，又包括订单中的商品信息所含有的维度节点的拆分模 型。
根据本发明的技术方案，能够在有特殊的商品需要单拆分出来的 时候，无需进行特殊的逻辑处理，只要在已有的业务逻辑上增加新拆 分要求即可，克服了需要不断修改已有业务逻辑的缺点，减少了已有 业务逻辑出现崩溃的风险，提高了系统的稳定性，有利于系统和业务 的扩展。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是根据现有技术的拆分模型流程图；
图2是根据本发明实施例的订单拆分方法示意图；
图3是根据本发明实施例的订单拆分装置示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发 明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。 因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做 出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清 楚和简明，以下的描述中省略了对公知功能和结构的描述。
图2是根据本发明实施例的订单拆分方法示意图。如图2所示， 该方法主要包括如下的步骤S20至S22。
步骤S20：在已有的拆分维度节点中，保存根据业务需求增加的拆 分维度节点。其中，已有的拆分维度节点包括如下一种或多种：库房 号、商家标识、机构号、商品类型、以及库存状态等等；这些维度是 可以人工按照实际业务需求添加到程序中的。而增加的拆分维度节点 是从业务需求中提取出来的，比如有一个新的业务要求只要是买a商品 时就必须是一单一品，也就是说只要订单中包含了a商品的时候就需要 把a商品单独拆分成一单，这就是一个业务需求。那么针对系统而言， 相关人员会把业务需求转换为系统的规则，去满足这样的业务。相关 人员可以通过增加一个商品通用维度标识对业务需求进行标识；比如 skuMark是增加的一个商品通用维度标识，设定为一个字符串00000。 当业务需求所对应的商品出现时，系统可以根据相关人员的设定，将 设定的字符串修改为10000；那么只要看到商品通用维度标识skuMark 第一位是1的话，就代表是针对上面的这种业务需求所操作的；因此， 商品通用维度标识skuMark就是根据新的业务需求所增加的拆分维度 节点。
步骤S21：在已有的拆分模型基础上，加入包括所述增加的拆分维 度节点的拆分模型，以构造得到动态业务拆分模型。
比如有一个用户下原始订单A，包括b、c和d三个商品，其中b 和c是图书，d是电脑；按照原来固有拆分模型的拆分方式，由于库房 不同，原始订单A被拆分成了两单：图书一单电脑一单。
如果现在新业务规定c商品必须是单独一单，那么按照原来固有拆 分模型的拆分方式就很难将原始订单A进行彻底的拆分；因此，应该 根据新的业务需求，在已有的拆分维度节点中增加拆分维度节点。
针对新业务，可以在已有的拆分模型基础上，在系统中添加一个 单独包括已增加拆分维度节点的拆分模型；或者结合原始订单A中的 商品信息，在系统中添加一个既包括已增加的拆分维度节点，又包括 订单中商品所含有的其他维度节点的拆分模型；从而构造得到动态业 务拆分模型。比如，增加了一个商品通用维度标识skuMark，这个商品 通用维度标识是根据业务需求增加的，当有特定的业务时，就通过增 加的商品通用维度标识对特定业务进行标记。商品通用维度标识 skuMark设定为一个字符串如00000，那么所加入的包含商品通用维度 标识的拆分模型可以定义为只要发现商品是c商品，系统就将商品通用 维度标识skuMark的值修改为10000，而b商品还是00000，这样的话 对于b商品和c商品就区分开了，最后也就将订单A拆分彻底了。
步骤S22：根据订单中的商品信息以及所述动态业务拆分模型，对 订单进行拆分。根据订单中的商品信息以及动态业务拆分模型对拆分 模型进行填充，形成订单中商品的拆分模型实例。当订单中的一个商 品将所有的拆分模型执行完成，就会形成了一个完整的商品拆分模型 实例，也就是将这个商品划分为最细维度，最终得到对应于商品的拆 分序列号。当订单中的每个商品都经过这样的操作后，会得到每个商 品的拆分模型实例，从而得到订单中所有商品的拆分序列号；系统判 断每个商品的拆分序列号是否相同，如果相同，则把相同的商品归为 一堆，不相同的话就归为不同的堆，最后根据分堆的结果得到订单的 拆分结果。
图3是根据本发明实施例的订单拆分装置示意图。如图3所示， 本发明实施例的订单拆分装置30主要包括保存模块31、构造模块32、 以及拆分模块33。保存模块31在已有的拆分维度节点中，保存根据业 务需求增加的拆分维度节点；构造模块32在已有的拆分模型基础上， 加入包括所述增加的拆分维度节点的拆分模型，以构造得到动态业务 拆分模型；拆分模块33根据订单中的商品信息以及所述动态业务拆分 模型，对订单进行拆分。
根据本发明实施例的技术方案，可以根据业务需求去动态的构造 业务拆分的模型进行拆分处理，在有特殊的商品需要单拆分出来的时 候，无需进行特殊的逻辑处理，只要在已有的业务逻辑上增加新拆分 要求即可，克服了需要不断修改已有业务逻辑的缺点，减少了已有业 务逻辑出现崩溃的风险，提高了系统的稳定性，有利于系统和业务的 扩展。
以上结合具体实施例描述了本发明的基本原理，在本发明的装置 和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些 分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处 理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要 一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域 技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种 各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内 所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。