故事是这样开始的。在从0-1的开发过程中,经历了几次产品迭代,这期按单拣货的模块我主动承担了起来,(之前交由另一个同事,由于他忙不过来,我主动帮着做了。)
一、需求
这期很简单,需求很明确,按单拣货增加以下小有需求:
1、确认拣货后,商品从库位移动到过渡库位。
过渡库位可以是:容器、拣货车等。
2、当拣货单取消拣货后,需要将库存从过渡库位移回到之前的库位上。
3、只有PC端操作的确认拣货,才能取消拣货。即手持端拣货,不能逆向操作。
二、填坑
坑一:库存表之前设计的只是针对库位,没有容器。容器和库位在数据库是两个表,两个独立的功能模块,没有任何关联关系。
库存转移到容器中,必定要更改库存。于是乎,修改容器模块。为了不影响前端调用,接口请求方法不做修改,只是修改接口内部逻辑:之前容器维护在容器表,现在改到库位表。库位表字段type:【0-地堆1-货架 2-周转箱 3-笼车 4-拣货车】,type【0-地堆1-货架】代表库位;type【2-周转箱 3-笼车 4-拣货车】代表容器。
坑二、按单拣货占用库存时,会生成库存分配明细。
库存分配明细表,记录该订单,每个订单明细,在哪个库位上,占用了多少商品。
当发货订单拣货完成后,开始发货交接,会修改该订单对应的库存分配明细 改为已发货,同时根据该表修改库存表(warehouse_inventory):假设发了10个,此时总库存减少10个,占用库存减少10个,可用库存和冻结库存不变。
商品SKU001 从库位 KW001转移到容器RQ001,移动数量是10。
步骤:
1、库存表warehouse_inventory,库位KW001,总库存减少10,占用库存减少10.
2. 库存表warehouse_inventory增加一个记录,容器RQ001(拷贝了一份库位KW001),总库存10,占用库存10.
3. 库存分配明细表,增加一条记录,warehouse_inventory_id指向 2新增的记录。
4.发货交接时,就会根据3 增加的这条库存分配明细记录扣减库存(从容器里扣减库存)。
坑三、释放占用库存
之前的库存占用逻辑,都是正品发货,占用可用库存。
这期占用库存,可以发次品,占用冻结库存。
所以释放库存时,不能将释放数量都加到可用库存上,而是要根据库存分配明细表的品质类型转移商品数量。
坑四、部分发货
同一个发货订单,先部分占用,生成拣货单1,部分发货。
继续完全占用库存,生成拣货单2,完全拣货。
此时界面上,这两个单据没有区别,SO状态完全拣货,拣货状态已完成。但实际上下面的单据已发货了,不能再取消拣货了。
三、建议优化
针对按单拣货功能模块(上个页面),为了增强用户使用的体验,建议做以下优化。
1.发货订单,新增一个字段,是否发货:【0-未发货,1-已发货】。
当发货交接后,修改发货订单 是否发货状态:【1-已发货】。
2. 前端按钮的控制。
占用库存:发货订单状态(非订单创建和部分发货状态),参数为:订单id。
释放占用库存:拣货单状态(0-待处理,1-已领用),参数改为:拣货单id。
分配拣货任务:按钮没有限制。(后台只会分配0-待处理)
确认拣货:拣货单状态【0-待处理,1-已领用】,参数:拣货单id
取消拣货:拣货单状态【4-已完成】,参数:拣货单id
四、因为要做这期的小需求,我把按单拣货整个模块都走了一下流程。由于这期又增了波次拣货、占用策略等需求,
所以按单拣货每个点基本上都做了改动。。。
之前有些改动是预想到了,还有一些没有考虑到,走到测试环境才发现的问题。需求迭代由产品主导,项目经理、开发人员、测试人员积极参与。但是经过了一系列需求评审、开发设计评审、测试用例评审,到最后还是出现了各种预测不到的问题。如何能把需求层层剥离出来?如何做到需求迭代时不牵一发而动全身呢?