A.系统架构相对简单：

　　这种货位系统只需要单独维护一张表格，表格中的数据项仅有两个，所有操作都只针对表格的信息行作处理，非常简单。

　　B.上架操作相对简单：

　　上架操作时，先查询是否原来已经存在货位，若已经有货位，则放到已有货位上，若没有，则新建货位。若原有货位上无法放下产品，则直接再找一个能放下的货位，将对应关系添加到表格中去。

　　C.成本低：

　　所有的操作（包括上架、检货、移货）都可以在电脑上完成，不需要采购专门的设备，成本很低。

　　但是不可避免地， 这一系统也有着非常大的缺点:

　　A.货位信息冗余不可避免：

　　这一点很好理解，例如Location N上面放了SKU N，后来在逐次出货的过程中，SKU N被一个个地检走了，最后Location N上面并没有SKU N了，但系统上仍然显示着SKU N在Location N上有货。这样的货位信息就是冗余信息，而且在日常的运营中根本无法避免。

　　B.检货效率受到影响：

　　在一个SKU存在于多个Location货人员需要自行判断到哪一个Location。若出现前一个货位信息冗余的问题，则有可能会让检货人员空跑一趟，这对检货效率的影响非常大。

　　C.盘点困难：

　　库房盘点时，一个SKU在多个货位，盘点时候需要跑来跑去，非常麻烦，且容易出错。

　　D.检货路径的低效：

　　在规模化的B2C企业中，检货是批量操作进行的，每一次检货会同时检出数十个订单，然后再进行分检。这也就意味着，检货员一次检货需要检出上百个SKU，这些SKU可能分布在库房的各个角落中，需要事先规划一条最优路径，以提高检货效率。但是在一个SKU存在多个Location下，检货人员有可能需要遍历所有的Location完成检货的任务，效率受到影响。

　　E.货出错率高：

　　基于该货位系统的检货过程完全是人工操作的，无系统检验，出错率较高。例如，在同一货位上，若摆放了类似的两个SKU，检货人员不小心就会检错。再例如，以批量检货时，检货员若漏检了某个SKU，则必须要等到分检时候才能够发现错误。

　　以上是一些主要问题，次要的不作过多描述。国内使用这一系统的公司，大多采用如下的方法来降低该库存系统的影响。

　　A.清理冗余信息：

　　定期对所有存在两个以上货位的SKU作核实，删除冗余的无用信息。

　　B.理货：

　　对货架上的产品作整理，例如将本段时间的热销品挪到货位体积较大的区域；将销售比较慢的产品挪到货位体积较小的区域，或者和别的产品放到同一个区域；或者是将分散在多个货位的同一个产品并到一起……

　　理货的操作是使得库存更加有序，提高检货的效率。

　　C.日常运营管理：

　　A)当某一产品的货位已经存在，并且货位上有库存时，尽量不新增货位；

　　B)原有货位无法放在所有库存时，可以找一个较大的货位，将所有的库存都放在其中，并删除原有货位；

　　C)类似的产品不放在同一货位；

　　逐次进化的货位系统的基本逻辑（其中最后一种是当前国内B2C公司使用较多的），也这三种货位系统存在的共同问题作了分析。对于这些共同问题，大部分公司采用加强现场运营管理的方法，尽量减少负面影响。但这只是治标，不能治本。

　　治本方式也有，各有优缺点吧。不过，这两种方法的基本思想是类似的，都是将货位信息记录更进一步，记录货位上有什么产品，多少个。

　　先介绍第1个，将检货区、补货区分离开，并使用补货逻辑。

　　进阶版B中，产品与货位是多对多的关系。同一个SKU对应着多个Loaction，哪一个Location中有多少库存并不体现在系统中，导致了诸多缺点。在此基础上，设立检货区、补货区的概念，具体做法如下：

　　A.库房分为检货区(Picking Location)和补货区(Storage Location)，检货操作只能在检货区进行，补货区用于存储大量货品，以及长尾末端的产品。检货区应对于订单出货需求，补货区应对大量存货，互为补充。系统上，也分为Storage Location和Picking Location两部分；