這一篇文章和之前寫的《跨境電商海外倉：WMS的庫齡與倉租功能設計》是姊妹篇，兩篇內容側重點不一樣，但是說的都是一個事情。而且近期我在調研國內一些知名的WMS系統的過程中發現，有一些觀點我可能需要調整一下，所以我決定再寫一篇關于批次，庫齡和倉租這一塊的內容。

一方面是對之前文章的補充和說明，另一方面也是一個記錄一下自己固有知識的更新和升級。

WMS的批次號和庫齡無「直接關系」

庫齡是指倉庫中的貨物在倉庫中存放的時間，一般是用天來統計。

之前我一直認為庫齡和批次號是必然的關系，如果要統計庫齡那么就一定要先生成批次號。例如在入庫上架的時候，根據上架日期生成批次號，然后和倉位關聯，批次庫存就會增加；在出庫的時候，再根據庫位的信息帶出批次號，然后扣減對應的批次庫存。這樣一增一減之后，批次會動態的變化，然后每日固定一個時間點去統計當前的批次庫存，最后就可以算不同的批次的庫齡是多少了。

這個方案是對的，可行的。但是我的理解太狹隘了，為了實現不同時期入庫上架的商品有不同的庫齡，不一定非要引入批次號，只需要記錄入庫/上架日期即可。

將上架日期看做是一個和批次號同級別的字段，每次上架和下架的時候都對應的增加或扣減，也能達到計算庫齡目的。

也就是說：上架日期不等同于批次號。

而之所以我說之前的方案是對的，是因為在WMS的批次屬性中，經常會把入庫日期或者上架日期當作一個系統預設的批次屬性。所以在誤打誤撞之間，按上架日期來生成批次號，也實現了計算庫齡的作用。

WMS的批次屬性才更加重要

那么，什么又是批次屬性呢？

關于批次屬性，初次我看到是在富勒的WMS操作手冊中，一開始我也沒看懂，直到最近我在鉆研批次和庫齡的事情，我才有了一個更加深刻的理解。

簡單理解就是同一批入庫的同一款產品，雖然長得都一樣，但是可能會生產日期不同，生產批次不同，顏色不同，或者來自不同的供應商等，在方便倉庫管理的前提下，又要做一些精細化的區分，于是將這些「能區分相同商品的不同_的屬性」都定義為批次屬性。

舉個栗子，一個入庫單預報了300件優衣庫的襯衫，實際收貨了300件，如果不引入批次屬性的話，那么就直接將這300件上架即可，對應的可用庫存也是300。但是如果引入了批次屬性的話，可以將產地作為批次屬性，也可以將生產日期或者批號作為批次屬性，這樣實際增加庫存的時候，總的可用庫存還是300，但是不同的批次下的可用庫存是不一樣的。

在富勒WMS系統中，定義了12個批次屬性，其他WMS也紛紛借鑒了這一種定義的方式。具體到底最開始這樣定義的是哪個，我就不知道了。

WMS的批次屬性可以做到很靈活，在后續的分波和揀貨策略中，批次屬性會很大程度的影響作業的策略。而批次屬性越多，也就會越精細，帶來的后果就是開發難度很大，維護成本很高，管理成本也很高。

所以一般的倉庫比較常用的就是入庫日期，批次號，生產日期和失效日期這幾個，而最最最常見的就是按入庫日期或者上架日期來生成批次號了，但這并不意味著算庫齡一定需要批次號。

庫齡和倉租在哪里算？

前面解釋了批次號和庫齡并無「直接關系」，只不過是剛好很多WMS的批次號生成規則就是用入庫/上架日期來生成的而已。

那么庫齡和倉租是否有直接關系呢？

答案是：有直接關系，而且是必然的直接關系。

因為倉租其實就是庫齡*單價算出來的，知道了庫齡，那么結合單價就一定可以算出倉租來。

關于庫齡如何計算，我之前寫的文章《跨境電商海外倉：WMS的庫齡與倉租功能設計》已經有很詳細的介紹了，大家在看的時候注意理解我文中所說的「批次號」即可。那篇文章中的批次號一般是指入庫/上架日期，但是如果你的批次號是通過其他方式生成的，有其他用處，那么就需要單獨用一個入庫/上架日期來記錄庫齡。如果沒有其他用處，那么就用批次號來計算庫齡也是可以的。

