说说：WMS：盘点设计

编辑导语：仓库管理系统WMS是常见的B端产品，其中，盘点业务是WMS中常见的业务流程。盘点任务的创建，包含了盘点触发、盘点范围、盘点方式及盘点人员等方面。本篇文章里，作者对WMS的盘点设计做了总结分享，一起来看一下。

之前陆陆续续写过WMS出库、入库、库内管理的相关设计，并且也正对于出库拣货的功能做了较为详细的阐述，今天我想聊一聊盘点。

在行业中，我们常常会用盘点准确率作为权衡仓库管理水平的核心指标。仓库管什么，管的就是那票货和操作那票货的人。而盘点，用最白话的方式来讲就是，系统告诉我这个地方有多少这个货，那我去数数看是不是真的是这个数，如果是的话那就没毛病，不是的话，那咱得好好看看哪儿出问题了。

那么接下来我们就开始进入正题吧。

对于盘点这个业务流程来说，通常可以分成三大步骤：创建任务→执行任务→盘点生效。

本文也会从这三个环节展开对盘点进行一个完整的介绍。

创建一个完整的盘点任务的生成应该包含以下几个部分：

这里通常可以分为三大类的触发情况，包括：周期性盘点、指定条件触发盘点、用户自主盘点。

1）周期性盘点

顾名思义，周期性盘点是定义一个固定的周期，由系统间隔一定周期后，创建固定的盘点任务由仓库进行盘点执行。这个功能通常是结合盘点计划来实现的。这也是仓库管理中应用最多的一种方式，一般会设置月盘/双月盘/季盘等。定期确认仓库库存的准确性，及时纠错。

2）指定条件触发盘点

这种触发方式相对来说就比较个性化了，需要结合实际的业务诉求进行设计。

比如为了保障在频繁操作中库存的准确性，当某仓位当日拣货频次达到一定量后自动触发盘点任务。要求在次日开始拣货前对此库位进行盘点。

或者为了避免商品丢失，对于一定时期没有流水的库位触发盘点任务由专人进行盘点，确保无资损等。

3）用户自主盘点

前两种都是由系统来触发的，而当用户实际操作过程中发现库存异常时，也应支持自主发起盘点任务。

如之前我们设计过在拣货过程中员工发现指定库位库存异常时，即刻触发盘点任务，由专人库管进行异常确认和相关盘点。

哪些仓库、哪些库位、哪些货品要盘点呢？

1）全盘

全盘很好理解，就是不管三七二十一，一股脑儿所有的可用仓库、所有货品都盘点一遍。虽然在库存准确性上有所保障，但是确实是“劳民伤财”了。因此通常只有在固定较长周期的盘点任务中才会用全盘的方式。

2）部分盘点

部分盘点可以是针对于部分库位、也可以是针对部分商品。或者对于3PL仓这种服务性质的仓库，也可以针对特定货主单独发起盘点。

当然还包括上文(指定条件触发盘点)中提到的按照指定条件触发盘点中一些特殊的维度。

如果是用户自主盘点的话，通常最细维度可以到针对仓库中某一库位的指定SKU。

以上都可以概括为部分盘点。

1）明盘VS暗盘

针对盘点过程中，用户的“知情权”不同，可以分为明盘和暗盘。

明盘是指用户在操作盘点时，允许用户知道当前库存，其目的是为了让用户知道在盘点过程中知道差异，并及时核实差异，确认差异原因报名抽奖，确保提交的结果是准确的。

暗盘则相反，用户盘点时，只知道当前盘点数量却无法查看到当前实际库存。只有最终提交结果生效后才可知道差异信息。通常这么做的目的是为了防止用户在盘点过程中作弊，为了应付考核而弄虚作假。

两种方式无谓对错，只是适用的大场景有所不同，大家可以思考下什么场景适合明盘，什么场景适合暗盘？

2）静盘VS动盘

