今天我們來探討一個讓我們比較頭疼的問題： 即當我們在處理訂單時，庫存出現問題的狀況。
一般來說，產生這類狀況的原因有兩種：
一種是揀貨出錯導致的，即我們倉庫方這邊自己出現了問題。另一種是訂單本身有問題，即采購方面出現的問題。
以下分別討論兩種情況不同的處理方式：
先說揀貨導致的庫存問題
揀貨過程當然難免會有一些錯誤，比如說，本來需要sku代碼為a的貨物，結果錯拿了sku代碼為b的貨物。
一般的操作過程，是進行更換，如果是靈活庫位制，同一種sku在存儲在多個不同庫位上，我們就比較頭疼了，這個a貨物我們當然知道要在哪個庫位揀貨，因為有揀貨單，但這個b貨物應該放回到哪個庫位呢?
最準確的辦法是對所有庫位上的b貨物進行盤點，從而判斷應該歸還到哪里。但在緊張的現場操作過程中，這樣的盤點是極為耗時耗力的，而且在出入庫過程中，系統庫存和庫位上的實際庫存都在不斷變動，基本沒法進行盤點。
這個問題的結果，就是系統庫存與實物庫存不能準確對應，那么就會有揀貨單要求到某個庫位揀貨，結果那個庫位沒有貨物的情況。而對這個問題的處理，有不同的思路：
一個是不處理，直接放置在某個特定的暫存區，如果后面有庫位上找不到貨的情況，就到這個暫存區尋找，直到下一個盤點節點再把貨物放回庫位。
一個是隨便放到一個存儲有該sku的庫位上并進行登記，等待下一次實物揀貨失敗再來查詢解決，一直等到下一個盤點節點完成實物數量與系統數量的重新準確對應。
當然，相對根本一點的辦法，還是在揀貨時進行庫位與貨物條碼的掃描，掃描的過程，一個是系統上的進出確認，一個是對sku正確與否的復核，那么出錯率自然可以控制在一個非常小的區間，只是這個辦法并不是在每一個倉庫都有可操作性。
訂單出錯導致的庫存問題
在人工下單過程中，不可避免地會有出錯的時候。同樣的問題，也可能因為供應短缺造成，比方說，某種sku暫時供應不上，需要在不同門店間進行平均分配，待后續供應上之后再緊急補充，而這個信息只有倉庫人員掌握，下單人員是不掌握的。
正常來說，系統匹配庫存的邏輯，是先匹配的訂單先滿足，這個邏輯解決不了平均分配的問題。
這個問題的處理一般有兩種辦法：
一種是修改訂單，除非比較有經驗的操作人員，可能在整個過程中現場都不會發現有什么問題，或者說，發現問題的時候，大多數訂單都已經處理完成了，這個時候再修改訂單已經沒有意義了。
所以，有些現場會有人工審核訂單的動作，雖然低效繁瑣，但在下單操作極不規范的情況下，是滿足客戶需求一個不得不采取的辦法。當然，審核訂單的工作，逐步可以通過系統來完成，通過對歷史訂單數據的統計，判定一個需求是否在正常范圍內并不是非常困難，只是太過于浪費資源了。
另一種是后期針對單個sku進行退回和重新下單，在實際貨物出庫之前，這種操作終歸是為時未晚的，不過對于信息化系統的設計要求比較高。
隨著系統在上下游的集成度越來越高，這個問題未來也稱不上是真正的問題了。
因為下單過程越來越自動化，下單人員只需要確定一定期間內需要維持的庫存量就可以了，訂單數據都可以自動生成。
本文來源于smartwms智慧倉儲管理系統，不代表本站觀點，如有侵權可聯系刪除，文章所用圖片來源于網絡，文章圖片如有侵權可聯系刪除。