?最近在負責電商后臺的商品模塊改造以及新增倉儲物流功能，將工作內(nèi)容梳理總結了一下，第一篇文章梳理改造的商品管理模塊，第二篇將整理從0到1規(guī)劃的物流倉儲模塊。
背景介紹
該電商為自營B2C模式，基本訂單業(yè)務流程是：
由前端APP銷售產(chǎn)生訂單，訂單傳到中臺訂單模塊，由訂單中心處理生成配送單，通過線下調度方式，派發(fā)給物流公司。系統(tǒng)上僅從商品創(chuàng)建上架開始管理，并沒有對商品采購等流程進行管理，因此系統(tǒng)中的商品庫存數(shù)據(jù)一直不準確，所以我們希望倉儲物流模塊可以從源頭管控商品采購流程，解決系統(tǒng)中商品庫存數(shù)據(jù)不準確的問題，其次解決商品配送問題，最終形成產(chǎn)品閉環(huán)。未來業(yè)務規(guī)劃需要拓展到分站分倉的銷售模式，那么在商品的數(shù)量上將會大大增加，而且同一商品在不同地域或倉庫維度上可能分別有不同的銷售價格。
系統(tǒng)為了滿足未來業(yè)務模式的拓展，我們決定先從商品模塊開始改造。
系統(tǒng)現(xiàn)狀問題分析
1.在創(chuàng)建商品時僅有一個庫存字段，設計之初是希望代表物理庫存，在商品生成訂單時，直接減扣該庫存，（實際上為了銷售業(yè)績，經(jīng)過了人工多次修改后已經(jīng)是虛擬庫存）這顯然是不能掌控實際倉庫庫存的。
2.商品管理維度為SKU，前臺顯示也按照SKU維度，包括前臺的搜索功能，系統(tǒng)中不存在SPU的概念，如果商品數(shù)量增多，那么前臺的類目展示、搜索、后臺管理都會很難維持。
3.商品屬性固定，僅有規(guī)格、顏色、計量單位，直接掛在商品SKU上，不支持擴展商品屬性分類，每種商品的屬性都是一樣的，商品屬性表與商品不存在對應關系。
4.目前每種商品只存放在一個倉庫中，并且每個SKU僅有一個價格，不能支持未來多倉庫多銷售站點多價格的業(yè)務模式。
系統(tǒng)改造
系統(tǒng)級的設計從大到細一般分為四個層次，
1.該系統(tǒng)與外部其他系統(tǒng)的關系（如何協(xié)作、功能邊界）
2.系統(tǒng)內(nèi)底層數(shù)據(jù)庫結構設計
3.系統(tǒng)內(nèi)應用功能邏輯
4.系統(tǒng)內(nèi)各界面層建設
一般從我們平時做產(chǎn)品設計的時候，可能會比較多在功能和界面上，而如果培養(yǎng)自己習慣從底層數(shù)據(jù)結構開始去思考這個功能和界面的設計，往往設計出來的功能可執(zhí)行性會更高，與程序猿撕逼的機會會更低。
（一）商品類目屬性改造
1.數(shù)據(jù)結構上增加SPU，直接將商品屬性掛在SPU上，商品屬性在SPU維度進行維護，SKU直接在SPU下新建，關聯(lián)所屬SPU的商品屬性。后端商品銷售類目直接作為前端銷售類目，下一步再由后端類目映射到前端銷售屬性（不在本次進行）。
附部分表結構設計
2.相關需要改造的功能流程
新建商品流程
商品上下架流程
商品權限管理
等等。。。
3.界面上的改造，優(yōu)化用戶體驗
前端商品列表由SKU變?yōu)镾PU，商品詳情頁內(nèi)區(qū)分出SKU，因為我們的商品屬性目前很少，為了減少用戶操作，所以在前端展示上SKU的銷售屬性值展示在一個類別下。
后端界面就不展開說明了。
4.老商品數(shù)據(jù)的處理
我們商品數(shù)量還不多共1300多個SKU，需要在我們系統(tǒng)改造后，將這些老數(shù)據(jù)整合成SPU，我們首先請采銷部門進行數(shù)據(jù)初次整合，畢竟采銷人員對于商品分類更專業(yè)，然后請銷售部門根據(jù)用戶購買習慣進行二次整理，最后請財務部對這些數(shù)據(jù)進行最后確認，避免對財務報表影響導致不必要的撕逼^^
（二）商品庫存改造
1.庫存由一個字段增加為三個，物理庫存、銷售庫存、凍結庫存，商品與倉庫是多對多的關系，庫存作為SKU和倉庫關系屬性
銷售庫存，即前臺界面顯示的庫存。
物理庫存，影響物理庫存庫存的行為，最主要的就是入庫、出庫。
入庫就是增加了多少商品數(shù)量，常見的有采購入庫、退貨入庫、換貨入庫、調撥入庫、生產(chǎn)入庫、盤盈入庫、其他入庫等；出庫就是減少了多少商品數(shù)量，常見的有銷售出庫、采購退貨出庫、調撥出庫、盤虧出庫、其他出庫等 。
鎖定庫存，由實際業(yè)務決定的，無需人工維護。
庫存減扣節(jié)點
假設用戶下單購買100件商品
用戶下單（確認訂單）：銷售庫存-100；物理庫存不變；凍結庫存不變
用戶付款：銷售庫存-100；物理庫存不變；凍結庫存+100
商品出庫：銷售庫存-100；物理庫存-100；凍結庫存釋放
2.業(yè)務功能
1）原有的一個庫存擴展到三個，其中銷售庫存和鎖定庫存均需人工維護，客服根據(jù)實際庫存和銷售需求維護銷售庫存，業(yè)務穩(wěn)定后，可以由系統(tǒng)根據(jù)超售比例自動維護，如銷售庫存=1.2*物理庫存，倉庫根據(jù)實際出入庫數(shù)量維護物理庫存。
2）組合活動商品
組合商品不算做新的sku，對應兩個商品分別的sku，新建一個活動商品C 。
組合商品價格=a活動價格+b活動價格，可以這么理解
商品庫邏輯功能這樣解決，設置新的活動商品C，賦予一個活動商品的銷售庫存，這個庫存可以根據(jù)實際業(yè)務需要來定（比如活動需要銷售臨近批次的產(chǎn)品，就可以將這部分的庫存數(shù)量控制在該批次商品庫存），實際扣減對應的a,b的物理庫存。
以上是對于商品管理模塊改造的簡單總結，關于商品倉儲物流的部分我會放在下一次繼續(xù)介紹(??ˇ?ˇ?)
作者：一枚電商產(chǎn)品妹子，坐標南京。（微信公眾號見名片）