静态盘点是指易企秀官网下载，在盘点过程中，全部作业停止，一直到盘点任务内所有物料盘点完成。在我刚毕业还在制造行业工作时，基本上每隔半年仓库就会大盘一次，产线会归还所有未用完的物料并停止作业，仓库此时禁止领还，等所有货物都盘点完毕并提交财务审核后，重新开始作业。在此期间，仓库内所有货物都是“静止”的。

动态盘点则是相对于静态盘点而言。在盘点过程中，仓库整体还是可以正常作业，针对于未盘点的区域进行“静止”处理，某区域一旦盘点完成，即可开始投入正常使用，不必等整个仓库盘点完毕。

盘点任务的执行可以实现为指定式、认领式。

1）指定式

系统按照用户设定的规则制定某个或某群用户。如特殊/贵重商品只能由部分权限用户才可进行盘点。通常需要用户在系统中预设指定规则。

2）认领式

则是指任务生成后盘点责任人为空，有相关仓库/区域权限的用户均可查看到此任务。用户按实际情况进行任务的认领。

此外，对于一个盘点任务来说，当盘点范围不同时，在人员的约束上也会有所不同。当把仓库/多货品作为一个盘点任务时，那么必然是要允许多人盘点的。但是对于针对库位库存异常生成的库位盘点任务，通常会限制一个用户认领后，其他用户是不允许再操作此盘点了。避免同时盘点同一库位造成的数据差异。

针对不同的场景，通常需要对这几个维度进行不同的组合，创建不同类型的盘点任务。大家可以自行思考下不同场景下对盘点任务的不同诉求。

盘点的实操部分反而是比较简单并且通用的部分了。

通常可以分为：领取任务（如果需要领取的话）、针对盘点任务中的明细开始盘点两个步骤。领取任务相对来说是个比较通用的功能，这边就不展开说了。

在盘点任务详情的呈现上面，可以分成两大类：按商品维度和按库位维度呈现。

以下图例仅为简例，只为说明概念，实际产品设计相对会更加复杂。

此外，在盘点实操过程中，为了确保用户确实是在指定库位盘点指定商品，在产品中需要增加库位、商品扫码逻辑。

盘点过程可以分为初盘和复盘，初盘即针对盘点对象的首次盘点，复盘通常是针对有初盘有差异的部分，要求用户重新核实盘点，增加盘点数据的准确性。

对于盘点有差异的部分，在提交时，要求用户录入可能造成差异的原因。

盘点完成后，用户对盘点结果进行提交，通常对于盘点结果是要求经过几轮业务包括财务的审核后，才可以生效的，毕竟直接影响的就是钱了。

并且增加审批流也可以对实操业务有一定警示作用，明白盘点的严肃性。

盘点结果审批通过后，则需要针对盘点结果对当前库存进行相应的调整。

库存调整可以分为覆盖调整（不推荐）和差异调整生效。

覆盖调整是指，原库存10，盘点后库存8，那么在盘点生效后直接将库存改为8。大家仔细想下这里是否会有问题？我在此处先不讲，等我讲完差异调整后，相信大家自己就明白了。

差异调整则是指，按照盘点结果中的库存差异对当前库存进行调整。按时按照上面的例子来说，盘点差异为-2，虽然盘点结束后库存是8，但是在提交审批后，审批过程中，仓库有出入库操作，实际审批通过时，库存为6。那么当按差异值-2调整后，库存应该为4。

回过头让我们再看下覆盖调整的问题，在上面的例子中，如果直接覆盖，则会将库存6直接更新为8，反而是盘盈了2，与实际盘点结果是不一致的。除非在审批通过之前，仓库库存仍然冻结并禁止操作，这显然对业务有较大影响，因此个人并不推荐这种做法。

在盘点的过程中还有很多细节的设计点，比如：

很多问题都需要结合实际的业务场景来设计，我这篇文章算是抛砖引玉了春分，大家有兴趣的话，可以一起聊一聊，你们的盘点是怎么做的呢？

麋鹿产品，麋鹿产品手册，专栏作家。专注供应链挖掘提升，热爱生活，热爱产品。

本文于。

题图来自Unsplash寒露，基于CCO协议。