編輯導語：在跨境電商海外倉業務中，批次、庫齡等資料都是業務中的關鍵指標，然而，你知道這些資料是如何得出，又是如何被應用的嗎？本篇文章裡，作者結合自己以往的認知，對批次、庫齡和倉租等因素做了重新解讀，一起來看一下吧。
這一篇文章和之前寫的《跨境電商海外倉（10）：WMS的庫齡與倉租功能設計》是姊妹篇，兩篇內容側重點不一樣，但是說的都是一個事情。而且近期我在調研國內一些知名的WMS系統的過程中發現，有一些觀點我可能需要調整一下，所以我決定再寫一篇關於批次、庫齡和倉租這一塊的內容。
一方面是對之前文章的補充和說明，另一方面也是記錄一下自己知識的更新和迭代。產品經理應該多“懷疑”過去的自己，這樣才會有更謙卑的心態去接納和學習更多的內容。
一、WMS的批次號和庫齡無「直接關係」
庫齡是指倉庫中的貨物在倉庫中存放的時間，一般是用天來統計。
之前我一直認為庫齡和批次號是必然的關係，如果要統計庫齡那麼就一定要先生成批次號。
例如在入庫上架的時候，根據上架日期生成批次號，然後和倉位關聯，批次庫存就會增加；在出庫的時候，再根據庫位的資訊帶出批次號，然後扣減對應的批次庫存。這樣一增一減之後，批次會動態的變化，然後每日固定一個時間點去統計當前的批次庫存，最後就可以算不同的批次的庫齡是多少了。
這個方案是對的，可行的。但是我的理解太狹隘了，為了實現不同時期入庫上架的商品有不同的庫齡，不一定非要引入批次號，只需要記錄入庫/上架日期即可。
將上架日期看做是一個和批次號同級別的欄位，每次上架和下架的時候都對應的增加或扣減，也能達到計算庫齡目的。
引入「上架日期」
也就是說：上架日期不等同於批次號。
而之所以我說之前的方案是對的，是因為在WMS的批次屬性中，經常會把入庫日期或者上架日期當作一個系統預設的批次屬性。所以在誤打誤撞之間，按上架日期來生成批次號，也實現了計算庫齡的作用。
二、WMS的批次屬性才更加重要
那麼，什麼又是批次屬性呢？
關於批次屬性，初次我看到是在富勒的WMS操作手冊中，一開始我也沒看懂，直到最近我在鑽研批次和庫齡的事情，我才有了一個更加深刻的理解。
摘自富勒WMS操作手冊
簡單理解就是同一批入庫的同一款產品，雖然長得都一樣，但是可能會生產日期不同，生產批次不同，顏色不同，或者來自不同的供應商等，在方便倉庫管理的前提下，又要做一些精細化的區分，於是將這些「能區分相同商品的不同_的屬性」都定義為批次屬性。
舉個栗子，一個入庫單預報了300件優衣庫的襯衫，實際收貨了300件，如果不引入批次屬性的話，那麼就直接將這300件上架即可，對應的可用庫存也是300。但是如果引入了批次屬性的話，可以將產地作為批次屬性，也可以將生產日期或者批號作為批次屬性，這樣實際增加庫存的時候，總的可用庫存還是300，但是不同的批次下的可用庫存是不一樣的。
批次屬性示意圖
在富勒WMS系統中，定義了12個批次屬性，其他WMS也紛紛借鑑了這一種定義的方式。具體到底最開始這樣定義的是哪個，我就不知道了。
富勒WMS的12個批次屬性
菜鳥大寶WMS也是12個批次屬性
WMS的批次屬性可以做到很靈活，在後續的分波和揀貨策略中，批次屬性會很大程度的影響作業的策略。而批次屬性越多，也就會越精細，帶來的後果就是開發難度很大，維護成本很高，管理成本也很高。
所以一般的倉庫比較常用的就是入庫日期，批次號，生產日期和失效日期這幾個，而最最最常見的就是按入庫日期或者上架日期來生成批次號了，但這並不意味著算庫齡一定需要批次號。
摘自C-WMS操作手冊
三、庫齡和倉租在哪裡算？
前面解釋了批次號和庫齡並無「直接關係」，只不過是剛好很多WMS的批次號生成規則就是用入庫/上架日期來生成的而已。
那麼庫齡和倉租是否有直接關係呢？
答案是：有直接關係，而且是必然的直接關係。
因為倉租其實就是庫齡*單價*計費單位（體積或重量）算出來的，知道了庫齡，那麼結合單價和計費單位就一定可以算出倉租來。
關於庫齡如何計算，我之前寫的文章《跨境電商海外倉：WMS的庫齡與倉租功能設計》已經有很詳細的介紹了，大家在看的時候注意理解我那篇文中所說的「批次號」即可。
那篇文章中的批次號一般是指入庫/上架日期，但是如果你的批次號是透過其他方式生成的，有其他用處，那麼就需要單獨用一個入庫/上架日期來記錄庫齡。如果沒有其他用處，那麼就用批次號來計算庫齡也是可以的。
在這裡我想額外來補充聊聊關於倉租的計算應該放在哪裡，放在什麼系統會更好？
庫齡資料來自於WMS，按理說放在WMS上去算肯定是最好的，或者說由WMS去提供資料，然後在BMS中計算。
但是按照我之前的設計方案我發現了這樣做會有一個弊端，理解起來可能會有點繞，大家可以仔細閱讀，揣摩一下。
當WMS根據上架日期來生成批次號之後，在揀貨的時候，由於系統會根據先進先出的規則進行庫位的推薦，但是由於沒有做「強推薦」，倉庫還是可以根據自己的實際經驗去揀貨，也就是不按推薦的庫位來揀貨，所以此刻在扣減庫存的時候並沒有做到完全的先進先出。
這個問題會導致在計算庫齡的時候，並不是嚴格的先進先出，只是做到了「庫位上的先進先出」，於是當客戶在檢視庫齡的時候會發現，有一些更早的批次沒有出庫，反而更晚一些的批次已經出庫了。
這個問題一般的解決方案是：最佳化揀貨推薦的策略，對倉庫揀貨實行「強推薦」，即強制客戶在推薦的庫位揀貨，確保一定可以先進先出。
但是在實際的倉庫管理中，要做到嚴謹的先進先出其實很難，付出的成本也會很高，而且對於海外倉來說，本來管理倉庫就已經是一件難事了，還要加上一些精細化的管理（嚴格先進先出），那無異於難上加難，幾乎不太能實現。
即使是解決了上述問題之後，還會遇到另外一個問題，那就是跨境電商海外倉系統隨著業務發展，很容易出現「第三方海外倉」或者「代理海外倉」的概念。
客戶使用了我的美國倉，但是他還需要使用英國倉，但是我沒有辦法提供英國倉。要麼他繼續去找另外的海外倉，然後分別使用兩套系統操作，這樣會很麻煩；要麼我去對接其他家的海外倉，然後把自己當做一個「代理倉」的角色，客戶可以從我這裡推送訂單到其他倉庫，實現一套系統接入多個倉庫。
當有了上述的業務之後，如果客戶要使用我的OMS向其他海外倉推送資料，那麼他大機率是不會用第三方海外倉的OMS，也就是我需要承擔部分第三方海外倉的功能。
其中庫齡和倉租的計算需求也就開始有了差異化的解決方案了。
綜合上述背景，我個人建議在哪裡統計庫齡和倉租，要結合自身的業務來考量，方案都會有利弊：
- 如果揀貨沒有做到「強推薦」，那麼建議在OMS端；
- 如果有「第三方海外倉」，那麼建議在OMS端；
- 如果揀貨可以「強推薦」，也沒有「第三方海外倉」，則在WMS和OMS端都可以；
OMS端統計庫齡可以採用自己計算或者讓WMS推送資料的方式。
如果是讓WMS推送資料，那麼OMS端只是展示一個結果，資料應該是會和WMS端保持一致的。那麼就要重點考慮WMS的一些出庫策略是否會對庫齡的計算有所影響，按理說庫齡的統計應該是先進先出的，這樣可以確保使用者花費的錢最少。
如果是讓OMS端自己計算庫齡並存儲，那麼OMS就需要根據入庫/上架，出庫完成的時間節點分別去計算不同批次的庫存的變化。這樣可能會出現OMS計算的庫齡和WMS端計算的庫齡不一樣的情況，因為扣減批次庫存的邏輯可能會不一樣，最後導致受影響的庫存批次會不太一樣。
四、總結
對於批次，庫齡和倉租，之前我一直感覺不太踏實，總感覺自己有一些東西沒想透徹，沒理解到位。經過這幾天查閱資料，再加上整理成文的過程，我發現我對這個東西不踏實感已經逐漸地消失了。
最早的時候，我以為批次很簡單，無非就是按日期記錄然後保證全流程都考慮到它的變化就好了。
後來看到了別人很複雜的批次屬性，我又發現自己好像對批次的理解不太到位，不太確定方案是否有坑。導致對做出來的功能總是不太滿意，隱約覺得會出問題。
到了現在，當我寫完了好幾篇關於這個東西的文章之後，我發現我基本上理解了這些東西，不再模糊，也不再恐懼，反而覺得好像也不是很難。
這個心路歷程剛好對應了：「看山是山，看山不是山，看山還是山」的故事。
看完我的分享，希望螢幕前的你，也可以做到！
#專欄作家#
我叫維他命（Vitamin），微信公眾號：PM維他命。前PHPer，做過線上教育類產品，也做過4年多的跨境倉儲物流方向的產品，目前是一位外貿SaaS領域的供應鏈產品經理。主要專注於WMS/OMS/TMS/BMS/ERP等領域，分享供應鏈相關的產品知識。
本文原創釋出於人人都是產品經理，未經作者許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議
