5000字拆解WMS中“暫存庫位”的功能和作用
在現代供應鏈管理中,倉庫管理系統(WMS)扮演著至關重要的角色。其中,“暫存庫位”作為一個特殊的概念,對于提高倉庫操作的效率和準確性具有深遠的影響。本文深入探討了“暫存庫位”的功能、作用以及在不同業務場景下的應用,揭示了它在復雜和成熟WMS中的重要性。
在一些復雜的、成熟的WMS中(例如富勒WMS)會有一個“過渡庫位”的概念,也可以理解為“暫存庫位”。意思就是說這個庫位是在倉庫的操作過程中臨時使用的庫位,用來過渡、暫存一下。
例如說,收貨完成之后,貨物會先暫時存放在過渡庫位(STAGE1),然后等要上架的時候再從過渡庫位轉移到具體的存儲庫位中。
同樣的道理,當揀貨完成之后,貨物會從存儲庫位中下架,然后也暫時存放在過渡庫位(STAGE2),等真正的出庫之后,再從過渡庫位中扣減庫存。
收貨過渡庫位和揀貨過渡庫位
當我們去研究海外倉WMS的競品時,可能會發現幾乎大多數的SaaS海外倉WMS或是自研型的海外倉WMS都沒有設計“暫存庫位”這個概念,但是依然可以正常將業務流程運轉起來。那么在實際的產品設計過程中,我們到底是選擇用“暫存庫位”,還是選擇不用,這兩者都什么區別,有什么差異呢?
接下來,我拋出幾個比較常見的業務問題或者是產品設計的場景問題,我們嘗試用不同的解決方案去解決它,然后再看這些解決方案背后有什么差異,也許就可以明白,到底自己在做WMS的時候,要不要用到“暫存庫位”了。
01.WMS入庫在什么時候增加庫存?
我相信,有非常多初次做WMS的朋友都曾經想過這問題,到底WMS在入庫的時候,應該在什么節點去增加庫存呢?是在收貨清點之后,還是在上架完成之后?
方案1:收貨之后
如果我們選擇了在收貨之后去增加庫存,那么意味著當倉庫完成了清點、驗收、收貨之后,WMS就增加了收貨的庫存。那么我們接下來就會面臨另外的幾個問題:收貨加了庫存,那么上架的時候加不加庫存?收貨加了庫存,那這個庫存記錄在什么維度上呢?怎么管理呢?
一般來說,如果采用了在“收貨之后”就增加庫存的方案,那么收貨之后會增加庫存,就需要知道這個庫存是掛在什么維度上的。此時就會在WMS中引入一個“暫存庫位”的概念,WMS收貨之后庫存會增加在“暫存庫位”中,這個暫存庫位就是一個虛擬的庫位,用來承載收貨的庫存數量。
Shipout WMS中的過渡庫位是“unsigned”庫位
由于大多數的WMS都是需要進行批次管理的,既然在收貨的時候生成了庫存,所以就應該在生成庫存的時候,同時也按批次屬性來生成對應的批次號,并將庫存和批次號關聯起來。所以當我們完成了收貨之后,同時也應該得到“SKU-庫位”和“SKU-批次”這兩個維度的庫存。
當倉庫完成了收貨之后,貨物可能只是暫存放在容器中或者是某個倉庫的空地上,最終的貨物肯定是要移動到具體的貨架上,庫位上。當我們在收貨之后,依然是要進行上架操作的,此時的上架依然是要增加庫存的,不過這個增加是“庫內移位式的增加”。
意思就是,從暫存庫位移動到存儲庫位,先從暫存庫位下架,然后再上架到存儲庫位中,庫存先扣減,然后再增加。
從暫存庫位轉移到存儲庫位方案
2:上架之后
也有很多海外倉是沒有引入“暫存庫位”或者“暫存庫位”的概念,所以他們往往會選擇在上架之后去增加庫存。
如果是在上架之后才生成庫存,也就是在上架之后才會有“SKU庫存、SKU-批次庫存,SKU-庫位庫存、SKU-批次-庫位”的庫存,那么又會面臨另外的一個問題:上架的時候要怎么判斷批次是否混放呢?
因為在很多WMS中,在新增庫位的時候,都會配置“是否允許混放產品”或者“是否允許混放批次”。
富勒WMS的庫位控制
吉客云WMS的庫位控制
因為上架之后才會增加庫存,此時如果還沒有上架,自然也就不會生成批次庫存了,也就沒有批次號了,那要怎么判斷是否批次混放呢?
為了解決這個問題,我們可以采用通過判斷“批次屬性”的方式來判斷是否批次混放,因為批次號的生成是通過批次屬性來判斷的,只要同一個SKU的批次屬性都相同,那么批次號必然也是相同的,那么能不能混放也就可以知道了。一般來說,批次屬性的一些數據獲取是在收貨的時候就可以獲取到的,例如說入庫日期,生產日期,失效日期,采購訂單號,供應商等。
在上架的時候,就可以通過這些批次屬性來判斷同一個庫位上是否混放了批次。
富勒批次屬性規則
直接上架后才增加庫存
02.倉庫揀貨下架之后但未出庫的庫存怎么處理?
當我們知道了問題1的背景和設計思路之后,我們馬上就會想到一個類似的問題:倉庫揀貨下架之后,還沒有出庫的部分庫存要怎么處理呢?
因為倉庫揀貨下架之后,貨物會放在揀貨車上,然后去做二次分揀、復核、打包稱重,最后等待物流攬收,直到貨物出庫之前,這些貨物應該都是存放在倉庫中的。所以理論上來說只要倉庫還沒有將實物出庫,那么這部分的庫存就應該是可以跟蹤和溯源的。
方案1:用暫存庫位來記錄這部分庫存
當倉庫揀貨之后,貨物從貨架上的庫位拿下來放到了揀貨車中,所以在“SKU-庫位”和“SKU-庫位-批次”的維度,這部分的庫存是要扣減的,因為貨物已經不在原來的庫位上了。
但是要追蹤和記錄這部分拿下來的庫存,所以我們可以再做一次“庫內移位式”的操作,貨物從貨架的庫位轉移到了暫存庫位的中,所以存儲庫位的“SKU-庫位”和“SKU-庫位-批次”維度的庫存扣減,對應的暫存庫位的“SKU-庫位”和“SKU-庫位-批次”維度的庫存則增加。
如果此時,倉庫需要做盤點、做移庫、做任何調用存儲庫位中庫存的動作,那么這部分已經揀貨下架的內容都不會受到影響,因為它已經不在存儲庫位上了。
同樣的道理,如果此時訂單發生了取消,需要將揀貨下架的這部分庫存重新返庫上架,回到原來的存儲庫位上,也可以從暫存庫位再做一次“庫內移位式”的操作。
如果訂單一切正常,那么當倉庫確認出庫之后,就直接從“暫存庫位”扣減庫存即可。
從存儲庫位轉移到暫存庫位
2.不用暫存庫位來記錄這部分庫存
如果我們選擇不用暫存庫位來記錄這部分的庫存,那么當實物揀貨下架之后,此時在WMS中是無法記錄到這部分“空白期”的庫存,我們只能記錄到從這個庫位上扣減了多少庫存數量。
通過前面章節的內容,我們知道倉庫會有多層級的庫位維度,那么在出庫的時候需要提前預占鎖定庫存,也需要按多層級的方式,從高到低逐層去預占鎖定。
層層鎖定的示意圖
當我們預占鎖定了“SKU-批次-庫位”維度的庫存之后,就可以去執行揀貨操作了。揀貨完成之后,我們需要將“SKU-批次-庫位”維度的庫存從預占鎖定轉為扣減,雖然是扣減了庫位上的庫存,但是倉庫層面的總庫存因為實物還沒有具體出庫,所以暫時還是在鎖定的狀態中。
如果此時,倉庫需要做盤點、做移庫、做任何調用存儲庫位中庫存的動作,那么這部分已經揀貨下架的內容都不會受到影響,因為它已經不在存儲庫位上了。
不過如果此時訂單發生了取消,需要將揀貨下架的這部分庫存重新返庫上架,回到原來的存儲庫位上,那么此時就不是做“庫內移位式”的操作,而是需要特殊處理一下用返庫上架的邏輯。因為如果是按普通的上架邏輯,那么批次號,原始的揀貨庫位等信息會對不上,所以得要用定制的“返庫上架”,去溯源取消的訂單曾經是從什么庫位揀貨的,現在又要回到什么庫位上。
可以通過庫存流水中關聯的“揀貨任務號”、“波次號”、“出庫單號”等信息來關聯相關的庫存流水,然后找到源庫位和數量等信息。
從存儲庫位扣減庫存
03.有了“暫存庫存”之后,查詢庫存的時候怎么展示?
通過上面入庫、出庫的拆解,我們會發現無論是否選擇使用“暫存庫位”,系統都可以有對應的解決方案,都是可以達到業務的目的,只不過是系統層面的一些改動點和邏輯處理會有點不太一樣而已。
當我們選擇了引入了“過渡庫位”或者“暫存庫位”之后,如果要在WMS中要去查詢庫存,那么對應的一些產品功能邏輯也要做出相應的調整,因為“暫存庫存”雖然是庫存,但是在某些場景是不可用的庫存,所以要在庫存設計的時候就考慮到這一層。
關于庫存方面的展示邏輯,還有是否可用的限制約束,以入庫收貨時啟用“暫存庫位”的場景為例,我這里整理了幾種相應的設計方案供參考。
方案一:部分維度隱藏“暫存庫存”的數據
第一種,就是在多層庫存查詢維度中,都不展示這部分的庫存,這樣可以直觀地讓用戶關注可用的庫存數量有多少,而不用被其他的概念和名詞困擾。
在這種方案中,可以通過“SKU-庫位查詢”或者是“SKU-批次-庫位”查詢,知道存放在暫存庫位中的數量有多少。同時系統也做了限制,雖然知道有多少數量,但是這些數量都是不可用的,不能用來分配揀貨,移庫,下架等任務,通過系統的定制化處理,只能將這部分的庫存用于上架使用(以收貨的“暫存庫存”為例)。
總庫存 = 可用庫存 + 鎖定庫存 + 不可用庫存(頁面不可見)
隱藏暫存不可用的庫存
方案二:全部維度展示“暫存庫存”的數據
第二種方案,就是在多層庫存查詢維度中,全部都展示這部分的庫存,但是標記為“不可用庫存”,這樣可以讓用戶知道具體有多少可用的庫存,又有多少不可用的庫存。而不可用的庫存,可以特意說明清楚就是指存放在暫存庫位的庫存。
在這種方案中,當通過“SKU-庫位”或者是“SKU-批次-庫位”查詢庫存的時候,可以知道貨物是放在了暫存庫位中。那么這部分庫存是算作“可用庫存”,還是“不可用庫存”,這個就要結合系統邏輯和代碼邏輯來處理了。如果算可用庫存,那么就要控制,在揀貨、移庫下架等場景下分配庫位庫存的時候,不要分配到暫存庫位的“可用庫存”;如果是算作不可用庫存,那么就是要控制,只有在特定的幾個場景下才可以使用暫存庫位的庫存,即使它是“不可用庫存”的類型
總庫存 = 可用庫存 + 鎖定庫存 + 不可用庫存(頁面可見)
顯示暫存不可用的庫存
方案三:部分隱藏,部分展示“暫存庫存”的數據
第三種方案,是富勒WMS的做法,它結合了方案一和方案二的內容,構成了一種比較特殊的處理方式。在“SKU”和“SKU-批次”的維度,隱藏不可用的庫存。但是在“SKU-庫位”和“SKU-批次-庫位”維度,引入了一個“待移出庫存”的概念,總庫存和待移出庫存是有數據的,但是可用庫存還是為0。
富勒WMS的做法
在富勒WMS中,涉及到“SKU-庫位”和“SKU-批次-庫位”維度的庫存,會有非常精細化的庫存類型的劃分,除了有“待移出庫存”之外,還會有:
- 訂貨數- 默認為空,用于根據庫存生成單證。
- 補貨待下架數量-補貨任務待操作數量。同一補貨任務,對于補貨來源庫位,鎖定為補貨待下架數量。
- 補貨待上架數量-補貨任務待操作數量。同一補貨任務,對于補貨目標庫位,鎖定為補貨待上架數量。
- 待上架數量-上架任務待操作數量。
- 待移出數量-移庫任務待操作數量。同一移庫任務,對于移庫來源庫位,鎖定為待移出數量。
- 待移入數量-移庫任務待操作數量。同一移庫任務,對于移庫目標庫位,鎖定為待移入數量。
- 待調整數量- 調整單待執行數量。
總結
通過上面的分析,我們可以知道WMS中可以啟用“暫存庫位”,也可以不啟用,最終我們都可以達到最終的業務目的。
當引入了“暫存庫位”之后,意味著倉庫入庫、出庫、盤點、移庫等各種操作都要考慮使用“暫存庫位”來承載庫存。當倉庫發生了庫位庫存的變動之后,往往會同時生成兩條流水,一條是存儲庫位的,一條是暫存庫位的,這兩者關聯的業務單據和動作任務等是同一個。
當后續需要定位一些庫存異常問題的時候,可以通過庫存流水,庫存變更的詳情來快速處理,因為越豐富的記錄,越豐富的字段,是可以大幅度提升排查問題的效率。
同時也因為增加了過多的概念和邏輯,系統的功能設計,邏輯設計,還有使用體驗等多少會受到一些影響,例如說系統邏輯更復雜了,開發難度更高,成本更高,同時用戶上手學習的成本也更高了,使用起來更復雜了。
而海外倉WMS或者是一些簡單化的WMS,一方面是業務場景沒有那么復雜,軟件功能夠用即可;另一方面也是基于用戶的上手學習使用的成本,往往會考慮更簡單直白的設計方案,所以往往在設計相關系統的時候不會采用引入“暫存庫位”的方案。
雖然沒有“暫存庫位”,但是海外倉WMS依然可以實現入庫到上架,揀貨到出庫的各項業務流程。即使有一些解決方案可能會有一定的取舍,不過最終所取得的結果還是沒問題的,這也是海外倉領域發展了這么多年之后的經驗沉淀。
本文由人人都是產品經理作者【PM維他命】,微信公眾號:【PM維他命】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
是不是還有個在途庫存?
是不是還有個停泊庫存?
嗯,在途是另外的概念,停泊這個沒聽過