前言
WMS的移库功能在不同的仓库或者不同的系统定义不一样，有些地方把移库当成两个仓库间货物的转移，有些地方把移库当成不同的库区间的货物转移，例如从拆零区到整箱区，或者从高货值区转移到低货值区等。
但是本文所提到的移库其实就是指货位（库位）间转移，将货物从库位A移库到仓位B，然后库位A的货品扣减数量，仓位B的货品增加数量。
看似很简单的功能，但是结合到实际业务中，也让我踩了挺多坑。所以我特地花了一些时间整理出此篇文章，复盘一下我在设计该功能的时候遇到了哪些问题，收获了哪些感悟。
那么，我们开始吧。
简易版的移库
很多海外仓没有做效期管理，也没有做批次管理，所以基本上对货物的管控粒度都是在SKU层面。如果是SKU层面的移库，只需要将源库位的SKU扣减数量，然后转移到目标库位上，SKU对应的的增加数量即可。
简易版的移库主要是因为管理粒度在SKU，所以在移库的时候，只需要判断目标库位的货主和料区是否和源库位一致，只要一致就可以移库，没有其他额外的判断逻辑。
货主为什么要一致？ 这个各个仓库的管理要求不一样，我们不允许一个库位放两个货主的货物是因为两个货主的货物可能会一样（你卖iPhone，我也可以卖iPhone），为了避免这种货物识别可能带来的风险，所以我们是只允许一个库位放一个货主的货物的。
料区是什么？为什么要一致？ 这个也和仓库的管理要求有关系，有些仓库对货物的品质管控只要求区分良品，残次品或者其他粒度。而我们对品质的管控要求细一些，除了要求好坏之分的话，还会有更细的粒度。例如退货回来的货物区分售后良品，售后不良品；所以一个库位只能放一个料区的货物，将良品放在一起，残次品放在另外的库位，那么移库的时候，一个良品库位的货物也就只能移库到其他良品的库位上了。
业务升级，引入批次概念
批次是仓库对货品的管理粒度还要再细一层，要精确到批次号（批号）上。批号这个概念在医药WMS中很常见，大家身边如果有药品盒子可以查看一下，一般来说药品上都会印有生产批号，如下图所示：
一般来说产品上有批号信息的商品其实还算方便管理，毕竟有个显眼的标识让你去查看。但是如果有些商品没有批号展示，但是又需要进行批次管理，那么难度就显然高了一些。
业内通用的做法有两种：
而往往大多数仓库采用的，就是第二种。
今天仓库收到了100箱维他柠檬茶，SKU为vita100，这100箱维他柠檬茶都是一年后过期。然后在系统在生成上架单的时候，会对这些产品自动标记一个批次号，例如就叫做BN20200725001。
过了两天仓库又收到了50箱维他柠檬茶，SKU还是vita100，但是这50箱维他柠檬茶是半年后就过期。在系统在生成上架单的时候，还是会对这些产品自动标记一个批次号，例如就叫做BN20200727001。
所以在系统中，就会知道一共有150箱维他柠檬茶，一共有两个批次，批次号BN20200725001的是100箱，批次号BN20200727001的是50箱。
如果仓库不要求对批次进行管控，那么这150箱的维他柠檬茶就是可以放在同一个库位的，到时出库的时候也就可以随机拣货出库了。
这个也就是为什么一些电商网站会说新老包装随机发货的原因，因为在仓库管理的时候新老包装都是同一个SKU，没有做批次管理，所以新老包装就放在一起了，拣货的时候就随机拿了。
如果仓库要求对批次进行管控，那么系统的功能设计上就要复杂一些了，因为批次管控意味着不能混批次（一个库位上不能放不同批次的同款商品）。上面提到，一般仓库不会采用重新贴码的方式来管理批次，所以都是用的第二种，也就是跟踪批次号对应的仓位的方式来管理。
那么之前的批次号为BN20200725001的100箱维他柠檬茶就应该放在一个库位，而BN20200727001的50箱应该放在另外一个库位，两者不能重叠。所以上架的时候应该要对批次号做限制，某个仓位有该产品的批次了，那么其他批次就不能放上去了。
此时如果我们加大业务量，一天同时入库10个货主，100款SKU，大概有400多个批次，而且这些产品中，有些需要效期管理，有些需求批次管理，有些只需要SKU管理，这个时候如果没有一套完善的批次管理机制就容易出问题了。
业务继续升级，效期，批次和普货同时管理
效期管理，就是针对商品的有效期（保质期）进行管理，仓库不能把一些过期了或者临近过期的产品发出去，否则会造成比较严重的损失。
批次管理，就是针对商品的出厂批次或者入库先后的批次做管理，一般会用来做先进先出，提升产品的周转率，同时也能尽量把老款卖出去，也方便来算库龄和仓租。
普货管理，就是普通的产品，不需要做批次管理，也不需要做效期管理，可以直接在SKU的粒度上进行管理，无论是先到的还是后到的，都可以直接叠放在同一个库位上。
针对这三类的产品，其实是有共性可以作为突破口的，那就是批次号。无论你是什么类型的产品，我都给你加上一个批次，这个批次可以理解为SKU的策略。因为批次号需要与库位进行关联，即某个SKU的某个批次号的货物放在了某个库位上。所以我们需要对库位也做一个策略的管理，就是商品是否混放与批次是否混放。
将SKU的策略和库位的策略结合在一起，来切割我们不同的产品的管理要求和粒度。
对于SKU的策略来说，可以分为需要批次管理和不需要批次管理，需要批次管理的是批次产品和效期产品，而不需要批次管理的则是普货。效期产品虽然重点关注的是失效日期，但是本质上来说还是属于批次的管理，不同的失效日期的可以理解成不同的批次号。
对于库位的策略来说，就是分为商品混放且批次混放，商品混放且批次不混放，商品不混放且批次混放，商品不混放且批次不混放，一共四种情况。一般来说海外仓用的最多的就是商品不混放且批次混放，就是一个SKU都放在一个库位上；而对于一些生鲜产品或者效期产品来说，用的比较多的就是商品混放且批次不混放。
所以一个SKU的上架，大概来说可能会有8种判断条件，如果把效期产品的单独算作一种策略，那么就会有12种判断条件。
说回移库
踩坑一：说移库只想到了移库
本文的主题是讲移库，但是我在梳理流程的时候发现我之前踩了一个很大的坑，那就是我在设计移库的功能的时候，只想到了移库，我重点在关注移库的一些操作和策略上。
但是回顾一下，其实移库的本质依然是上架，只是包装了一层外衣。难点其实依然是在上架的时候对SKU和库位策略的判断，如果只盯着移库去设计，很容易走进死胡同，发现怎么设计都会有欠缺，都是只见树木不见森林。
踩坑二：上架的方式与逻辑判断的方式
除了一开始踩进了移库这一个牛角尖的坑之外，还有一个很重要的坑，那就是关于上架的方式和逻辑判断的方式也碰壁了。
按常规来讲，移库应该是会涉及到同时移库多个产品的，这也意味着上架的时候会上架多个产品，现实的上架确实也会如此。
然后我在考虑SKU策略和仓位策略的时候就犯难了，例如一个库位的策略是商品不混放且批次混放，那么我在上架的时候得要先考虑我待上架的产品首先有没有混放（意思是自身有没有混）。如果没有混，那么放上去的时候又要考虑已有的产品和要放上去的产品是否混放。如果这个也没有混，最后再判断批次是否混放，直到都满足才可以上架。
这样一来，如果一次性上架很多个SKU，那么商品不混放的库位压根就上不了。如果在移库的时候，仓库发现这个库位上去了，那个也上不了，很容易就崩溃，效率也不高。
然后我就在开始思考，是不是要先考虑移库的时候源库位和目标库位的库位属性是否一致，是否要区分普通货物移库和批次货物移库。顺着这个思路，我就踩了第三个坑。
踩坑三：思考的方向变成了源库位和SKU
因为考虑到不同的产品和仓位策略上架的逻辑判断太多，我本能的觉得这样肯定不对，所以我决定把思路放在源库位和SKU上试试。
移库前先比对两者的库位策略是否一致，不一致就不允许移库了，如果一致才可以移库。但是这样还是会有一个问题，那就是本来库位的策略大家都是不允许商品混放，但是因为新的SKU移库过来了，那么就打破了本来的库位策略，所以判断条件还是有那么多。
于是我继续思考是不是还要先考虑SKU的组合的问题，例如移库只能一次移库一个，这样的话判断的时候就可以很容易的将待移库的SKU和目标库位的SKU进行对比，看看是否有没有破坏目标库位的策略。这样的话，判断条件确实是简单了一些，说明这思路是对的。
但是如果普通上架或者容器上架的时候，面临同时有多个SKU的时候怎么办？这个办法还是很麻烦，而且感觉不对劲，于是我将我的思考结果和疑惑点记录下来，跟我们的开发大佬沟通了一下，这才解开了我的疑惑。
解惑时刻
当我把记录的疑惑跟开发大佬沟通的时候，他指出了一个很重要的点，也是我一直思考碰壁的地方：移库的本质其实也是上架的策略，而上架的策略其实就是上架一个SKU判断一次策略！
这句话直接给了我解题的思路，瞬间打通了之前闭塞的环节，而且他还告诉我在前两天的时候他其实都已经理出来了逻辑而且核心代码都写好了，只不过这个是上架的策略，而我当时没有关注还心扑在移库上（直接碾压，尴尬）。
然后我们一起就着他画出来是思维导图进行了一波推演，发现这个方案确实是正确的，而且是通用型的，很多我没有想通的点，其实就是因为我踩了坑。
对着上方的逻辑图再走一遍流程会发现，不论是移库还是上架其实本质都是上架策略的判断，这是可以通用的。
首先判断货主和料区是否一致，这个前面提到过，属于常规性必做的判断。
其次判断商品混放策略，上面讲到了每次上架都判断一次这个逻辑，所以并不需要考虑本身待上架的产品内部是否混放的问题。商品混放策略直接拿待上架的这个SKU和已经在库位上的SKU判断即可，如果可以通过则进行下一个批次策略的判断。
在判断批次策略的时候先判断SKU的自身的策略，是否批次管理还是普货，如果是批次管理，那么就只能放在不允许混放批次的库位，然后再判断待上架的批次和已上架的批次是否相同；如果是普货，则任意都可以放。
上面的逻辑分析图基本上就可以覆盖所有的与上架策略有关的场景，理清楚了核心的业务逻辑，剩下的就是一些锦上添花的辅助工作了。
总结
本来一开始的工作任务是对移库功能进行优化和调整，但是随着业务的演变，一些规则和要求的加入之后，移库变得不是那么简单就能搞定的了。本以为是一次简单的业务逻辑调整，但是碰壁之后才发现原来是我自己对一些本质的东西没有抓住。
通过这次小小的复盘，让我get到了这么些感悟，分享给大家：