電商技術解密—管好庫存沒那么容易

今天來跟大家聊下電商平臺里的庫存系統(tǒng),相信大家對庫存系統(tǒng)最直觀的感受就是商詳頁上是否顯示“加入購物車”或者是“到貨通知”。只要能加入購物車就表示有庫存,顯示到貨通知就表示沒有庫存了,并沒有覺得這里面有多么的復雜。今天來跟大家一起解密下庫存系統(tǒng),來看一看是不是真的如大家想象中那么的簡單。

庫存系統(tǒng)的作用是什么?

最重要的作用就是管理好各個商品的實時庫存數(shù)據(jù),及時告訴用戶當前商品是否可以購買?還可以購買幾件。

為了能夠更清楚的介紹庫存系統(tǒng)是如何管理商品庫存數(shù)據(jù)的,這里需要先簡單給大家介紹另外一個系統(tǒng),叫做倉庫系統(tǒng)。估計很多人分不清倉庫系統(tǒng)跟庫存系統(tǒng)之間的關系是什么?

倉庫系統(tǒng)實際真正管理的是物理倉庫里面的庫存的數(shù)量。我們經(jīng)常聽說的京東亞洲一號倉等等這些大型的倉庫,由于面積非常大,里面的商品數(shù)量也很多,所以需要有一套系統(tǒng)來幫助管理實體倉里面的庫存的數(shù)量。

簡單來說就是管理這個倉庫一天有多少商品進入到這個倉庫里面來,每個商品的數(shù)量有多少?每天從這個倉庫發(fā)出去多少個商品?倉庫里面每個商品還剩下多少?剩下的這些商品分別存儲是倉庫的哪個儲位上等等。

那么有了倉庫系統(tǒng)就可以管理商品的數(shù)量,那么為什么還要有庫存系統(tǒng)呢?

下面給大家舉個例子,讓大家了解下倉庫系統(tǒng)和庫存系統(tǒng)之間的區(qū)別是什么?當某個商品A在倉庫里面有10個數(shù)量的時候,倉庫系統(tǒng)負責管理這個商品A的數(shù)量,以及它的位置信息。那么倉庫里面這個商品A在網(wǎng)站上是不是一定可以允許賣10個呢?這是不一定的。因為倉庫里面有10個商品A,可能網(wǎng)站上已經(jīng)有3個被用戶買掉了,只不過這3個商品還沒有出庫,所以在倉庫系統(tǒng)里面看這個商品A目前還有10個在倉庫,但實際上已經(jīng)賣掉3個,網(wǎng)站上其實只能賣7個,這種可賣的數(shù)量倉庫系統(tǒng)是區(qū)分不出來的,它只是負責管理在當前時刻倉庫里面一共有多少庫存,并不區(qū)分商品的狀態(tài)信息。所以庫存系統(tǒng)主要是用來解決這個問題,經(jīng)過一系列的計算告訴用戶當前時刻商品A一共還可以買幾個。倉庫系統(tǒng)管理的是倉庫里面商品的實際數(shù)量,庫存系統(tǒng)管理的是商品的可銷售數(shù)量,這就是庫存系統(tǒng)和倉庫系統(tǒng)主要的區(qū)別。

在電商網(wǎng)站的商詳頁上展示當前商品可售賣數(shù)量對庫存系統(tǒng)來說是相對比較簡單的,有貨的時候顯示當前商品的數(shù)量,沒貨的時候告訴前端此商品庫存為0,前端展示到貨通知,如下圖。

商詳上提示庫存的數(shù)量


商詳提示到貨通知


比較復雜的是如何對接倉庫的各種出入庫事件來管理商品的數(shù)量。下面來跟你介紹一下庫存跟倉庫系統(tǒng)之間交互的幾個比較重要的事件。

采購入庫

當B2C電商網(wǎng)站類似京東、當當這種想賣一個商品的時候首選要發(fā)起采購計劃,這時候需要在倉庫系統(tǒng)里面建立一個采購單。目的是記錄哪個商品采購了多少數(shù)量,將會把這批貨采購到哪個倉庫里面去。

采購單發(fā)起之后過一段時間實際的商品會入庫。這時候倉庫系統(tǒng)會把相應的商品數(shù)量進行更改。這個時候倉庫系統(tǒng)同時會通知庫存系統(tǒng),告訴庫存系統(tǒng)某個商品入庫了,數(shù)量是多少,庫存系統(tǒng)會把相應的數(shù)量加上。

采購入庫時序圖

下單鎖庫存

商品采購入庫之后庫存系統(tǒng)就會增加相應的數(shù)量,這時候在網(wǎng)站端這個商品就可以開始賣了。當有人購買這個商品的時候,庫存系統(tǒng)會將這個商品數(shù)量先鎖定。然后等待倉庫出貨。當倉庫真正出貨的時候,庫存系統(tǒng)才會將相應的數(shù)量減掉。這里解釋下庫存系統(tǒng)為什么要有一個鎖定的狀態(tài)?

還是舉個例子來說。當一個手機A采購入庫10個的時候,庫存系統(tǒng)也會顯示這個手機在庫存系統(tǒng)里面有10個數(shù)量。也就是說網(wǎng)站上可以銷售的數(shù)量為10。

可賣庫存為10

當一個用戶買了一個手機A的時候。庫存系統(tǒng)會將這個商品先鎖定一件。表示有一個商品已經(jīng)有人付錢要進行購買了,這個時候庫存系統(tǒng)會告訴網(wǎng)站端此商品目前能購買的數(shù)量為9個。

減掉鎖定數(shù)據(jù),可售數(shù)量為9

訂單取消解鎖庫存

