如何理解供應鏈系統（ERP和WMS）中的貨主、實體倉和邏輯倉？這篇文章里，作者基于自己關于實際業務場景和相關底層邏輯的調研和研究，梳理并分享了自己的看法和觀點。一起來看看這篇文章。

在2023年10月份的時候，我寫了一篇名為《供應鏈系統中的倉庫類型拆解：實體倉、邏輯倉、虛擬倉》的文章，主要是分享了一下我對實體倉、邏輯倉、虛擬倉的一些理解和認知。

我一直覺得大量濫用邏輯倉是一個不太優雅的、不太簡潔的產品設計方案，帶來的一些隱患和弊端非常之大，于是就很想要重構這一塊的邏輯。

過去這段時間趁著一些機會對實際的業務場景和相關的底層邏輯做了更深入的調研和研究，然后發現歷史包袱想要拋棄掉估計是不太行了。但是既然都做了調研了，還是得要把一些經驗、知識、感悟什么的記錄下來，萬一以后有機會從零開始再做一次類似的項目呢，于是就有了這一篇文章。

一、名詞定義

1. 貨主

貨主，可以理解為“貨物的擁有者”，也就是說貨物歸屬于誰。在WMS倉儲系統中，貨主的定義一般比較簡單純粹，通常是在簽約合作的時候就配置好貨主編碼，后續的作業單據中也指明相關的貨主信息。但是在ERP系統或者財務結算類系統（金蝶、用友等），可能貨主的概念就會復雜一些。

例如說集團和分公司之間的采購模式可能會有多種，不同的采購模式對應的采購方，收貨方，結算方，還有貨主也是不一樣。

圖源：金蝶ERP

例如“張李科技有限公司”是總公司，下面會有三個子公司，雖然這三個子公司很多業務上的操作是會一樣，但是由于財務層面需要做獨立核算，所以在財務核算的時候是需要做一些區分的。ERP統計不同公司（貨主）的庫存或者用來不同公司（貨主）的庫存成本的去做結算的時候，是需要嚴格區分貨主的，因為ERP需要算清楚每一筆庫存的變化，到底是屬于張三，還是李四或王五。

多組織架構模式下的供應鏈業務示例

貨主的定義在不同的系統，不同的領域是會有區分的。如果在負責業財一體化相關的業務或者是多組織架構模式下的供應鏈業務時候，需要特別注意一下，可以參考金蝶的玩法。

2. 實體倉

實體倉的定義比較簡單，就是指真實存在的倉庫，這種倉庫有具體的倉庫名稱和編碼，有物理地址，有聯系人信息等，屬于供應鏈系統中最常見的“倉庫”的概念。實體倉通常位于實際的物流節點，可以是公司自己擁有或租賃的倉庫，也可以是第三方物流提供商的倉庫。實體倉用于存儲、分揀、包裝和分發貨物，是供應鏈中實際操作的環節。

例如說某個系統中有“東莞一倉”，這是一個實體倉，通過這個倉庫名稱可以在系統中查詢到相關的倉庫基礎信息，倉庫中的貨主信息，倉庫中的庫存信息等。

3. 邏輯倉

邏輯倉是基于實體倉而衍生出來的概念，現實情況下一般實體倉的數量是有限的、較少的，也就意味著用“實體倉”的維度去查詢一些信息的時候粒度會比較粗糙。而在實際的業務發展過程中，如果某個公司要對庫存有更精細化的庫存管理，那么只用“實體倉”這個字段是不夠的。

邏輯倉可以根據不同的需求和策略劃分為不同的區域、庫位或存儲單元，用于管理庫存和貨物的流動。邏輯倉可以通過供應鏈管理軟件進行管理，記錄和跟蹤庫存信息、訂單流程和庫存變動等。邏輯倉的劃分可以基于產品屬性、銷售渠道、地理位置等因素進行。

例如在某個實體倉中，劃分了多個區域，這不同的區域歸屬于同一個公司下不同的業務部門，每個部門獨立占用其中一塊區域作為自己的庫存管理區域，常見的做法就是會引入邏輯倉。

實體倉和邏輯倉

二、ERP和WMS的貨主、實體倉、邏輯倉的場景初步分析

