編輯導(dǎo)語：在跨境電商海外倉業(yè)務(wù)中，批次、庫齡等數(shù)據(jù)都是業(yè)務(wù)中的關(guān)鍵指標(biāo)，然而，你知道這些數(shù)據(jù)是如何得出，又是如何被應(yīng)用的嗎？本篇文章里，作者結(jié)合自己以往的認(rèn)知，對批次、庫齡和倉租等因素做了重新解讀，一起來看一下吧。

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

一方面是對之前文章的補(bǔ)充和說明，另一方面也是記錄一下自己知識的更新和迭代。產(chǎn)品經(jīng)理應(yīng)該多“懷疑”過去的自己，這樣才會有更謙卑的心態(tài)去接納和學(xué)習(xí)更多的內(nèi)容。

一、WMS的批次號和庫齡無「直接關(guān)系」

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

之前我一直認(rèn)為庫齡和批次號是必然的關(guān)系，如果要統(tǒng)計庫齡那么就一定要先生成批次號。

例如在入庫上架的時候，根據(jù)上架日期生成批次號，然后和倉位關(guān)聯(lián)，批次庫存就會增加；在出庫的時候，再根據(jù)庫位的信息帶出批次號，然后扣減對應(yīng)的批次庫存。這樣一增一減之后，批次會動態(tài)的變化，然后每日固定一個時間點去統(tǒng)計當(dāng)前的批次庫存，最后就可以算不同的批次的庫齡是多少了。

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

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

引入「上架日期」

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

而之所以我說之前的方案是對的，是因為在WMS的批次屬性中，經(jīng)常會把入庫日期或者上架日期當(dāng)作一個系統(tǒng)預(yù)設(shè)的批次屬性。所以在誤打誤撞之間，按上架日期來生成批次號，也實現(xiàn)了計算庫齡的作用。

二、WMS的批次屬性才更加重要

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

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

摘自富勒WMS操作手冊

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

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

批次屬性示意圖

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

富勒WMS的12個批次屬性

菜鳥大寶WMS也是12個批次屬性

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

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

摘自C-WMS操作手冊

三、庫齡和倉租在哪里算？

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

那么庫齡和倉租是否有直接關(guān)系呢？

答案是：有直接關(guān)系，而且是必然的直接關(guān)系。

因為倉租其實就是庫齡*單價*計費(fèi)單位（體積或重量）算出來的，知道了庫齡，那么結(jié)合單價和計費(fèi)單位就一定可以算出倉租來。

關(guān)于庫齡如何計算，我之前寫的文章《跨境電商海外倉：WMS的庫齡與倉租功能設(shè)計》已經(jīng)有很詳細(xì)的介紹了，大家在看的時候注意理解我那篇文中所說的「批次號」即可。

那篇文章中的批次號一般是指入庫/上架日期，但是如果你的批次號是通過其他方式生成的，有其他用處，那么就需要單獨用一個入庫/上架日期來記錄庫齡。如果沒有其他用處，那么就用批次號來計算庫齡也是可以的。

在這里我想額外來補(bǔ)充聊聊關(guān)于倉租的計算應(yīng)該放在哪里，放在什么系統(tǒng)會更好？

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

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

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

這個問題會導(dǎo)致在計算庫齡的時候，并不是嚴(yán)格的先進(jìn)先出，只是做到了「庫位上的先進(jìn)先出」，于是當(dāng)客戶在查看庫齡的時候會發(fā)現(xiàn)，有一些更早的批次沒有出庫，反而更晚一些的批次已經(jīng)出庫了。

這個問題一般的解決方案是：優(yōu)化揀貨推薦的策略，對倉庫揀貨實行「強(qiáng)推薦」，即強(qiáng)制客戶在推薦的庫位揀貨，確保一定可以先進(jìn)先出。

但是在實際的倉庫管理中，要做到嚴(yán)謹(jǐn)?shù)南冗M(jìn)先出其實很難，付出的成本也會很高，而且對于海外倉來說，本來管理倉庫就已經(jīng)是一件難事了，還要加上一些精細(xì)化的管理（嚴(yán)格先進(jìn)先出），那無異于難上加難，幾乎不太能實現(xiàn)。

即使是解決了上述問題之后，還會遇到另外一個問題，那就是跨境電商海外倉系統(tǒng)隨著業(yè)務(wù)發(fā)展，很容易出現(xiàn)「第三方海外倉」或者「代理海外倉」的概念。

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

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

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

綜合上述背景，我個人建議在哪里統(tǒng)計庫齡和倉租，要結(jié)合自身的業(yè)務(wù)來考量，方案都會有利弊：

1. 如果揀貨沒有做到「強(qiáng)推薦」，那么建議在OMS端；
2. 如果有「第三方海外倉」，那么建議在OMS端；
3. 如果揀貨可以「強(qiáng)推薦」，也沒有「第三方海外倉」，則在WMS和OMS端都可以；

OMS端統(tǒng)計庫齡可以采用自己計算或者讓W(xué)MS推送數(shù)據(jù)的方式。

如果是讓W(xué)MS推送數(shù)據(jù)，那么OMS端只是展示一個結(jié)果，數(shù)據(jù)應(yīng)該是會和WMS端保持一致的。那么就要重點考慮WMS的一些出庫策略是否會對庫齡的計算有所影響，按理說庫齡的統(tǒng)計應(yīng)該是先進(jìn)先出的，這樣可以確保用戶花費(fèi)的錢最少。

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

四、總結(jié)

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

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

后來看到了別人很復(fù)雜的批次屬性，我又發(fā)現(xiàn)自己好像對批次的理解不太到位，不太確定方案是否有坑。導(dǎo)致對做出來的功能總是不太滿意，隱約覺得會出問題。

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

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

看完我的分享，希望屏幕前的你，也可以做到！

#專欄作家#

我叫維他命（Vitamin），微信公眾號：PM維他命。前PHPer，做過在線教育類產(chǎn)品，也做過4年多的跨境倉儲物流方向的產(chǎn)品，目前是一位外貿(mào)SaaS領(lǐng)域的供應(yīng)鏈產(chǎn)品經(jīng)理。主要專注于WMS/OMS/TMS/BMS/ERP等領(lǐng)域，分享供應(yīng)鏈相關(guān)的產(chǎn)品知識。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議