在這里我重點想聊聊關于倉租的計算應該放在哪里，放在什么系統會更好？

庫齡數據來自于WMS，按理說放在WMS上去算肯定是最好的，或者說由WMS去提供數據，然后再BMS中計算。

但是按照我之前的設計方案我發現了這樣做會有一個弊端，理解起來可能會有點繞，大家可以仔細閱讀，揣摩一下。

當WMS根據上架日期來生成批次號之后，在揀貨的時候，由于系統會根據先進先出的規則進行庫位的推薦，但是由于沒有做「強推薦」，倉庫還是可以根據自己的實際經驗去揀貨，也就是不按推薦的庫位來揀貨，所以此刻在扣減庫存的時候并沒有做到完全的先進先出。

這個問題會導致在計算庫齡的時候，并不是嚴格的先進先出，只是做到了「庫位上的先進先出」，于是當客戶在查看庫齡的時候會發現，有一些更早的批次沒有出庫，反而更晚一些的批次已經出庫了。

這個問題的解決方案是：優化揀貨推薦的策略，對倉庫揀貨實行「強推薦」，即強制客戶在推薦的庫位揀貨，確保一定可以先進先出。

在解決了上述問題之后，還會遇到另外一個問題，那就是跨境電商海外倉系統隨著業務發展，很容易出現「第三方海外倉」或者「代理海外倉」的概念。

客戶使用了我的美國倉，但是他還需要使用英國倉，但是我沒有辦法提供英國倉。要么他繼續去找另外的海外倉，然后分別使用兩套系統操作，這樣會很麻煩；要么我去對接其他家的海外倉，然后把自己當做一個「代理倉」的角色，客戶可以從我這里推送訂單到其他倉庫，實現一套系統接入多個倉庫。

當有了上述的業務之后，如果客戶要使用我的OMS向其他海外倉推送數據，那么他大概率是不會用第三方海外倉的OMS，也就是我需要承擔部分第三方海外倉的功能。

其中庫齡和倉租的計算需求也就開始有了差異化的解決方案了。

綜合上述背景，我個人建議在哪里統計庫齡和倉租，要結合自身的業務來考量，都有利弊：

1. 如果揀貨沒有做到「強推薦」，那么建議在OMS端；

2. 如果有「第三方海外倉」，那么建議在OMS端；

3. 如果揀貨可以「強推薦」，也沒有「第三方海外倉」，則在WMS和OMS端都可以；

OMS端統計庫齡可以采用自己計算或者讓WMS推送數據的方式。

如果是讓WMS推送數據，那么OMS端只是展示一個結果，數據應該是會和WMS端保持一致的。那么就要重點考慮WMS的一些出庫策略是否會對庫齡的計算有所影響，按理說庫齡的統計應該是先進先出的，這樣可以確保用戶花費的錢最少。

如果是讓OMS端自己計算庫齡并存儲，那么OMS就需要根據入庫/上架，出庫完成的時間節點分別去計算不同批次的庫存的變化。這樣可能會出現OMS計算的庫齡和WMS端計算的庫齡不一樣的情況，因為扣減批次庫存的邏輯可能會不一樣，最后導致受影響的庫存批次會不太一樣。

總結

對于批次，庫齡和倉租，之前我一直感覺不太踏實，總感覺自己有一些東西沒想透徹，沒理解到位。經過這幾天查閱資料，再加上整理成文的過程，我發現我對這個東西不踏實感已經逐漸地消失了。

最早的時候，我以為批次很簡單，無非就是按日期記錄然后保證全流程都考慮到它的變化就好了。

后來看到了別人很復雜的批次屬性，我又發現自己好像對批次的理解不太到位，總是不太踏實。導致對做出來的功能總是不太滿意，隱約覺得會出問題。

到了現在，當我寫完了好幾篇關于這個東西的文章之后，我發現我基本上理解了這些東西，不再模糊，也不再恐懼，反而覺得好像也不是很難。

這個心路歷程剛好對應了：「看山是山，看山不是山，看山還是山」 的故事。