在接下来的三篇文章中，我们分别提到了海外仓WMS的入库、入库、库存功能的产品设计。 其中，仓储和拣货是WMS的核心功能，而库存管理是WMS的基石，因此库存功能堪称WMS的“无忧杂货店”。

海外仓WMS基本上每晚都有频繁的订单进出仓。 再加上海外本地化管理的问题，很多仓库的运营不规范，导致“人肉运维”事件时有发生。 之前我曾联系过一位客户，提出了一个看似简单却心酸的要求：“我希望找到海外仓合作伙伴跨境电商进口流程图，只要他们能完成每天的订单进出仓，并且能给我反馈准确的库存情况。”

这个要求乍一看很奇怪，这么简单的要求怎么需要指出。 而在仔细询问了顾客一些细节后，他发现自己也有难以言喻的痛苦。 因为他之前接触过的很多海外仓或者订单管理系统在库存方面都没有做好，要么库存不准确，要么反馈不实时，要么没有系统接口可以查（这个应该是指一些海外ERP或者小平台等）。

其实里面的例子并没有足够的说服力，或者说只能代表一个很不受欢迎的群体。 但总的来说，从我接触过的业务来看，很多海外仓系统对于库存的准确性做得不够好，或者你没有在这里投入太多的精力和资源，所以里面的故事就会发生。

库存的准确性是指实物与账面数据的准确性，即“现实”与“理想”的差异。 当库存不准确，客户对自己的实际库存不稳定时，就会担心超买或买少，从而形成忧心忡忡的感觉。 WMS的库存功能对于此类客户来说就像一个“省心杂货店”。 即使对库存有疑虑，我们还是盘点一下吧。

1、库存

以下内容摘自网络，只要搜索“库存”或“仓库库存”，基本上都能找到类似的说明和介绍。

仓库盘点是一项技术活，并不像想象的那么简单。 例如跨境电商进口流程图，仓库库存有三种分类方法。 1、按照库存时间跨度分为定期库存和不定期库存； 2、按照库存内容分为综合库存和重点库存； 3、按库存功能分为循环库存、连续库存（动态库存）和高级库存。

刚开始接触盘点或者想做盘点的时候，我找了很多资料和资料，但我发现越看越迷茫，越看越心疼。 功能这么多，我该如何设计产品功能呢？ 直到最近，我回顾了一下自己当时的设计和库存流程，然后得出了一个结论：

库存的本质是：

对实物进行清点，然后与书本数据进行比对； 根据实物盘点结果，对账面数据进行调整，以符合实际账务情况。

所以，菜鸟想要设计这个产品功能，一定要记得抓住本质来设计，否则很容易误入歧途，进而陷入无休无止的修复之中。

核心点是能够吃饱，提供能量。 至于选择哪种方式，取决于各种激励措施，所以只要能满足当前的业务，就不必太郁闷。

比如看竞品的时候，别人有公开市场，也有暗市，我也应该这样做吗？ 别人有永续盘点和静态盘点，我也要效仿吗？ 别人盘点的时候可以导出到Excel，我也应该这样做吗...

这是我当时踩到的最大的坑，我还是想让库存功能完整健全。 原来，很多功能设计完成后，根本无法通过审核。 或者在做用户demo体验的时候，仓库根本不认识那么多复杂的操作方法，只能回调重新思考业务需求是什么，海外仓的特点是什么，库存功能的边界如何界定。

2、库存流程

库存流程图

库存流程的主线基本都是邯郸，因为本质就是清点实物，然后调整系统账面数据。 因此，困难通常在于一些小细节和业务判断，以及海外仓的操作系统和管理方法。

1. 创建库存清单

在创建库存清单时，我简化了库存方法，最终保留了两种形式：

根据SKU+仓储库存，系统标记该仓储位点需要盘点的SKU数量； 按仓库库存，系统标记需要盘点的SKU数量，以及各自的编号；

都是开盘，不考虑黑盘的方式（可以根据具体业务而定），这两种方式是最常见的仓库库存，可以满足大部分的库存需求。

给仓库更多的选择。 如果您想要盘点客户的库存，您可以盘点该 SKU，并且可以盘点您想要盘点的仓库地点。 一切都是由仓库自己决定的。 系统要做的就是准确地记下位置和信息，然后提供给仓库盘点人员。

2. 主队

前面提到，盘点的本质就是将实物数据与系统的账面数据进行比较，然后调整系统的账面数据，实现账面的一致性。

如果实物比账本数据多，这就是“超额”，这意味着库存调整订单需要减少库存，类似于系统无缘无故地多“赚”一些钱。

如果实物少于账面数据，这就是“库存损失”，这意味着库存调整订单需要扣除库存，这类似于系统中无缘无故的“损失”金额。

而主队就意味着第一盘，第一盘。 主队以后还会有重赛，有的仓甚至会三盘，就是重赛后盘点。

未来主队之所以恢复比赛，是考虑到人工计分可能出现误算的情况。 如果在一次计数后进行调整，人为错误可能会成为太大的诱因。 因此，我会考虑主队，再进行一次审查，以减少一次因主队而造成的偏差率。

3. 回顾

再次盘点主队的成绩称为复盘，也可称为二次盘点或第二盘。 关于审核有一个逻辑需要高度重视：那就是审核，引擎呢？

如果我们不去想太多，这样的审核肯定是主队的重复动作，也就是说主队有10个SKU和20个位置，这样的审核也需要统计10个SKU和20个位置。

