1.业务背景：
- 生鲜加工环节,需要领取原料才能进行原料加工,现在加工仓缺少领料,退料等功能,导致原料加工环节无法继续向下进行.现急需开发领料,退料功能,来保证原料加工环节的正常工作.
- 1.1:领料业务流程
-
1.2:退料业务流程
2.业务目标：
- 快速开发实现领料,退料功能,同时保证系统功能的拓展性,能满足后续新增的业务发展需求,比如后续要实现的退料差异场景.
3.需求分析:
-
3.1:产品设计的方案,流程如下
-
- 1.产品的方案简单来说,就是1个叫料需求,对应1个领料需求单, 用需求单去承载整个领料,交料流程。
- 2.如果按照上面产品同学的方案,那开发同学设计时,设计1张领料需求单表和1张领料需求单明细表
- 3.领料需求单表主要记录了领料的需求信息,而明细表则是对这些需求的详细补充,比如:领取数量这些.
-
3.2.方案2-作业任务化
-
- 1.该方案在操作"叫料"按钮时,除了生成"领料需求单"及明细表外，还会生成"领料任务"表.
- 2.后续仓库作业人员都是只对接"领料任务",对领料任务做操作,和领料需求单没有关系.
-
方案对比
-
产品出的方案1
-
优势
- 简洁性：只建立了领料需求单及明细表，结构简单，易于理解和维护
- 快速实现：开发周期短，可以快速上线满足基本需求
-
劣势
- 扩展性受限：如果未来需要添加更多功能或处理更复杂的业务逻辑，领料需求表设计可能会成为瓶颈
- 责任不明确：领料需求和领料处理都放到领料需求表处理,数据耦合太重
-
方案2
-
优势
- 责任明确：加工人员的操作和作业流转人员操作独立开,责任清晰明确.
- 扩展性强：如果未来需要添加新的功能或修改现有功能,可以在现有的表结构基础上进行扩展,而无需对整个系统进行大规模的修改,如添加领料审批,那我只需要在领料任务表上做修改,原来的领料需求功能不用动.
-
劣势
-
- 开发成本：新增了领料任务,开发周期较方案1更长一点.
最终方案
-
综合后续拓展性及可维护性来说,最终选择方案2,并且方案2的开发周期并不会比方案1开发周期多很多.
4.详细设计
-
4.1.场景说明：
- 领料和退料的业务场景相似,可以把对应的领料任务和退料任务抽象成1个任务模块.统一管理和分配领料与退料任务，提高操作效率和准确性.现阶段可以把任务相关代码统一放到1个包下面,然后统一对外提供api接口.
- 暂时不做成任务中心服务:
- 成本考虑:比如:服务器资源,是需要费用开销的
- 业务规模:现有的任务场景不是特别多,而且业务规模还在发展阶段,等业务规模越来越大, 任务场景使用越来越多时,再考虑服务独立,也来的及.
-
4.2.流程说明
- 领料任务：加工台工作人员点击“叫料”按钮后，系统自动生成领料需求单和任务。仓库作业人员通过任务中心领取任务，根据任务详情领取原料并送到加工台.
- 退料任务：加工台工作人员点击“退料”按钮后，系统自动生成退料需求单和任务。仓库作业人员通过任务中心领取任务，根据任务详情将多余原料退回.
-
4.3.任务模型-实体生命周期
- 如上图的流程中,领料任务或者退料任务,其实就是对应着上图中的“任务头”,"基础任务明细","扩展业务明细","任务作业结果"表.
- 任务头:保存是任务单号及该任务所属上层的内容,比如：这个任务归属于哪个加工任务id,哪个产线id，哪个加工仓id等信息.
- 基础任务明细:这个任务的公共部分,比如:供应商id,商品id这些，退料任务和领料任务中都会包含供应商和商品.还有任务类型,比如是退料任务还是领料任务.
- 扩展任务明细：每个任务不同的部分，可以拓展的部分,后续要有新的需求变更,要新增字段,就在扩展任务明细中加.
- 任务作业结果表:顾名思义,就是保存这个任务作业的结果的.
-
4.4.数据库设计
