新零售SaaS架構：中央庫存系統架構設計
在全渠道模式下，各渠道必須有足量的商品來滿足客戶需求，同時需有效管理總庫存，平衡各渠道庫存，以減少缺貨或者滯銷的情況發生。
全渠道模式下，庫存管理面臨的挑戰
在線上線下渠道融合的大背景下，零售企業如果沒有管理好全渠道庫存，會帶來諸多問題：
-
各渠道庫存割裂，進行線上線下促銷活動時，商品超賣，引起客訴。
-
各渠道庫存分配不合理，要麼缺貨，要麼庫存積壓。
-
各渠道庫存數據更新不及時，有貨卻不能下單，銷售機會大量流失。
-
各地庫存數據分散在各系統中，數據不通，無法知曉庫存分佈情況，無法統一採購/調撥。
-
無法根據用戶的下單信息，進行智能分倉、就近發貨。
中央庫存系統的定位
向下對接各地倉庫/門店庫存，將各地庫存放在「一盤貨」里，進行管理、統一調配。
向上打通所有銷售渠道平台，實現全渠道庫存共享、自動化運營。
中央庫存系統的關鍵概念
中央庫存整體業務框架
中央庫存體系將庫存管理分為三層，銷售層、調度層、倉庫層，實現庫存利用最大化，支持多倉多渠道模式下的各種業務場景。
倉庫層
倉庫層的定位是管理倉庫庫存，一般使用倉庫WMS、門店系統或ERP系統來管理倉庫的進銷存，通過出入庫單據變更倉庫庫存數量。
倉庫庫存的關鍵屬性包括：貨主、倉庫/門店、SKU、批號、生產日期、庫存狀態、庫位等。
-
貨主：貨物所有權的擁有者。
-
倉庫/門店：存儲貨物的邏輯單元，這裡需要與物理世界的倉庫區分開，可能一個物理倉庫包含多個邏輯倉庫單元。
-
批號：用於區分每一批投料生產出來的產品，為了事後能追蹤這批產品的責任，每一批產品都有相應的批號。
-
生產日期：生產線包裝出可銷售的成品的日期與時間。
-
庫存狀態：描述庫存在不同業務場景下的不同狀態，例如，可用、凍結、在途、不良品、廢品等。
-
庫位：一般是指在工廠倉庫中實際存在的庫位，比如一個個的貨架。同時也是SKU庫存的最小粒度。
調度層
調度層的定位是匯總各倉庫/門店的所有庫存狀態的庫存總量，但不同於倉庫庫存，調度層的實物庫存無需管理批號、庫位等細粒度的庫存維度，只需要管理每個庫存狀態下的實物庫存總數即可，這是一種解耦的設計方式。
實物庫存的關鍵屬性包括：倉庫/門店、SKU、庫存狀態等。關鍵概念包括：
-
在途庫存：指供應商發貨但還未入庫的庫存，有時為了擴大銷售機會，在途庫存也會用於擴大銷售庫存數量。
-
可用實物庫存：倉庫實際可用於銷售的庫存。
-
不可用實物庫存：即對應倉庫中的不可用庫存。
-
銷售預占庫存：訂單提交並分倉成功後，會預占對應倉庫的庫存，訂單取消或發貨後，會扣減預占庫存。
-
銷售可用庫存：銷售可用庫存=可用實物庫存-銷售預占庫存。
銷售層
銷售層的定位是管理各個銷售渠道的渠道庫存，為銷售平台提供庫存計算與庫存同步的服務，並通過各種渠道庫存分配策略進行庫存分配，防止超賣，保障利潤最優。
銷售庫存的關鍵屬性包括：
-
銷售渠道：包括自營的網店、門店線下渠道，天貓，京東，美團，餓了么等三方平台等。
-
銷售店鋪：銷售的店鋪或門店。
-
發貨方式：快遞、同城配送、自提。
-
配送區域：由於各個倉庫覆蓋的配送區域不一樣，所以SKU能支持的配送範圍也不同。
銷售庫存的關鍵概念：
-
銷售可用庫存：按照倉庫/門店的供貨關係、渠道庫存分配策略進行計算匯總的可銷售的庫存數量。訂單提交成功扣減銷售可用庫存，當調度層的實物庫存更新，需要觸發銷售層重新計算銷售可用庫存。
-
預售庫存：如果商品未到貨，可以開啟預售模式，提前售賣。實物庫存與預售庫存是隔離開的，當實物到貨後，預售庫存統一推到實物庫存進行履約。
-
預占庫存： 訂單已提交但未支付之前，為給顧客預留商品，會先預占商品庫存，待支付以後再刪除預占庫存、扣減可銷售庫存。若長時間未支付，則會取消訂單，釋放預占庫存。
-
活動庫存：針對某些SKU做促銷活動時，例如特價、秒殺活動，需要設置活動庫存，可以從正常庫存中預留部分庫存，活動開始後釋放預留庫存。如果活動商品的下單數量等於活動計劃的庫存總數量，則活動終止。活動訂單與普通訂單，在庫存處理邏輯上是一模一樣的。如果沒有特殊要求，沒必要單獨把活動庫存單獨分出來，作為獨立的業務處理，這樣會多出兩套庫存邏輯，三層庫存架構需要都獨立分開處理，極大地增加了複雜度。
-
預留庫存：若需要提前為某些促銷活動預留庫存，以免活動開始以後庫存不足，可設置預留庫存。
-
可售庫存 = 預售庫存+銷售可用庫存 – 預占庫存 – 預留庫存。
銷售渠道層
銷售渠道層代表各個銷售渠道平台，包括自營的網店、門店渠道，天貓，京東，美團，餓了么等三方平台等。
邏輯模型設計
庫存的核心場景
調度層同步邏輯
調度層的實物庫存來自各個倉庫的庫存，一般有兩種同步模式：
-
流水同步模式：適用於內部系統打通，能夠獲取倉庫/門店的庫存流水，通過回傳流水，變更調度層的實物庫存數量。這樣做的好處是，有很清晰的實物庫存流水變更記錄，便於追查到每次庫存變化的明細，需要注意做好冪等處理，避免重複同步導致庫存數量變更出錯。
-
數量同步模式：適用於外部系統對接，一般獲取不到詳細的庫存流水，通過商家後台或系統對接的方式同步庫存實時數量。
銷售庫存計算邏輯
在新零售的多倉多渠道模式下，為了實現全渠道庫存共享，庫存匯總為「一盤貨」管理，要充分考慮各個倉庫/門店的特性，包括支持的發貨方式，配送範圍等，為了合理分配庫存，需要考慮各個銷售店鋪的庫存佔比。下面針對幾種常見的場景，說明銷售庫存的計算邏輯。
多倉供貨場景
門店A、門店B為兩個線下門店，門店A有100件iphone14，門店B有50件iphone14。
假設商家有1個天貓旗艦店，門店A、門店B均給天貓店供貨。
天貓旗艦店僅支持快遞發貨方式，為了防止超賣，設置快遞的最大分配比例為80%。
如圖例所示，最終天貓渠道的iphone14的庫存數量為120，並定期將數量同步到天貓平台。
單倉給多店供貨場景
商家有1個電商倉，為商家的各個電商平台店鋪提供倉儲服務與發貨服務，電商倉有100件iphone14。
電商倉同時為京東旗艦店、天貓旗艦店供貨，兩個店鋪僅支持快遞發貨方式，最大分配比例分別為80%、60%。
如圖例所示，最終京東渠道的iphone14的庫存數量為80，天貓渠道的iphone14的庫存數量為60。
門店全渠道庫存共享場景
隨着新零售線上線下渠道加速融合，門店線上線下全渠道銷售，已經成為大部分零售商家的標配。
受益於微信生態和小程序電商的高速發展，越來越多的門店開啟了雲店模式，雲店實際上就是門店的線上化交易渠道，或者稱為門店的「線上貨架」。
連鎖企業把線下門店嫁接到微信生態中，將門店所有商品上架到雲店小程序。藉助雲店，消費者無需到店，即可享受到門店的服務，同時，門店的導購可以向自己的會員推薦所有雲店商品。
如圖例所示，門店A有100份的草莓蛋糕，門店A為自己供貨，並共享草莓蛋糕的庫存到多個銷售渠道（美團外賣、雲店、門店線下渠道），實現門店「一盤貨」全渠道銷售。
渠道庫存同步
銷售庫存計算完後，需要將渠道庫存同步到各個平台渠道，這樣，消費者才能完成交易流程。根據渠道類型不同，渠道庫存同步有兩種處理邏輯：
-
自營系統：如果自營渠道與庫存系統是一體的，即一套系統，那麼不需要過於複雜的庫存同步邏輯，自營渠道直接讀取中央庫存系統的渠道庫存即可。
-
三方平台系統：像天貓，京東，美團，餓了么等，這些三方平台系統屬於外部系統，商家自身無法管控，就需要通過開發API，向三方平台同步渠道庫存。一般而言不會實時同步渠道庫存，即只要有庫存變動，就計算渠道庫存，同步至三方平台。這種方式對系統壓力較大，而且三方平台的API大多會按調用量收費，因此，會設定好時間間隔，定期同步渠道庫存，例如5分鐘一次。
組合商品庫存計算
組合商品一般指人為將幾個單獨售賣的商品組合在一起，進行合併售賣的商品，例如：下午茶套餐、七夕美妝組合等。
組合商品會先在調度層，根據組合比例計算好虛擬庫存，不影響子商品的供貨邏輯，下單時，會根據組合商品標識，進行子商品的實物庫存預占、扣減。
中央庫存系統的應用架構設計
小結
