项目业务与应用场景
窜货上报需要结合人员区域、商品码、定位和灵活表单，同时处理重复扫码、暂存、合并拆分和驳回后的重新流转。
13REGIONAL TRACEABILITY
五粮液窜货管理小程序
大区负责人和助理扫描箱码或瓶码后，系统判断商品是否属于当前销售区域，并完成异常登记、上报与处理。
Spring BootMySQLMyBatis-PlusRedisJWTMinIO小程序
扫码确定商品区域归属
大区负责人和助理扫描箱码或瓶码，结合人员区域与定位判断商品是否属于当前销售区域。
异常登记支持现场暂存
未提交记录可以保存，表单支持合并与拆分，适应现场连续扫码和后续统一上报。
驳回后按明细继续处理
问题商品可以拆出修改与重新上报，人员、岗位、区域和灵活表单共同约束处理流程。
BUSINESS FLOW
核心业务链路
从用户进入系统开始，查看业务数据如何经过各环节并形成最终结果。
SYSTEM NODE 01
人员与区域
岗位、大区、区域和管理员关系共同形成数据权限。
ENGINEERING DECISIONS
难题如何变成系统能力
从业务约束出发，说明机制为什么成立、边界在哪里。
人员与区域共同形成权限
- 难题
- 同一岗位在不同销售区域拥有不同的数据范围。
- 机制
- 人员、岗位、大区与区域关系共同判定访问；一个大区包含多个区域并只设置一个管理员。
- 结果
- 扫码、查看与处理遵守同一组织权限边界。
暂存、去重与提交分开
- 难题
- 现场重复扫码、重复点击提交和暂存操作容易产生重复记录。
- 机制
- 扫码先进入暂存模型，提交时执行重复校验与合并规则。
- 结果
- 重复扫码与重复提交都受到控制，同时保留现场暂存能力。
可拆分的表单流转
- 难题
- 一个表单中部分商品被驳回时，不应要求全部重新上报。
- 机制
- 灵活字段配置与明细模型支持合并、拆分和驳回重组，并与第三方系统关联。
- 结果
- 问题明细可以独立修改和重新进入异常处理链。
展开补充设计与约束
- 一个大区可包含多个区域，但只配置一个管理员，权限随人员和区域共同判断。
- 扫码记录先进入暂存模型，提交时执行重复校验和合并规则。
- 驳回后按明细拆分表单，使问题商品能够单独修改和再次上报。
PROJECT RECORD
原项目记录与量化结果
以下为原简历中已确认的项目指标；与本站演示样例数据分别展示。
01箱码 / 瓶码双类型扫码
02重复扫码与重复提交双重控制
03支持表单合并、拆分与驳回重组