[转]库存那些事儿_2_货位系统_2
前篇中，介绍了三种逐次进化的货位系统的基本逻辑（其中最后一种是当前国内B2C公司使用较多的），也这三种货位系统存在的共同问题作了分析。对于这些共同问题，大部分公司采用加强现场运营管理的方法，尽量减少负面影响。但这只是治标，不能治本。
治本方式也有，我接触过两个，各有优缺点吧。不过，这两种方法的基本思想是类似的，都是将货位信息记录更进一步，记录货位上有什么产品，多少个。
先介绍第1个，将检货区、补货区分离开，并使用补货逻辑。
进阶版B中，产品与货位是多对多的关系。同一个SKU对应着多个Loaction，哪一个Location中有多少库存并不体现在系统中，导致了诸多缺点。在此基础上，设立检货区、补货区的概念，具体做法如下：
A. 库房分为检货区(Picking Location)和补货区(Storage Location)，检货操作只能在检货区进行，补货区用于存储大量货品，以及长尾末端的产品。检货区应对于订单出货需求，补货区应对大量存货，互为补充。系统上，也分为Storage Location和Picking Location两部分；
B. 货位系统增加数据项，除了Location、SKU外，增加Quantity项，例如补货区的库存记录表如下：
D. 检货区库存系统中增加安全库存数据项，当实际库存数量低于安全库存时，触发补货逻辑；检货区库存系统中增加最大库存数据项，用于判断补货数量；
E. 在检货区中，同一个SKU，只有一个Location；在补货区中，同一个SKU可以有多个Location；
F. 收货上架时，由系统根据检货区库存数量，生成上架任务。
该货位系统相当于两套库存并行运行，检货区用于满足最近一段时间的订单需求，存货区用于大量的存储和长尾商品的存储。两套库存之间，是单向传递的关系，传递的方式是补货。
G. 系统周期性判断相关产品的检货区库存数量、存货区库存数量、订单占用库存数量，触发补货逻辑。
与检货需求相关的库存的数量发生变化（包括检货区库存数量、存货区库存数量、订单占用库存数量）时，系统会生成补货的需求。
补货逻辑是这一套系统运行的核心，讲几个要点：
A. 哪些货放在检货区：
检货区是为了满足订单的快进、快出需求的，放在检货区中的产品，最大的特点就是在近期内会产生检货的需求。
WMS从哪里知道这些产品近期会产生检货需求呢？首先，根据历史的销售数据，对于产品的近期销售情况作预测；其次，根据当前的促销政策对于产品的近期销售情况作预测；最后，根据已经生成的订单，判断产品的检货需求。
B. 有两种情况补货：
一是收货上架时直接将一定的数量上到检货区，二是正常出货时，检货区的数量不够，从补货区将库存移动到检货区。
收货上架直接上货到检货区，这一情况应用较少，虚库存时候会使用到，另外热销产品的备货不足也会导致收货后直接上架到检货区。
从补货区移动库存，这是正常的逻辑。检货区的库存只保留一部分，应付两天（可以自由调整）的正常销售量。另外，在前面讲检货区的库存系统结构时，提到了两个数据项：Secure Qty和Max Qty，这两项是补货逻辑的基础。
C. 什么时候补货：
当货位的当前库存低于Secure Qty时，触发补货逻辑。Secure Qty是至少应该达到补货操作的这一段时间内的可能销售数量，一般会高于这个数字，提高安全系数。
长尾商品
D. 补多少货：
补货数量为Max Qty-当前货位库存+当前订单已经占用库存，如果补货区的库存低于这一数量，则将所有补货区的库存都补过去。
Max Qty为未来两天（该公司不同情况作调整）内该产品的销售数量预测。
E. 补货逻辑被触发后的操作：
补货逻辑被触发后，生成了某一产品的补货需求，一般是这样：
从补货区的某个货位，移动N个库存，到检货区的某个货位。
这与订单其实是有相似点的。一般情况下是会将补货的需求批量化处理。
对这个系统作一点分析吧：
优点：
1. 将库存数量与货位相绑定；
2. 基本解决了冗余信息的问题（系统自动定时清理Qty数量为0的记录即可）；
3. 单独设立检货区，可以提高检货的效率，因为检货的区域变小了；
4. 单独设立存货区，可以提高库存的容积率，因为可以使用立体式货位；
5. 盘点较为方便，一个产品在检货区只有一个货位；存货区和检货区的盘点可以分开进行；
缺点：
1. 系统逻辑非常复杂，首先需要为检货区、存货区分别建立库存表格，其次要根据这两部分的分割，将上架逻辑、检货逻辑、补货逻辑分别设计；
2. 前面所说的补货逻辑、检货逻辑信赖于产品的Secure Qty和Max Qty这两个参数，每个产品的参数需要单独设定；
3. 系统的整体表现对产品参数设置的信赖程度很高，以Secure Qty为例，过小会导致补货不及时，订单处理延误，过大则会导致浪费检货区的存储空间；
这是检货区与补货区分离的方式，还有一种方法，是完全的系统化管理，留待下次再写吧。