在多組織架構模式下，ERP系統中的貨主、實體倉、邏輯倉的關聯關系會有多種組合，不同組合的邏輯關系解釋如下。為了簡化理解，以下的推演都是建立在只有一個實體倉的情況下，暫不考慮多地多倉的情況。

ERP系統中存在一個貨主和一個實體倉，或者是多個貨主和一個實體倉的場景具有最高的普適性。也就是無論是單貨主還是多貨主都會把貨物存放在一個實體倉中，如果多貨主存放在一個實體倉但是又需要做一些更精細化的區分時，會考慮引入邏輯倉，就會變成“多貨主+單實體倉+多邏輯倉”的玩法。

ERP和WMS的貨主、倉庫的關系

場景1：單貨主，單實體倉，無邏輯倉

非常高頻常見，是見得最多，最常用的一種方案。

ERP只有一個貨主，也只有一個實體倉，在創建入庫單或者出庫單的時候，直接下拉選擇對應的貨主編碼或者倉庫編碼即可。當只有一個貨主的時候，貨主可以直接省略，默認程序處理邏輯的時候自帶這個貨主編碼即可；而只有一個倉庫的時候也可以這樣做，但是實際上倉庫一般會有多個，所以倉庫一般支持靈活選擇。

場景2：單貨主，單實體倉，單邏輯倉

比較少見，不怎么常用的方案。

ERP只有一個貨主，也只有一個實體倉，一般不會額外再去創建一個邏輯倉了，這樣完全沒必要，所以這種場景幾乎不存在。

場景3：單貨主，單實體倉，多邏輯倉

沒有那么高頻，但是對于復雜的業務場景下，一般都會選擇這種方案。

ERP只有一個貨主，也只有一個實體倉，如果需要引入邏輯倉相關的業務場景，那么就必然會創建多個邏輯倉，用來支撐相關的業務。

例如說：實體倉是“深圳坂田倉”，但是由于業務需要區分正向采購和逆向退回的貨物，那么就會引入“深圳坂田正向商品倉”和“深圳坂田逆向商品倉”，這樣的邏輯倉來支撐相關的業務。

場景4：多貨主，單實體倉，無邏輯倉

非常高頻常見，比第一種方案稍微少一些。

ERP有多個貨主，因為同一套公司里面可能包含了不同的集團、公司、子公司、部門等，這些都可能是貨主，但是依然只有一個實體倉。而且在實物管理的時候，這些不同的貨主都會具有相同的商品。

當出現這種情況，倉庫端一般會選擇也創建多個貨主，這樣可以和ERP的貨主對應上。此時在倉庫端的庫存是：張三+iPhone15+深圳坂田倉，李四+iPhone15+深圳板田倉

而在ERP端的庫存也是：張三+iPhone15+深圳坂田倉，李四+iPhone15+深圳板田倉……

這樣在實體倉中，可以通過貨主來區分具體的商品到底是哪個貨主的，用來計算庫存也會更加簡單方便。

場景5：多貨主，單實體倉，單邏輯倉

比較少見，不怎么常用的方案。

ERP有多個貨主，也只有一個實體倉，一般不會額外再去創建一個邏輯倉了，這樣完全沒必要，所以這種場景幾乎不存在。

場景6：多貨主，單實體倉，多邏輯倉

沒有那么高頻，但是對于復雜的業務場景下，一般都會選擇這種方案。

ERP有多個貨主，因為同一套公司里面可能包含了不同的集團、公司、子公司、部門等，這些都可能是貨主。當只有一個實體倉的時候，如果又要引入邏輯倉相關的業務場景，那么就必然會創建多個邏輯倉，用來支撐相關的業務。

此時可能會有6.1和6.2的玩法區分：

• 6.1就是倉庫還是會創建多貨主；
• 6.2則是倉庫只有一個貨主。

當選擇了6.1的方案時，實體倉是“深圳坂田倉”，但是由于業務需要區分正向采購和逆向退回的貨物，那么就會引入“深圳坂田正向商品倉”和“深圳坂田正向商品倉”，這樣的邏輯倉來支撐相關的業務。

此時，在倉庫端的庫存查詢是：張三+iPhone15+深圳坂田倉，李四+iPhone15+深圳板田倉……

