在倉庫現場操作過程中，會碰到各種各樣的問題，有些是容易解決的，有些是不太好處理的，現場人員還是得根據具體情況做好區分，哪些是經常性的問題，需要制定專門的流程進行對付，哪些是偶發性的問題，主要靠臨時調整來解決。

  訂單操作失誤造成的庫存管理問題

  一種是揀貨出錯導致的。揀貨過程當然難免會有一些錯誤，比如說，本來需要SKU代碼為A的貨物，結果錯拿了SKU代碼為B的貨物。

  一般的操作過程，是進行更換，如果是靈活庫位制，同一種SKU在存儲在多個不同庫位上，就比較麻煩了，這個A貨物我們當然知道要在哪個庫位揀貨，因為有揀貨單，但這個B貨物應該放回到哪個庫位呢?

  最準確的辦法是對所有庫位上的B貨物進行盤點，從而判斷應該歸還到哪里。但在緊張的現場操作過程中，這樣的盤點是極為耗時耗力的，而且在出入庫過程中，系統庫存和庫位上的實際庫存都在不斷變動，基本沒法進行盤點。

  這個問題的結果，就是系統庫存與實物庫存不能準確對應，那么就會有揀貨單要求到某個庫位揀貨，結果那個庫位沒有貨物的情況。

  而對這個問題的處理，有不同的思路：

  一種是不處理，直接放置在某個特定的暫存區，如果后面有庫位上找不到貨的情況，就到這個暫存區尋找，直到下一個盤點節點再把貨物放回庫位。

  一種是隨便放到一個存儲有該SKU的庫位上并進行記錄，等待下一次實物揀貨失敗再來查詢解決，一直等到下一個盤點節點完成實物數量與系統數量的重新準確對應。

  當然，相對根本一點的辦法，還是在揀貨時進行庫位與貨物條碼的掃描，掃描的過程，一個是系統上的進出確認，一個是對SKU正確與否的復核，那么出錯率自然可以控制在一個非常小的區間，只是這個辦法并不是在每一個倉庫都有可操作性。

  訂單本身錯誤導致的問題

  尤其在人工下單過程中，不可避免地會有出錯的時候，如果是需求100個，結果下單寫成1個，對倉庫是沒有太大影響的，無非是后期可能需要處理一個緊急訂單;如果是需求1個，結果下單寫成100個，現場就比較頭疼了，可能總體庫存不足，那么，這邊錯誤的需求滿足了，其它99個訂單的需求就無法滿足了，后果很嚴重。

  同樣的問題，也可能因為供應短缺造成，比方說，某種SKU暫時供應不上，需要在不同門店間進行平均分配，待后續供應上之后再緊急補充，而這個信息只有倉庫人員掌握，下單人員是不掌握的。正常來說，系統匹配庫存的邏輯，是先匹配的訂單先滿足，這個邏輯解決不

  了平均分配的問題。

  這個問題的處理一般有兩種辦法：

  一種是修改訂單，那么問題來了，除非比較有經驗的操作人員，可能在整個過程中現場都不會發現有什么問題，或者說，發現問題的時候，大多數訂單都已經處理完成了，這個時候再修改訂單已經沒有意義了。

  所以，有些現場會有人工審核訂單的動作，雖然低效繁瑣，但在下單操作極不規范的情況下，是滿足客戶需求一個不得不采取的辦法。當然，審核訂單的工作，逐步可以通過系統來完成，通過對歷史訂單數據的統計，判定一個需求是否在正常范圍內并不是非常困難，只

  是未免有殺雞用牛刀之感。

  另一種是后期針對單個SKU進行退回和重新下單，在實際貨物出庫之前，這種操作終歸是為時未晚的，不過對于WMS的設計要求比較高。

  當然，隨著系統在上下游的集成度越來越高，這個問題也就逐步得到解決了，一方面是供應商對于需求量有了更準確的把握。

  另一方面，下單過程也越來越自動化，下單人員只需要確定一定期間內需要維持的庫存量就可以了，訂單數據都可以自動生成。

  從這兩個庫存管理問題來看，我們對于倉儲過程的信息化是充滿期望的——在一些技術細節上，我們往往能很明確地看到未來在哪里，只是還差一步步走過去。

  本文來源于SmartWMS智慧倉儲管理系統 ，不代表九州物流網(http://www.ruyi818.com)觀點，文章如有侵權可聯系刪除