面对无处不在的戴森专利，你自查了吗？GBC律所代理Dyson戴森发案（案件号：21-cv-6567），TRO已生效
这一篇文章和之前写的《跨境电商海外仓：WMS的库龄与仓租功能设计》是姊妹篇，两篇内容侧重点不一样，但是说的都是一个事情。而且近期我在调研国内一些知名的WMS系统的过程中发现，有一些观点我可能需要调整一下，所以我决定再写一篇关于批次，库龄和仓租这一块的内容。 一方面是对之前文章的补充和说明，另一方面也是一个记录一下自己固有知识的更新和升级。 库龄是指仓库中的货物在仓库中存放的时间，一般是用天来统计。 之前我一直认为库龄和批次号是必然的关系，如果要统计库龄那么就一定要先生成批次号。例如在入库上架的时候，根据上架日期生成批次号，然后和仓位关联，批次库存就会增加；在出库的时候，再根据库位的信息带出批次号，然后扣减对应的批次库存。这样一增一减之后，批次会动态的变化，然后每日固定一个时间点去统计当前的批次库存，最后就可以算不同的批次的库龄是多少了。 这个方案是对的，可行的。但是我的理解太狭隘了，为了实现不同时期入库上架的商品有不同的库龄，不一定非要引入批次号，只需要记录入库/上架日期即可。 将上架日期看做是一个和批次号同级别的字段，每次上架和下架的时候都对应的增加或扣减，也能达到计算库龄目的。 也就是说：上架日期不等同于批次号。 而之所以我说之前的方案是对的，是因为在WMS的 那么，什么又是 关于批次属性，初次我看到是在富勒的WMS操作手册中，一开始我也没看懂，直到最近我在钻研批次和库龄的事情，我才有了一个更加深刻的理解。 简单理解就是同一批入库的同一款产品，虽然长得都一样，但是可能会生产日期不同，生产批次不同，颜色不同，或者来自不同的供应商等，在方便仓库管理的前提下，又要做一些精细化的区分，于是将这些「能区分相同商品的不同_的属性」都定义为 举个栗子，一个入库单预报了300件优衣库的衬衫，实际收货了300件，如果不引入批次属性的话，那么就直接将这300件上架即可，对应的可用库存也是300。但是如果引入了批次属性的话，可以将 在富勒WMS系统中，定义了12个批次属性，其他WMS也纷纷借鉴了这一种定义的方式。具体到底最开始这样定义的是哪个，我就不知道了。 WMS的批次属性可以做到很灵活，在后续的分波和拣货策略中，批次属性会很大程度的影响作业的策略。而批次属性越多，也就会越精细，带来的后果就是开发难度很大，维护成本很高，管理成本也很高。 所以一般的仓库比较常用的就是入库日期，批次号，生产日期和失效日期这几个，而最最最常见的就是按入库日期或者上架日期来生成批次号了，但这并不意味着算库龄一定需要批次号。 前面解释了批次号和库龄并无「直接关系」，只不过是刚好很多WMS的批次号生成规则就是用入库/上架日期来生成的而已。 那么库龄和仓租是否有直接关系呢？ 答案是：有直接关系，而且是必然的直接关系。 因为仓租其实就是 关于库龄如何计算，我之前写的文章《跨境电商海外仓：WMS的库龄与仓租功能设计》已经有很详细的介绍了，大家在看的时候注意理解我文中所说的「批次号」即可。那篇文章中的批次号一般是指入库/上架日期，但是如果你的批次号是通过其他方式生成的，有其他用处，那么就需要单独用一个 在这里我重点想聊聊关于仓租的计算应该放在哪里，放在什么系统会更好？ 库龄数据来自于WMS，按理说放在WMS上去算肯定是最好的，或者说由WMS去提供数据，然后再BMS中计算。 但是按照我之前的设计方案我发现了这样做会有一个弊端，理解起来可能会有点绕，大家可以仔细阅读，揣摩一下。 当WMS根据上架日期来生成批次号之后，在拣货的时候，由于系统会根据先进先出的规则进行库位的推荐，但是由于没有做「强推荐」，仓库还是可以根据自己的实际经验去拣货，也就是不按推荐的库位来拣货，所以此刻在扣减库存的时候并没有做到完全的先进先出。 这个问题会导致在计算库龄的时候，并不是严格的先进先出，只是做到了「库位上的先进先出」，于是当客户在查看库龄的时候会发现，有一些更早的批次没有出库，反而更晚一些的批次已经出库了。 这个问题的解决方案是：优化拣货推荐的策略，对仓库拣货实行「强推荐」，即强制客户在推荐的库位拣货，确保一定可以先进先出。 在解决了上述问题之后，还会遇到另外一个问题，那就是跨境电商海外仓系统随着业务发展，很容易出现「第三方海外仓」或者「代理海外仓」的概念。 客户使用了我的美国仓，但是他还需要使用英国仓，但是我没有办法提供英国仓。要么他继续去找另外的海外仓，然后分别使用两套系统操作，这样会很麻烦；要么我去对接其他家的海外仓，然后把自己当做一个「代理仓」的角色，客户可以从我这里推送订单到其他仓库，实现一套系统接入多个仓库。 当有了上述的业务之后，如果客户要使用我的OMS向其他海外仓推送数据，那么他大概率是不会用第三方海外仓的OMS，也就是我需要承担部分第三方海外仓的功能。 其中库龄和仓租的计算需求也就开始有了差异化的解决方案了。 综合上述背景，我个人建议在哪里统计库龄和仓租，要结合自身的业务来考量，都有利弊： OMS端统计库龄可以采用自己计算或者让WMS推送数据的方式。 如果是让WMS推送数据，那么OMS端只是展示一个结果，数据应该是会和WMS端保持一致的。那么就要重点考虑WMS的一些出库策略是否会对库龄的计算有所影响，按理说库龄的统计应该是先进先出的，这样可以确保用户花费的钱最少。 如果是让OMS端自己计算库龄并存储，那么OMS就需要根据入库/上架，出库完成的时间节点分别去计算不同批次的库存的变化。这样可能会出现OMS计算的库龄和WMS端计算的库龄不一样的情况，因为扣减批次库存的逻辑可能会不一样，最后导致受影响的库存批次会不太一样。 对于批次，库龄和仓租，之前我一直感觉不太踏实，总感觉自己有一些东西没想透彻，没理解到位。经过这几天查阅资料，再加上整理成文的过程，我发现我对这个东西不踏实感已经逐渐地消失了。 最早的时候，我以为批次很简单，无非就是按日期记录然后保证全流程都考虑到它的变化就好了。 后来看到了别人很复杂的 到了现在，当我写完了好几篇关于这个东西的文章之后，我发现我基本上理解了这些东西，不再模糊，也不再恐惧，反而觉得好像也不是很难。 这个心路历程刚好对应了：「看山是山，看山不是山，看山还是山」 的故事。WMS的批次号和库龄无「直接关系」
批次属性中，经常会把入库日期或者上架日期当作一个系统预设的批次属性。所以在误打误撞之间，按上架日期来生成批次号，也实现了计算库龄的作用。WMS的批次属性才更加重要
批次属性呢？
批次属性。产地作为批次属性，也可以将生产日期或者批号作为批次属性，这样实际增加库存的时候，总的可用库存还是300，但是不同的批次下的可用库存是不一样的。
库龄和仓租在哪里算？
库龄*单价算出来的，知道了库龄，那么结合单价就一定可以算出仓租来。入库/上架日期来记录库龄。如果没有其他用处，那么就用批次号来计算库龄也是可以的。总结
批次属性，我又发现自己好像对批次的理解不太到位，总是不太踏实。导致对做出来的功能总是不太满意，隐约觉得会出问题。
希望，你也可以做到！
我们建了一个亚马逊卖家交流群，里面不乏很多大卖家。
现在扫码回复“ 加群 ”，拉你进群。
热门文章
*30分钟更新一次
