在仓库现场操作过程中，会碰到各种各样的问题，有些是容易解决的，有些是不太好处理的，现场人员还是得根据具体情况做好区分，哪些是经常性的问题，需要制定专门的流程进行对付，哪些是偶发性的问题，主要靠临时调整来解决。
订单操作失误造成的库存管理问题
一种是拣货出错导致的。拣货过程当然难免会有一些错误，比如说，本来需要SKU代码为A的货物，结果错拿了SKU代码为B的货物。
一般的操作过程，是进行更换，如果是灵活库位制，同一种SKU在存储在多个不同库位上，就比较麻烦了，这个A货物我们当然知道要在哪个库位拣货，因为有拣货单，但这个B货物应该放回到哪个库位呢?
最准确的办法是对所有库位上的B货物进行盘点，从而判断应该归还到哪里。但在紧张的现场操作过程中，这样的盘点是极为耗时耗力的，而且在出入库过程中，系统库存和库位上的实际库存都在不断变动，基本没法进行盘点。
这个问题的结果，就是系统库存与实物库存不能准确对应，那么就会有拣货单要求到某个库位拣货，结果那个库位没有货物的情况。
而对这个问题的处理，有不同的思路：
一种是不处理，直接放置在某个特定的暂存区，如果后面有库位上找不到货的情况，就到这个暂存区寻找，直到下一个盘点节点再把货物放回库位。
一种是随便放到一个存储有该SKU的库位上并进行记录，等待下一次实物拣货失败再来查询解决，一直等到下一个盘点节点完成实物数量与系统数量的重新准确对应。
当然，相对根本一点的办法，还是在拣货时进行库位与货物条码的扫描，扫描的过程，一个是系统上的进出确认，一个是对SKU正确与否的复核，那么出错率自然可以控制在一个非常小的区间，只是这个办法并不是在每一个仓库都有可操作性。
订单本身错误导致的问题
尤其在人工下单过程中，不可避免地会有出错的时候，如果是需求100个，结果下单写成1个，对仓库是没有太大影响的，无非是后期可能需要处理一个紧急订单;如果是需求1个，结果下单写成100个，现场就比较头疼了，可能总体库存不足，那么，这边错误的需求满足了，其它99个订单的需求就无法满足了，后果很严重。
同样的问题，也可能因为供应短缺造成，比方说，某种SKU暂时供应不上，需要在不同门店间进行平均分配，待后续供应上之后再紧急补充，而这个信息只有仓库人员掌握，下单人员是不掌握的。正常来说，系统匹配库存的逻辑，是先匹配的订单先满足，这个逻辑解决不
了平均分配的问题。
这个问题的处理一般有两种办法：
一种是修改订单，那么问题来了，除非比较有经验的操作人员，可能在整个过程中现场都不会发现有什么问题，或者说，发现问题的时候，大多数订单都已经处理完成了，这个时候再修改订单已经没有意义了。
所以，有些现场会有人工审核订单的动作，虽然低效繁琐，但在下单操作极不规范的情况下，是满足客户需求一个不得不采取的办法。当然，审核订单的工作，逐步可以通过系统来完成，通过对历史订单数据的统计，判定一个需求是否在正常范围内并不是非常困难，只
是未免有杀鸡用牛刀之感。
另一种是后期针对单个SKU进行退回和重新下单，在实际货物出库之前，这种操作终归是为时未晚的，不过对于WMS的设计要求比较高。
当然，随着系统在上下游的集成度越来越高，这个问题也就逐步得到解决了，一方面是供应商对于需求量有了更准确的把握。
另一方面，下单过程也越来越自动化，下单人员只需要确定一定期间内需要维持的库存量就可以了，订单数据都可以自动生成。
从这两个库存管理问题来看，我们对于仓储过程的信息化是充满期望的——在一些技术细节上，我们往往能很明确地看到未来在哪里，只是还差一步步走过去。
本文来源于SmartWMS智慧仓储管理系统 ，不代表九州物流网(http://www.wl890.com)观点，文章如有侵权可联系删除