新零售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分鐘一次。
組合商品庫存計算
組合商品一般指人為將幾個單獨售賣的商品組合在一起，進行合併售賣的商品，例如：下午茶套餐、七夕美妝組合等。
組合商品會先在排程層，根據組合比例計算好虛擬庫存，不影響子商品的供貨邏輯，下單時，會根據組合商品標識，進行子商品的實物庫存預佔、扣減。
中央庫存系統的應用架構設計
小結
本文來自部落格園，作者：湯師爺說，轉載請註明原文連結：https://www.cnblogs.com/tangshiye/p/16768880.html