而在ERP中，查詢庫存的時候是：張三+iPhone15+深圳坂田正向商品倉，李四+iPhone15+深圳坂田正向商品倉……

當選擇了6.2的方案時，實體倉是“深圳坂田倉”，但是由于業務需要區分正向采購和逆向退回的貨物，那么就會引入“深圳坂田正向商品倉”和“深圳坂田正向商品倉”，這樣的邏輯倉來支撐相關的業務。不過此時，倉庫端只有一個貨主，所以在倉庫端的庫存查詢是：簽約貨主+iPhone15+深圳坂田倉……

而在ERP中，查詢庫存的時候是：張三+iPhone15+深圳坂田正向商品倉，李四+iPhone15+深圳坂田正向商品倉……

這種方案下，倉庫端只有一個貨主，而ERP有多個貨主，當倉庫端主動發起一些庫存變動時，則ERP需要經常性去做“貨主分配”的操作，因為一對多的場景下，“一”方主動反饋數據，“多”方是需要指定分配去接收的。

ERP多貨主和WMS單貨主關系

三、多種場景的具體分析和庫存結構推演

場景1：單貨主，單實體倉，無邏輯倉

這種場景的業務模式是最簡單的，哪怕是有異地多倉，ERP也可以很輕松就統計出多倉的庫存情況。一般適用于業務模式單一的場景，例如說進銷存，自建電商系統，簡單的ERP，海外倉業務等系統就會使用這種方案。

場景2：單貨主，單實體倉，單邏輯倉

此場景幾乎不存在，不具有什么分析的價值，一般要引入邏輯倉的時候一定是會多個，而不會只有一個，所以此處直接跳過相關的拆解分析。

場景3：單貨主，單實體倉，多邏輯倉

當ERP系統有多個邏輯倉的時候，邏輯倉需要和實體倉配置好對應的關系，然后在庫存表中一般只需要使用邏輯倉即可?？梢酝ㄟ^置邏輯倉，去找到背后對應的實體倉，然后推送單據到具體的實體倉中。ERP中的實體倉編碼和WMS的倉庫編碼保持一致，或者也可以不一致，通過一對一映射的方式解決即可。

如果ERP使用了多個實體倉，則每一個實體倉都要映射相應的邏輯倉，最后會形成N*M個邏輯倉。日常業務還是用邏輯倉，實體倉只是ERP和外部WMS系統對接時使用的。

場景4：多貨主，單實體倉，無邏輯倉

當ERP引入了多貨主之后，ERP層面只是在庫存維度上再增加一個新貨主即可，但是一般倉庫端會有兩種情況：

1. 單貨主，即倉庫和ERP的一個貨主簽約了，一般會和ERP的一個總公司/結算主體簽約，例如下圖中的張李科技；
2. 多貨主，即倉庫和ERP的多個貨主簽約了，一般是ERP有幾個貨主，倉庫也是有幾個貨主；

當倉庫端只有一個單貨主，而ERP有多貨主時，ERP是按具體的貨主來分別統計庫存，而WMS端則是按單個簽約的貨主統計庫存，兩者并不是一一對應的，涉及到庫存的分配邏輯。

場景5：多貨主，單實體倉，單邏輯倉

此場景幾乎不存在，不具有什么分析的價值，一般要引入邏輯倉的時候一定是會多個，而不會只有一個，所以此處直接跳過相關的拆解分析。

場景6.1：多貨主，單實體倉，多邏輯倉，且倉庫端也是多貨主

和場景3相比，ERP增加了多貨主的場景，也就是說ERP端會有多貨主，然后WMS端也會有多個貨主，一般兩者都是一一對應的。同時又引入了多邏輯倉，所以ERP也需要把邏輯倉和實體倉配置好對應的關系，日常業務還是使用邏輯倉，但是需要和外部WMS系統交互的時候再使用實體倉。

ERP有兩個貨主分別是張三和李四，然后在WMS端也是有兩個貨主，分別是張三和李四；ERP有多個邏輯倉，而WMS中就會有相應的區域/庫區去做區分。

在上一篇文章《供應鏈系統中的倉庫類型拆解：實體倉、邏輯倉、虛擬倉》講過，當引入了邏輯倉之后，要確認邏輯倉的庫存和實體倉的庫存是怎么聯動的，則需要提前定義好兩者的“映射關系”。業內一般會有兩種做法，一種是有映射關系，一種是沒有映射關系。上圖中演示的就是有映射關系的做法。

