電商技術解密之庫存系統
今天來跟大家聊下電商平臺里的庫存系統,相信大家對庫存系統最直觀的感受就是商詳頁上是否顯示“加入購物車”或者是“到貨通知”。只要能加入購物車就表示有庫存,顯示到貨通知就表示沒有庫存了,并沒有覺得這里面有多么的復雜。今天來跟大家一起解密下庫存系統,來看一看是不是真的如大家想象中那么的簡單。
庫存系統的作用是什么?
最重要的作用就是管理好各個商品的實時庫存數據,及時告訴用戶當前商品是否可以購買?還可以購買幾件。
為了能夠更清楚的介紹庫存系統是如何管理商品庫存數據的,這里需要先簡單給大家介紹另外一個系統,叫做倉庫系統。估計很多人分不清倉庫系統跟庫存系統之間的關系是什么?
倉庫系統實際真正管理的是物理倉庫里面的庫存的數量。我們經常聽說的京東亞洲一號倉等等這些大型的倉庫,由于面積非常大,里面的商品數量也很多,所以需要有一套系統來幫助管理實體倉里面的庫存的數量。
簡單來說就是管理這個倉庫一天有多少商品進入到這個倉庫里面來,每個商品的數量有多少?每天從這個倉庫發出去多少個商品?倉庫里面每個商品還剩下多少?剩下的這些商品分別存儲是倉庫的哪個儲位上等等。
那么有了倉庫系統就可以管理商品的數量,那么為什么還要有庫存系統呢?
下面給大家舉個例子,讓大家了解下倉庫系統和庫存系統之間的區別是什么?當某個商品A在倉庫里面有10個數量的時候,倉庫系統負責管理這個商品A的數量,以及它的位置信息。那么倉庫里面這個商品A在網站上是不是一定可以允許賣10個呢?這是不一定的。因為倉庫里面有10個商品A,可能網站上已經有3個被用戶買掉了,只不過這3個商品還沒有出庫,所以在倉庫系統里面看這個商品A目前還有10個在倉庫,但實際上已經賣掉3個,網站上其實只能賣7個,這種可賣的數量倉庫系統是區分不出來的,它只是負責管理在當前時刻倉庫里面一共有多少庫存,并不區分商品的狀態信息。所以庫存系統主要是用來解決這個問題,經過一系列的計算告訴用戶當前時刻商品A一共還可以買幾個。倉庫系統管理的是倉庫里面商品的實際數量,庫存系統管理的是商品的可銷售數量,這就是庫存系統和倉庫系統主要的區別。
在電商網站的商詳頁上展示當前商品可售賣數量對庫存系統來說是相對比較簡單的,有貨的時候顯示當前商品的數量,沒貨的時候告訴前端此商品庫存為0,前端展示到貨通知,如下圖:
庫存跟倉庫系統之間的交互
比較復雜的是如何對接倉庫的各種出入庫事件來管理商品的數量。下面來跟你介紹一下庫存跟倉庫系統之間交互的幾個比較重要的事件。
采購入庫
當B2C電商網站類似京東、當當這種想賣一個商品的時候首選要發起采購計劃,這時候需要在倉庫系統里面建立一個采購單。目的是記錄哪個商品采購了多少數量,將會把這批貨采購到哪個倉庫里面去。
采購單發起之后過一段時間實際的商品會入庫。這時候倉庫系統會把相應的商品數量進行更改。這個時候倉庫系統同時會通知庫存系統,告訴庫存系統某個商品入庫了,數量是多少,庫存系統會把相應的數量加上。
采購入庫時序圖
下單鎖庫存
商品采購入庫之后庫存系統就會增加相應的數量,這時候在網站端這個商品就可以開始賣了。當有人購買這個商品的時候,庫存系統會將這個商品數量先鎖定。然后等待倉庫出貨。當倉庫真正出貨的時候,庫存系統才會將相應的數量減掉。這里解釋下庫存系統為什么要有一個鎖定的狀態?
還是舉個例子來說。當一個手機A采購入庫10個的時候,庫存系統也會顯示這個手機在庫存系統里面有10個數量。也就是說網站上可以銷售的數量為10。
當一個用戶買了一個手機A的時候。庫存系統會將這個商品先鎖定一件。表示有一個商品已經有人付錢要進行購買了,這個時候庫存系統會告訴網站端此商品目前能購買的數量為9個。
訂單取消解鎖庫存
當用戶下了單買了手機A之后,過了一會可能由于種種原因后悔了,或者是不想買了或者是想換一個更好的手機,這個時候用戶會將這個訂單取消掉。在倉庫沒有將這個手機發出去之前用戶是可以取消的,這個時候我們需要將剛剛鎖定的數量解鎖掉,變化后的庫存數量如下:
出庫扣庫存
如果上面用戶沒有取消訂單,那么倉庫里面的工作人員將這個商品找到、打好包裹、寄出去之后,倉庫系統會通知庫存系統這個手機已經出庫,這個時候庫存系統需要將數量減少,具體變化如下:
倉庫的實際數量變為9,鎖定數量變為0,可售賣的數量仍然為9。
倉庫間調撥
這個純屬電商倉庫管理的后臺流程,普通用戶是感知不到的,稍微大一點的商家或者自營平臺,類似京東、蘇寧這種自建倉庫的平臺商家都會有很多個倉庫分布式在全國各地,商品也是有一定規則的分布在各個倉庫一定的數量,當用戶下單的時候盡量從離用戶最近的倉庫發貨,這樣速度比較快并且距離也比較短,物流成本也比較低。但實際上會由于各種原因導致某些商品庫存數量分配的并不是很合理,可能南方的倉庫已經賣沒了,北方的倉庫還積壓很多沒賣出去,這個時候為了讓商品盡快的賣出去,需要將這個商品從北方的倉庫調撥到南方的倉庫,這就是調撥的業務場景。
可以看到調撥是一個商品在兩個倉之間的周轉,這就為管理增加了難度,完成一次調撥有三個步驟:發起調撥申請、調撥出庫、調撥入庫。
發起調撥申請:當決定把商品A從北方倉調撥到南方倉的時候,首選需要發起一個申請,表示哪個商品從哪個倉調撥到哪個倉,調撥的數量是多少。
為了方便大家理解,我們舉個例子,將商品A從北方倉調撥到南方倉100個。當發起調撥申請的時候,庫存系統會先在北方倉鎖定100個商品A的數量。庫存的變化如下:
發起調撥前
發起調撥后
看到這里有同學會奇怪為什么發起調撥的時候也要先將調撥數量進行鎖定,因為如果不進行鎖定的話極端情況下北方倉的這個商品可能突然就賣掉了950件,這時候倉庫只剩下了50個,倉庫就沒有辦法進行100個商品的調撥,會影響商家的整體統籌安排,所以需要在發起調撥的時候預先鎖下,保證調撥可以正常進行。
調撥出庫:即當A商品從北方倉出庫的時候,這個時候我們需要將庫存數量進行相應的調整,調整后數量如下:
將北方倉的實際庫存數量和鎖定數量都減掉100,可銷售的數量仍然是900。
調撥入南方倉
在這100個商品進入到南方倉之前,我們看下南方倉的庫存數量,如下:
當這個100個單品進入到南方倉之后,南方倉這個商品的數量會進行調整,如下:
實際數量和可售賣數量都變成了100。
至此我們完成了一次完成的調撥流程。這里面大家可以看到,其實庫存與倉庫之間交互的事件比較多,邏輯也比較復雜。上面只是簡單列舉了幾個比較核心的流程。實際生產中還有很多更細節的事件需要管理。例如,退貨的流程、換貨的流程、損益的流程等等。如果任何一個地方出現誤差,就會導致倉庫的數量與庫存的數量不一致。
如果出現不一致,那就是庫存系統的最大失敗,庫存系統就是用來管理庫存的,這就是它的職責。但是實際業務中由于復雜的邏輯會出現一部分商品庫存管理出現錯誤,這時候會導致兩種后果,一種是倉庫系統明明只有5個商品,庫存那邊計算成了10個。這樣可能會有10個用戶來購買,但是倉庫只有5個,會導致有5個用戶的商品不能發貨,這就是我們所謂的超賣。這種是比較嚴重的后果,用戶的體驗非常不友好。另外一種情況是倉庫里面還有10個商品,但是庫存系統計算成只有5個,這樣會導致商品少賣會造成商品在倉庫的積壓。所以倉庫跟庫存還有一個比較重要的邏輯就是對賬每天都要核對一下兩邊的庫存數量是否一致。
上面跟大家介紹了下庫存系統的大體業務邏輯,相信已經有不少人已經看暈了,后面再找時間跟大家介紹下如此復雜的庫存系統是如何實現的?這里需要解決的問題是如何保數據一致性?跨庫的事務如何解決?采用什么樣的策略進行補償?對賬如何做?商詳的請求量比較大,如何保證庫存的性能?等等。有好的方案歡迎留言討論。
相關閱讀
本文由 @Nicole 原創發布于人人都是產品經理。未經許可,禁止轉載。
在庫存調撥的時候有一個漏洞,在商品調撥入庫前,貨品的跟蹤處于系統監控的真空狀態。在北方倉出庫后,在南方倉入庫前這批貨物在兩個倉庫系統之間都沒有數據可以查閱到這批貨物,這對商品的盤點是不利的。所以個人認為在庫存系統中需要有在途庫存這個狀態。
在南方入庫前,北方的鎖定的100貨就是這批貨物;當南方入庫后,鎖定的100件或釋放為0,南方的庫存為100;每個過程,肯定是能查閱到這批貨的。
你沒仔細看文章和我的回復哦~
我明白你的回復,是我想的有問題 ?? 對于北方已經出庫了,南方還未入庫的貨物在途過程是必須要監控的。
哈哈,研發庫存和采購系統時的一點經驗。歡迎交流,互相學習。
我們應該是同一行業的 ??
這些應該屬于WMS的范疇了吧
請問下下面這些問題有相應的介紹嗎:復雜的庫存系統是如何實現的?這里需要解決的問題是如何保數據一致性?跨庫的事務如何解決?采用什么樣的策略進行補償?對賬如何做?表示幫助很大,希望老師能發更多的講解
還好做過ERP的實施
還好自己開過天貓,能理解 ??
還好有基礎,提到的這些都能夠理解看明白。 ??
寫的很棒,知道商品庫存是怎么減的,又是什么時候鎖的了,這幾個問題好想知道,希望作者慷慨發表哦!“復雜的庫存系統是如何實現的?這里需要解決的問題是如何保數據一致性?跨庫的事務如何解決?采用什么樣的策略進行補償?對賬如何做?商詳的請求量比較大,如何保證庫存的性能?”
退貨是否需要退回庫存呢?
退貨一般分很多種情況,在不影響二次銷售(也就是七天無理由退換貨)這種情況,是直接入庫操作的,下次正常銷售,但是如果影響二次銷售的,存在質量問題的情況,又會有很多種處理方式,例如返廠維修、轉二手商品出售…….
產品小白,能否解答下贈品出庫這一塊的邏輯呢?
作者什么時候能再來一篇庫存管理如何實現的文章。這篇文章收獲頗豐,但是意猶未盡。另外 有個問題,下面有個朋友說 出庫減庫存是個坑,他們采用下架減庫存。請問下,為什么出庫減庫存是坑呢?具體的場景能幫忙介紹下嗎?
實際上庫存鎖也是有 A 鎖,B 鎖,也就是預鎖/正式鎖的區分的,當然就是對鎖的狀態進行細分,這樣的話可以更詳細區分業務場景,和數據統計分析的有效性,當然這個也增加了系統和流程的復雜性,雙刃劍也是沒辦法的。
出庫減庫存也是一個坑,我們設計的是上架加庫存,下架減庫存
出庫減庫存為什么是坑,能詳細解釋下嗎 謝謝
這個是什么邏輯,上架加庫存,下架減庫存?你這樣真的是實際庫存嗎?你這個最多只是可賣商品數;
下架減庫存不合理,實際下架的商品還在倉庫內,處于出庫中狀態,如果遇到取消訂單或者其他需要調用這批貨的情況就很難處理了
兩個系統有點類似會計上的權責發生制與收付實現制
建議建立電商產品經理微信群,我也是電商產品經理,最近做erp
有聯系方式嗎?
群有了嗎?這個真的可以有,涉及到倉儲、庫存,學問太大,大家可以相互交流各自經驗。
喜歡這種介紹實質業務處理的文章,想入門想了解,就是要通過這些才行。
在調撥那塊必須加上在途這么一種狀態,不然你在貨物從北倉到南倉的這段時間豈不是消失了。影響整體庫存不說,對財務也是一種誤導,一般庫存都是和財務有直接關聯的,這種倉庫之間的調撥也不是常規出庫。
恩,看來你是行家,實際是有調撥在途,包括采購在途的。我為了讓大家更好理解,沒寫這塊,加上在途的話邏輯更復雜了。
感謝查漏補缺
在途本身來說不算消失,整體計算的時候可以計算為在庫,因為不會發生庫存移動單價變化。
庫存最重要的功能就在于管理貨物狀態,通過貨物的狀態去控制前臺商品是否可以銷售(在途一般情況下是不可銷售,單庫存可見),同時貨物狀態的改變也會觸發財務系統對接的部分功能(應收、應付),庫存不單單是用來做貨物數量統計作用。
不錯。
商品的狀態是需要定義的,不同的操作狀態也會自動變更,并與其它系統如財務、采購、物流等產生交互,不僅僅是入庫、出庫等狀態。