https://www.cnblogs.com/smh188/p/11533668.html(我是如何一步步編碼完成萬倉網ERP系統的(一)系統架構)html
https://www.cnblogs.com/smh188/p/11534451.html(我是如何一步步編碼完成萬倉網ERP系統的(二)前端框架)前端
https://www.cnblogs.com/smh188/p/11535449.html(我是如何一步步編碼完成萬倉網ERP系統的(三)登陸)數據庫
https://www.cnblogs.com/smh188/p/11541033.html(我是如何一步步編碼完成萬倉網ERP系統的(四)登陸的具體實現)跨域
https://www.cnblogs.com/smh188/p/11542310.html(我是如何一步步編碼完成萬倉網ERP系統的(五)產品庫設計 1.產品類別)前端框架
https://www.cnblogs.com/smh188/p/11546917.html(我是如何一步步編碼完成萬倉網ERP系統的(六)產品庫設計 2.百度Ueditor編輯器)架構
https://www.cnblogs.com/smh188/p/11572668.html(我是如何一步步編碼完成萬倉網ERP系統的(七)產品庫設計 3.品牌圖片跨域上傳)框架
https://www.cnblogs.com/smh188/p/11576543.html(我是如何一步步編碼完成萬倉網ERP系統的(八)產品庫設計 4.品牌類別)編輯器
https://www.cnblogs.com/smh188/p/11578185.html(我是如何一步步編碼完成萬倉網ERP系統的(九)產品庫設計 5.產品屬性項) 網站
https://www.cnblogs.com/smh188/p/11589264.html(我是如何一步步編碼完成萬倉網ERP系統的(十)產品庫設計 6.屬性項和類別關聯) 編碼
https://www.cnblogs.com/smh188/p/11596459.html(我是如何一步步編碼完成萬倉網ERP系統的(十一)產品庫設計 7.發佈商品)
https://www.cnblogs.com/smh188/p/11610960.html(我是如何一步步編碼完成萬倉網ERP系統的(十二)庫存 1.概述)
https://www.cnblogs.com/smh188/p/11669871.html(我是如何一步步編碼完成萬倉網ERP系統的(十三)庫存 2.加權平均價)
https://www.cnblogs.com/smh188/p/11763319.html(我是如何一步步編碼完成萬倉網ERP系統的(十四)庫存 3.庫存日誌)
萬倉網ERP系統不開源,準備作一個系列,講一講主要的技術點,這些技術點會有源代碼。若是想看全部的源代碼,能夠打道回府了,不必再閱讀下去了,浪費您寶貴的時間。
接下來的幾篇開始說說庫存,如何設計一個高效NB的電商庫存系統呢?好的電商庫存系統有哪些要點呢?
對於用戶來講,固然是操做方便;庫存帳目清晰準確;雙十一、618大促時可以減小超賣;可以根據現有庫存銷售數據,預測未來的銷售,掌控供應鏈,提升庫存週轉率和資金的使用率等。
對於開發設計來講,怎麼作才能知足用戶的要求?固然是直接借鑑一個成熟的大流量的電商庫存系統,那就是亞馬遜的Bin系統,網上有不少亞馬遜bin系統的介紹,能夠搜索關鍵字進行查詢,這裏就不過多的介紹了,直接上正文吧。
1. 採用雙重的庫存架構,第一層是以倉庫和SKU爲維度的庫存結構,主要字段有倉庫編碼,SKU編碼,可訂量和庫存量等(能夠在此基礎上進行擴展好比殘品可訂量,殘品庫存,鎖定可訂量(大促前鎖定的庫存),這裏不過多介紹擴展字段,只介紹正品可訂量和正品庫存)。
可訂量就是可供訂單(包括調撥單、領用單和採購退貨單等)下單的數量,訂單進入到ERP系統確認審覈後,根據訂單明細扣減可訂量,這時庫存量不變。這樣設計能保證大促銷時,減小超賣現象,系統能夠根據可訂量來判斷能不能下單,盤虧時可訂量可能爲負。
庫存量就是倉庫內實際的商品庫存,庫存量不能爲負。
2. 第二層以貨位和SKU爲維度的Bin貨位庫存結構,庫房有貨架,貨架上每一個貨格稱爲 「Bin」 貨位,這就對庫房的工做人員多了一些工做量,須要事先設定好貨位,更細緻的能夠設訂貨位的長寬高,商品入庫時能夠根據商品的體積來推薦上架貨位。
貨位號須要保持全系統惟一,這樣可以方便定位檢索。
貨位類型能夠根據存貨商品類型和使用方式分爲三種:正品貨位(細分爲正品存貨位和正品揀貨位)、殘品貨位和移動貨位。正品貨位只能存儲正品庫存,殘品貨位只能存儲殘品庫存。移動貨位做爲一種特殊的貨位,好比當採購單入庫後,採購的貨品按照庫房的做業應該是先放到托盤上,這時這個托盤就是移動貨位,庫管拉着托盤去正品貨位或殘品貨位進行上架,這樣貨位就和SKU進行綁定,接下來就引伸出來BinItem(貨位庫存)。
能夠看一下BinItem的表架構,一個貨位能夠放置多種SKU,這樣設計就避免一種SKU佔用一個貨位,當SKU種類過多時,貨位就不夠用了,可以合理的使用貨位。
可用量就是能夠分揀的數量,拿訂單來講,訂單在佔用Storage表可訂量時,就須要分揀具體的貨位了,根據單據的正殘,來分揀正品貨位或殘品貨位。分揀貨位時,BinItem表ForUsage就直接扣減(須要記錄日誌,揀貨時按照指訂貨位揀貨),可是貨位庫存量不變。
拿採購單來講,單據從源頭上就要區分是正品仍是殘品,固然採購單確定是正品了(一些二手商家會採購一些殘品),採購單入庫時,Storage庫存表可訂量和庫存量要一同增長,用戶在購物網站就能夠下單了。同時移動貨位的BinItem貨位庫存表貨位庫存量要增長,移動貨位的可用量不用增長,WHY?由於系統設定,單據揀貨時不能分揀到移動貨位(單據揀貨時從正品貨位下架到移動貨位,這時單據又分揀到移動貨位,形成死循環),那可用量在何時增長呢?在庫存上架的時候,貨位庫存從移動貨位移動到正品(殘品)貨位時,正品(殘品)貨位可用量和貨位庫存量同時增長,扣減移動貨位的庫存量,Storage表不進行任何操做。
能夠看出Storage庫存表的可訂量和BinItem貨位庫存表的可用量並非實時一致的,訂單佔用可訂量,還沒分揀時可用量並沒佔用。但庫存表和貨位庫存表的庫存量是一致的。
二者的庫存量在入庫或者出庫時必須同時增減,對系統的一致性要求極高,能夠合理的使用事務來確保兩表操做的一致性。
這樣設計出來的庫存系統能夠實現精細化管理,某個商品在哪一個貨位,庫存量、可訂量和貨位可用量能夠方便的查詢,因爲BinItem表結構設計,當SKU或者貨位比較多時,一個SKU能夠放置在多個貨位,有很頻繁的貨位移動,數據量會比較大,須要合理的設置索引鍵,同時對數據庫的讀寫壓力也比較大。固然好處也很是多,庫房能夠上一些現代化的PDA,實現無紙化操做,庫房揀貨、上架和盤點均可以同時操做。
嘮嘮叨叨,先說這麼多。
PS:客官有時間光臨個人小站 萬倉網 。