邏輯倉和實體倉的庫區/庫位映射

場景6.2：多貨主，單實體倉，多邏輯倉，且倉庫端是單貨主

和場景6.1相比，最大的區別就是倉庫端的貨主是單貨主，6.2的場景下意味著ERP端是多貨主，而WMS端則是單貨主，需要做多對一的映射關系。多邏輯倉的業務模式還是保持一致，日常業務還是使用邏輯倉，但是需要和外部WMS系統交互的時候再使用實體倉。

ERP有兩個貨主分別是張三和李四，然后在WMS端只有單個貨主，即張李科技。意味著倉庫只和ERP的一個貨主簽約了，一般會和ERP的一個總公司/結算主體簽約，例如上圖中的張李科技。

ERP多貨主和WMS單貨主關系

四、ERP端多貨主&倉庫端單/多貨主的對比

ERP的貨主可以是單個或者多個，WMS的貨主也可以是單個或者多個，所以組合之后就是2*2=4種關系。

ERP是單貨主，WMS也是單貨主，這種沒什么優劣勢之分，就是最常用的方案，所以不做分析。同時ERP是單貨主，但WMS是多貨主，這種情況一般不存在，所以也不做分析。

所以剩下要分析對比的就是ERP是多貨主，WMS是單貨主或者WMS也是多貨主這兩種情況，由于這兩種場景各有優劣，不同的公司/團隊中在選擇的時候往往也會產生一些分歧和爭議，所以應該重點分析對比這兩種情況。

• ERP是多貨主，WMS也是多貨主，則稱為：一對一關系；
• ERP是多貨主，WMS的單貨主，簡稱為：多對一關系。

1. 為什么會有多貨主？

ERP存在多個貨主的時候，往往是因為同一個集團公司下，會有不同的子集團、子公司、分公司等，這些組織在金蝶的體系下都稱之為“業務單元”，然后如果這些“業務單元”要支持結算的話，就會被定義為“結算組織”。

為了降低大家的理解成本，可以先不考慮這些概念或者名詞定義，簡單來說就是：一款自研型ERP，內部涉及到多個公司，多個主體，這些主體在財務層面需要分開結算。

張李科技有限公司是總公司，下面會有三個子公司，這三個子公司需要分開核算，雖然很多業務上的操作是會一樣，但是財務層面的結算時需要區分。ERP在統計不同公司（貨主）的庫存，或者用來不同公司（貨主）的庫存成本的去做結算的時候，是需要嚴格區分貨主的，因為ERP需要算清楚每一筆庫存的變化，到底是屬于張三，還是李四或王五。

2. 一對一的場景

ERP上有多個貨主，如果此時對接的外部倉庫也有多個貨主，那么無論是ERP主動推送單據給倉庫，還是倉庫主動發起一些庫存變更給ERP，都可以在單據上帶上“貨主”字段，這樣雙方核對數據，業務往來等，都是最簡單，最輕松的，所以這個方案也是最多選擇的。

但是這個方案自然也會有弊端，它最大的弊端就是：倉庫存在多貨主，會增加倉庫作業的成本，帶來了一些額外的支出。

1. 對接外部倉庫的時候，需要和外部倉庫簽約，此時就需要簽約多個主體，然后維護多份數據。這個改造的成本也不是很大，只是稍微麻煩了一點點；
2. 倉庫有多貨主的情況下，如果要給倉庫下銷售單，那么就要明確給出具體是要出哪個貨主的貨，這些貨物可能都是送到同一個地點，此時就要倉庫支持多貨主的出庫貨物合并打包，然后統一送到一個地點。這種包裹合并發貨的功能，一些大倉庫也是支持的，不過會增加一定的操作成本；
3. 張三、李四、王五的貨物可能都是相同的，這個時候倉庫端在管理這些庫存的時候需要考慮哪些可以混貨主存放，哪些不能混貨主存放，無形中會增加庫存占用空間，同時倉庫在作業的時候也要時刻去區分不同的貨主，會帶來一定的操作成本增加；
4. 倉庫使用了多貨主之后，在后續對賬、核對的時候，工作量也可能會翻倍，尤其是如果公司并不需要在實物層嚴格區分貨主的時候，這種操作就比較麻煩了。