而且从实际的监管和仓库反馈来看，有时候仓库并不想对已经确认数据的内容进行重复盘点，这样会浪费自己的时间，感觉自己做了很多无用的工作。 但如果只审核有差异的内容，会发现如果仓库要重新盘点一些不确定的SKU，系统无法支持审核数据的输入，会比较吐。

因此，推荐的解决方案是：可以在审核时对所有数据进行操作，减少一个额外的筛选按钮，即“只显示有差异的内容”。 这样就只能统计不同的内容，对于不区分的内容计数数据，手动使用主队的数据； 如果要统计所有的内容，系统也留了一个洞，让仓库没有录入数据的入口。

4. 确认盘点结果

经过复核后，大多数情况下可以保证实际统计的数量应该是准确的，从而可以确认复核的结果。 确认后，可以进行库存差异处理，从而可以进行库存调整，减少过剩或赤字流量。

为了确认盘点结果，可以考虑实现授权功能或初步审核功能。 尽量保证这个动作的完成有一定的阈值。 虽然系统账本数据有所调整，但还是需要操作者有一定的敬畏心和谨慎意识。 其实如果能用管理的方法来避免这些错误检查那就最好了，因为系统毕竟只是一个工具。 虽然一味地用工具来限制人并不可取，但是这样很容易降低成本，增加系统的复杂度。

5、盘点详细流程

最后，我在这里放一张详细版本的库存流程图。 虽然最初的版本应该有更多的功能，但随着业务的控制变得更加清晰，删除了很多内容。

库存详细流程图

3. 困难与陷阱

盘点的难点和陷阱

难点一：分类及业务分支复杂

正如后面提到的，库存有多种类型和形式。 如果一味的想要完整，满足所有的功能，这样会让支线变得更加复杂。

比如我目前只使用两种盘点，涉及到主队，审核并决定是否执行，最后兼容不同的盘点设备。 虽然这套出来了，但是工作量还是蛮大的。

不过，虽然库存功能只是WMS库存模块的一个小功能，但如果一开始就使用太多类型的库存表单，最终可能会演变成一个更复杂的分支。 开发成本高，仓库使用的学习成本也高。

难点二：库存锁定库存与实际库存

仓库盘点的时候，应该在上班吗？ 对于这个问题，不同的人有不同的答案，结果肯定是：不工作的时候做盘点会减少产品设计的需要。

在仓库做盘点工作时，创建盘点清单获取实时数据时，它是一个值，而实际取盘点时可能会变成另一个值。 为了防止这些数据的动态增减，我们可以考虑冻结运行中的SKU或者仓位，不允许这条库存中的数据。 那么什么时候发布数据又是一个问题，是下架后发布还是取料后发布。 如果下架了就会放行，那么如果有订单被拦截取消然后退回仓库怎么办？ 如果拣货了，就会放行，所以订单暂时不会拣货，仍然会放在等候区不拣货，所以短时间内无法盘点个别SKU。

因此，如何处理锁定库存也是库存的一个难点。 我们要考虑清楚系统锁定和释放库存的时机，然后结合业务进行设计。

我自己的经验是，盘点的时候倾向于让仓库不工作，这样的数据是最准确的。 我只统计存储地点的库存，不管是锁定的还是冻结的，只要不在存储地点的，我就不统计。 最好的前提是：仓库已经完成正常作业，并且没有入库和拣货的操作。

踩坑点一：产品边界问题

据说盘点的形式和种类很多，今后统计库存统计的方式也有很多种。 盘点结果需要多次确认。 盘点时，使用 PDA 或纸质表格或 Excel。 盘点可以支持多人同时工作，多设备一起提交……这些都是产品边界的问题。

产品边界问题不仅在库存中遇到，在其他产品功能的设计中也会遇到。 而我自己在盘点的时候也踩过这个坑，所以记忆比较深刻。 从设计到开发再到最终上线库存功能，比我预计的整整晚了两个迭代。 造成这种情况的最大原因是我对产品边界缺乏控制。

有些功能只做了一半，看起来好处并不算太大，考虑的因素太多； 还有一些功能没有考虑好，比如货物材质面积的问题，所以需要紧急规划，弥补一些缺失的点。

产品边界的坑是我从库存功能中得到的最大的教训，也算是最大的收获。

总结

库存功能是WMS库存模块的辅助功能，协助仓库调整系统的账面库存，以满足实际账务的要求。 海外仓的库存和国外电商仓库的库存在太原应该是差不多的。 主要区别在于仓库管理与实际业务的区别。 系统虽然是给人使用的，但是用户不同，使用的方法自然也会不同。

关于海外仓WMS的库存功能设计，有这么多的经验和感受。 最近写了一系列WMS总结文章，有了一些新的体会。

你总说B端产品要更加关注业务，吃透业务，理清逻辑； 而C端产品需要更加注重新增留存、商业价值、用户体验和用户价值。 说的很多，听到的都是一样的，却是难得，被千分之一感动的更是难得。

当我回过头来反思自己的WMS产品设计时，发现自己对业务的理解还是很片面的，一直以为自己看到的才是最真实、最全面的。 但在幕后，冰山之下的人并没有挖掘太多，而是花费了更多的时间和精力去对比竞品、分析同行的设计初衷……

所以，哪怕是看似简单的8个字：吃透业务、理清逻辑。 其实要做起来需要花费大量的精力和时间，所以B端产品在业务上应该还是有优势和劣势的。 了解了业务，把业务看透了之后，我们离优秀的B端产品又近了一步。