仓储管理系统开发

项目背景

这是一套仓储管理系统，单个代码库，包含 414 个 Java 文件与 34 个 Vue 文件，另有 2 个测试文件和 3 篇项目文档。从代码规模看，这是一套完整实现的业务系统，覆盖入库、出库、库存盘点与库位管理等核心环节。

客户当时的状态

仓储管理的核心诉求只有一个词：账实相符。系统里显示的库存和货架上的实物对不上，后面所有的采购、发货、盘点都会跟着错。而库存对不上，几乎都出在单据上——入库单、出库单、调拨单各自流转，没有统一的状态口径，就会出现「货已经出库了，系统里还挂在库里」这种情况。另外仓库作业是分工的，收货、上架、拣货、复核由不同的人做，权限不分开，出了问题分不清责任。

我们的做法与取舍

第一个取舍是把单据做成库存变动的唯一来源。库存不靠人工改数字，只能由单据驱动。代价是操作步骤变多，收益是每一次库存变化都能追到源头。

第二个取舍是把库位管理做进主流程，而不是当成一个附加信息。库位不确定，拣货就得靠人找，账实相符也无从谈起。

第三个取舍是权限按作业环节拆开，而不是按部门粗放划分。收货、上架、盘点、复核各自有对应权限，谁做的操作系统里有记录。这部分在一套 414 个 Java 文件的工程里是贯穿式的改动，不是加个角色就能解决的。

系统怎么承载这条链路

后端承载物料、库位、库存与单据的核心逻辑，入库、出库、盘点、调拨都作为单据类型走同一套状态机；前端负责作业界面与查询；项目内留有 3 篇文档和 2 个测试文件，说明核心链路在交付时做过验证。库存数量由单据累计得出，不允许直接修改——这条约束贯穿整套系统，也是 414 个 Java 文件里改动最密集的部分。文档覆盖的是单据规则与操作方式，交接时不用再靠口头解释。

交付状态与边界

代码库最后一次提交在 2021 年 12 月，系统交付后没有再更新。边界说明：系统承载的是仓储作业流程与库存记录，不涉及自动化立库、AGV 等硬件设备的控制；条码与硬件采集设备的选型由使用方决定，系统提供的是数据接收与处理；盘点差异的最终认定与账务处理属于财务范畴，系统只记录盘点结果与差异明细，不替财务做结论。