當用戶下了單買了手機A之后,過了一會可能由于種種原因后悔了,或者是不想買了或者是想換一個更好的手機,這個時候用戶會將這個訂單取消掉。在倉庫沒有將這個手機發(fā)出去之前用戶是可以取消的,這個時候我們需要將剛剛鎖定的數(shù)量解鎖掉,變化后的庫存數(shù)量如下。

鎖定數(shù)量取消,可賣數(shù)量仍為10

出庫扣庫存

如果上面用戶沒有取消訂單,那么倉庫里面的工作人員將這個商品找到、打好包裹、寄出去之后,倉庫系統(tǒng)會通知庫存系統(tǒng)這個手機已經(jīng)出庫,這個時候庫存系統(tǒng)需要將數(shù)量減少,具體變化如下。

出庫將鎖定和實際庫存數(shù)量減掉

倉庫的實際數(shù)量變?yōu)椋梗i定數(shù)量變?yōu)椋埃墒圪u的數(shù)量仍然為9。

倉庫間調撥

這個純屬電商倉庫管理的后臺流程,普通用戶是感知不到的,稍微大一點的商家或者自營平臺,類似京東、蘇寧這種自建倉庫的平臺商家都會有很多個倉庫分布式在全國各地,商品也是有一定規(guī)則的分布在各個倉庫一定的數(shù)量,當用戶下單的時候盡量從離用戶最近的倉庫發(fā)貨,這樣速度比較快并且距離也比較短,物流成本也比較低。但實際上會由于各種原因導致某些商品庫存數(shù)量分配的并不是很合理,可能南方的倉庫已經(jīng)賣沒了,北方的倉庫還積壓很多沒賣出去,這個時候為了讓商品盡快的賣出去,需要將這個商品從北方的倉庫調撥到南方的倉庫,這就是調撥的業(yè)務場景。

可以看到調撥是一個商品在兩個倉之間的周轉,這就為管理增加了難度,完成一次調撥有三個步驟:發(fā)起調撥申請、調撥出庫、調撥入庫。

發(fā)起調撥申請:當決定把商品A從北方倉調撥到南方倉的時候,首選需要發(fā)起一個申請,表示哪個商品從哪個倉調撥到哪個倉,調撥的數(shù)量是多少。

為了方便大家理解,我們舉個例子,將商品A從北方倉調撥到南方倉100個。當發(fā)起調撥申請的時候,庫存系統(tǒng)會先在北方倉鎖定100個商品A的數(shù)量。庫存的變化如下:

發(fā)起調撥前

發(fā)起調撥前有1000個

發(fā)起調撥后

發(fā)起調撥后,鎖定100個

看到這里有同學會奇怪為什么發(fā)起調撥的時候也要先將調撥數(shù)量進行鎖定,因為如果不進行鎖定的話極端情況下北方倉的這個商品可能突然就賣掉了950件,這時候倉庫只剩下了50個,倉庫就沒有辦法進行100個商品的調撥,會影響商家的整體統(tǒng)籌安排,所以需要在發(fā)起調撥的時候預先鎖下,保證調撥可以正常進行。

調撥出庫:即當A商品從北方倉出庫的時候,這個時候我們需要將庫存數(shù)量進行相應的調整,調整后數(shù)量如下:

出庫后減掉鎖定量和實際庫存數(shù)量

將北方倉的實際庫存數(shù)量和鎖定數(shù)量都減掉100,可銷售的數(shù)量仍然是900。

調撥入南方倉

在這100個商品進入到南方倉之前,我們看下南方倉的庫存數(shù)量,如下。

南方倉此時沒有庫存

當這個100個單品進入到南方倉之后,南方倉這個商品的數(shù)量會進行調整如下。

可售賣數(shù)量變?yōu)?00

實際數(shù)量和可售賣數(shù)量都變成了100。

至此我們完成了一次完成的調撥流程。這里面大家可以看到,其實庫存與倉庫之間交互的事件比較多,邏輯也比較復雜。上面只是簡單列舉了幾個比較核心的流程。實際生產(chǎn)中還有很多更細節(jié)的事件需要管理。例如,退貨的流程、換貨的流程、損益的流程等等。如果任何一個地方出現(xiàn)誤差,就會導致倉庫的數(shù)量與庫存的數(shù)量不一致。

如果出現(xiàn)不一致,那就是庫存系統(tǒng)的最大失敗,庫存系統(tǒng)就是用來管理庫存的,這就是它的職責。但是實際業(yè)務中由于復雜的邏輯會出現(xiàn)一部分商品庫存管理出現(xiàn)錯誤,這時候會導致兩種后果,一種是倉庫系統(tǒng)明明只有5個商品,庫存那邊計算成了10個。這樣可能會有10個用戶來購買,但是倉庫只有5個,會導致有5個用戶的商品不能發(fā)貨,這就是我們所謂的超賣。這種是比較嚴重的后果,用戶的體驗非常不友好。另外一種情況是倉庫里面還有10個商品,但是庫存系統(tǒng)計算成只有5個,這樣會導致商品少賣會造成商品在倉庫的積壓。所以倉庫跟庫存還有一個比較重要的邏輯就是對賬每天都要核對一下兩邊的庫存數(shù)量是否一致。

上面跟大家介紹了下庫存系統(tǒng)的大體業(yè)務邏輯,相信已經(jīng)有不少人已經(jīng)看暈了,后面再找時間跟大家介紹下如此復雜的庫存系統(tǒng)是如何實現(xiàn)的?這里需要解決的問題是如何保數(shù)據(jù)一致性?跨庫的事務如何解決?采用什么樣的策略進行補償?對賬如何做?商詳?shù)恼埱罅勘容^大,如何保證庫存的性能?等等。有好的方案歡迎留言討論。


PS:本人主攻電商的方方面面,喜歡的記得關注哦,你的關注是我持續(xù)的動力!

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容