綜合上述分析可知，如果多貨主的商品、業務模式等比較雷同，那么會出現大量的重復性操作，此時如果倉庫端還是使用多貨主模式去管理，就會增加沒必要的成本，反而會帶來效率的降低。所以這種方案比較適合于：

多貨主的商品，業務模式都不太一樣，而且希望能在實物層嚴格區分管理的業務場景下。

3. 多對一的場景

分析完了上述的一對一的場景，接下來可以看看多對一的玩法是怎么樣的。ERP上還是有多個貨主，但是和外部倉庫簽約的時候，只簽約一個主體，相當于在倉庫端其實只有一個貨主。這樣就會構成多對一的情況：ERP是多貨主，WMS是單貨主。

這種方案的優勢其實就是“一對一場景”的劣勢，它適用于：

多貨主的商品、業務模式都很一樣，在業務操作層基本上不需要特殊區分，只是財務/賬務層面要做庫存的區分而已。

采用這種方案之后，ERP可以按多貨主的邏輯去建單，去操作，然后推送給到WMS之后，WMS只有一個貨主，只有一種操作邏輯和管理要求，可以有效地節省操作成本，同時也降低了一些管理的復雜度。

而采用了這種方案之后，最大的弊端就是需要ERP做大量的“分配貨主”的功能，需要業務定好清晰的規則，同時系統也要能比較完善地支撐這些需求。在多對一的場景下，若“多方”發起單據，“一方”是可以直接接收并處理的；而如果是反過來，“一方”發起單據，“多方”是不能直接接收并處理的，因為不知道具體是誰來處理，所以就需要制定好分配邏輯。

如果是倉庫端（一方）主動發起的單據，ERP端（多方）去接收的時候，都會涉及到分配的邏輯：

1. 倉庫端發現破損/丟失，主動發起盤虧或者發起盤盈，需要分配貨主；
2. 倉庫端對商品庫存的狀態進行變更，例如正常轉臨期，臨期轉過期，正品轉次品等，需要分配貨主；
3. 倉庫端發起的對庫存的變更，調整，ERP端如果需要記錄和知曉的，都需要分配貨主；

結合上面的分析可以知道，多對一的場景下，WMS側的操作相對來說會簡單清晰很多，比較利于節省成本和提升倉庫的作業效率，而對應的弊端就是會存在一些實物和系統庫存不能精確匹配，在庫存邏輯數量層面需要強依賴信息化系統（ERP）的分配策略。

所以如果采用了此方案，那么對于ERP端來說一方面要做好和倉庫端的接口對接，把倉庫端的一些核心庫存信息都抓取回來，包含但不限于：商品質量情況（良品，不良品），生產日期，失效日期，生產批號，商品關聯的單號等。另一方面也要制定好完善的多貨主庫存分配邏輯，明確在什么場景下先增加/扣減哪個貨主的庫存，然后扣減的庫存關聯的顆粒度是什么維度，例如“貨主+SKU”，“貨主+SKU+批次”，“貨主+SKU+批次+序列號”……

總結

供應鏈系統中的貨主和倉庫都是非?；A且常見的概念，但是在不同的業務場景下，不同的系統邏輯下，會有很多種不同的玩法，讓我時常有一種“看山是山，看山不是山”的感覺。

早期做海外倉的時候，貨主和倉庫的邏輯都很簡單，后面陸續接觸了ERP之后發現貨主和倉庫其實也可以做得比較復雜，定義更加細分，最后通過一些調研并輸出了這一篇文章之后，我感覺這里其實依然還有很多地方可以做文章。

以上的內容更多是作為一個業務調研和方案調研之后的推演結果記錄和思考，其中有一些方案是工作中已經接觸過，并且知道了優勢和弊端是什么的。而有一些則是根據當前的采用的模式去反推的另一種可能解法，只是推演而已，所以一些優劣勢分析可能還不夠全面，也不夠精細化……

非常希望有相關實踐經驗的朋友看完文章之后，可以一起交流、討論、互相學習一波。

供應鏈之路，道阻且長，期待更多同行者一起交流學習……