如何理解供應(yīng)鏈系統(tǒng)（ERP和WMS）中的貨主、實體倉和邏輯倉？這篇文章里，作者基于自己關(guān)于實際業(yè)務(wù)場景和相關(guān)底層邏輯的調(diào)研和研究，梳理并分享了自己的看法和觀點。一起來看看這篇文章。

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

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

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

一、名詞定義

1. 貨主

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

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

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

圖源：金蝶ERP

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

多組織架構(gòu)模式下的供應(yīng)鏈業(yè)務(wù)示例

貨主的定義在不同的系統(tǒng)，不同的領(lǐng)域是會有區(qū)分的。如果在負責業(yè)財一體化相關(guān)的業(yè)務(wù)或者是多組織架構(gòu)模式下的供應(yīng)鏈業(yè)務(wù)時候，需要特別注意一下，可以參考金蝶的玩法。

2. 實體倉

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

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

3. 邏輯倉

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

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

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

實體倉和邏輯倉

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

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

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

ERP和WMS的貨主、倉庫的關(guān)系

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

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

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

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

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

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

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

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

ERP只有一個貨主，也只有一個實體倉，如果需要引入邏輯倉相關(guān)的業(yè)務(wù)場景，那么就必然會創(chuàng)建多個邏輯倉，用來支撐相關(guān)的業(yè)務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

此時可能會有6.1和6.2的玩法區(qū)分：

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

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

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

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

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

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

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

ERP多貨主和WMS單貨主關(guān)系

三、多種場景的具體分析和庫存結(jié)構(gòu)推演

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

邏輯倉和實體倉的庫區(qū)/庫位映射

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

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

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

ERP多貨主和WMS單貨主關(guān)系

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

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

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

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

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

1. 為什么會有多貨主？

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

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

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

2. 一對一的場景

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

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

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

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

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

3. 多對一的場景

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

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

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

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

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

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

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

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

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

總結(jié)

供應(yīng)鏈系統(tǒng)中的貨主和倉庫都是非常基礎(chǔ)且常見的概念，但是在不同的業(yè)務(wù)場景下，不同的系統(tǒng)邏輯下，會有很多種不同的玩法，讓我時常有一種“看山是山，看山不是山”的感覺。

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

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

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

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