9.9 KiB
采购入库 PDA 扫码页重构设计
背景
当前“扫码采购入库”页面更接近通用表单页，而非工厂仓库现场的扫码作业页。页面在未锁定采购单前就暴露了商品扫码、批次号、库位码、提交等动作，导致流程噪音大、操作节奏不稳定、误操作风险高。
本次重构面向工厂仓库出入库场景，明确主使用设备与操作方式：
- 90% 使用 PDA / 手持终端物理扫码枪
- 10% 使用手机摄像头扫码
- 商品扫码主路径为“一枪一件”，每次扫码自动累计
+1
因此页面设计必须优先服务高频、连续、站立式作业，而不是低频表单录入。
目标
重构采购入库扫码页，使其满足以下目标：
- 先锁采购单，再进入连续扫码作业
- 商品扫码成功时不打断操作节奏
- 异常时给出明确、可恢复的处理反馈
- 始终让操作员看到当前单据、当前仓库、扫码进度、异常数量
- 降低危险操作误触概率，避免“清空全部”成为高频可见动作
- 保持与现有 ERP 扫码页代码风格一致，优先复用现有扫描输入、明细列表、提交逻辑能力
非目标
本次设计不包含以下范围：
- 不重做采购入库后端接口协议
- 不新增复杂的离线同步机制
- 不引入多步骤向导页或跨页长流程
- 不为手机摄像头场景单独做一套交互，只保留备用入口
设计方向
页面采用“作业台式”方案。锁单是进入作业态的前置动作，作业态才是页面主体。
相比“单页折叠式”或“全表单式”，作业台式更适合 PDA 连续扫码场景，原因是：
- 核心视线始终集中在当前单据、扫码输入、最近结果
- 可以让商品扫码输入框常驻焦点，适应物理扫码枪回车行为
- 订单上下文与作业进度持续可见，减少扫错单、扫过量、扫混仓的风险
页面状态
页面只允许存在两个一等状态：锁单态 与 作业态。
锁单态
页面目标只有一件事：确定当前采购单。
展示内容：
- 页面标题：
扫码采购入库 - 主动作：
扫描采购订单号 - 次动作：
手动选单 - 可选辅助文案：说明供应商、仓库、结算账户将在锁单后自动带出
锁单态不展示以下内容：
- 商品扫码输入框
- 批次号输入框
- 库位码输入框
- 入库明细列表
- 提交采购入库按钮
设计理由：未锁单前，商品扫码与提交都不可执行。提前展示只会制造误导。
作业态
选定采购单后进入作业态，页面主体切换为扫码作业台。
展示内容：
- 顶部固定订单信息条
- 商品扫码输入区
- 批次号、库位码辅助区
- 最近扫描记录区
- 底部主提交区
作业态的默认焦点必须回到商品扫码输入框，以适应 PDA 连续扫码。
页面结构
1. 顶部固定订单信息条
用于持续回答两个问题：当前在扫哪张单，以及还差多少。
固定展示字段：
采购单号：最醒目的主字段，例如CG2025001供应商仓库进度：格式为已扫 X / Y异常数：格式为异常 N
规则：
- 当异常数大于 0 时，使用警示色强调
- 顶部信息条在明细滚动时仍保持可见
- 标题可显示为
采购入库 / CG2025001，帮助快速确认当前上下文
2. 商品扫码输入区
这是作业态的主操作区。
字段与控件：
- 商品条码输入框：主输入，常驻焦点
- 批次号输入框：可选
- 库位码输入框：可选
- 相机按钮：仅手机摄像头备用
规则：
- 商品扫码成功后自动累计
+1 - 默认不依赖手动点击“确认”按钮完成正常扫码
- 若保留“确认”能力，也仅作为手机手输备用，不应成为 PDA 主路径
- 商品扫码完成后，焦点自动回到商品条码输入框
3. 最近扫描记录区
该区域不是传统表单明细，而是作业回显区。
默认展示：
- 最近 5 条扫描记录
- 最新一条置顶
- 最新成功记录高亮约 2 秒
每条记录显示：
- 商品名称
- 商品条码
- 批次号
- 库位码
- 当前明细累计数量
- 当前订单该商品剩余可入库数量
合并规则：
- 同商品、同批次、同库位的重复扫码：合并到同一条明细并数量
+1 - 同商品但批次不同：分成新行
- 同商品但库位不同：分成新行
操作规则：
- 每条记录提供
撤销或删除本条能力 - 不提供高频可见的
清空全部
4. 底部主提交区
底部只保留一个强主动作：提交采购入库
规则：
- 仅当存在有效明细时可点击
- 点击后进入 loading，防止重复提交
- 不将
清空全部与提交并列摆放
扫码交互规则
正常路径
锁单后，PDA 连续扫码主路径如下：
- 扫描商品条码
- 系统匹配当前采购单中的订单行
- 若匹配成功，则新增或累计对应明细
- 数量自动
+1 - 顶部进度同步刷新
- 页面显示成功反馈，例如：
西兰花 +1，已扫 12 / 30 - 焦点返回商品扫码输入框，等待下一枪
正常路径要求：
- 不弹窗
- 不要求人工再次确认
- 不打断扫码节奏
PDA 行为适配
考虑物理扫码枪通常自带输入结束与回车行为，页面需满足：
- 商品条码输入框支持快速连续触发提交
- 回车后自动执行匹配与累计
- 成功后无需额外点击
- 扫码完成后尽快恢复待扫状态
手机摄像头备用路径
手机端仍保留相机按钮，但定位是备用入口：
- 适用于无 PDA 或临时补录
- 交互与 PDA 一致，扫码成功后同样走自动累计逻辑
- 不单独扩展额外的手机专属页面流程
异常处理
异常处理分为三类。
1. 不中断型反馈
适用于成功扫码。
表现：
- 使用绿色反馈条或高可见状态条
- 文案直接描述结果，例如：
西兰花 +1，已扫 12 / 30 - 持续约 0.8 到 1.2 秒后消失
- 焦点自动回到商品扫码输入框
2. 中断型异常
适用于以下场景：
- 商品不在当前采购单内
- 商品剩余可入库数量为 0
- 扫码后将超出剩余可入库数量
- 条码命中多个待入库订单行
- 当前采购单未锁定
表现：
- 使用红色错误条或常驻错误提示
- 错误文案必须明确原因，不能只写“操作失败”
- 焦点不应伪装成成功回跳
- 必要时进入人工处理分支
推荐错误文案：
商品不在当前采购单内该商品剩余可入库 0 件该商品本次扫码后将超出剩余数量条码命中多个订单行，请人工选择请先扫描采购订单号
3. 可恢复型提示
适用于非强拦截场景，例如：
- 批次号为空
- 库位码为空
处理原则：
- 若业务允许为空，则不拦截扫码
- 可在记录中标记为空，或在提交前统一提醒
- 不应影响正常扫码节奏
危险操作策略
仓库扫码场景下，危险操作必须降级。
优先提供：
撤销上一笔删除单条
降级隐藏：
清空全部
规则：
清空全部放入右上角更多菜单或二级操作区- 执行前必须二次确认
- 不能与
提交采购入库同层并列
原因：现场最常见修正动作是撤销刚才那一枪，而不是整单清空。
提交流程
提交前条件
提交采购入库 按钮仅在满足以下条件时启用：
- 已锁定采购单
- 至少存在 1 条有效明细
提交前校验
提交前统一执行轻校验，检查：
- 是否已锁单
- 是否存在有效明细
- 是否存在未处理异常
- 是否存在超量或冲突记录
- 若业务要求，可额外检查是否存在空库位记录
提交中行为
- 提交按钮进入 loading
- 页面避免重复触发提交
- 不清空当前上下文，直到接口明确成功
提交成功后
成功反馈不能只有“成功”提示，而应给用户明确后续动作：
继续当前单据扫码返回列表
若业务允许同一采购单分批入库，则继续当前单据是高价值动作。
提交失败后
提交失败时必须保留现场：
- 当前采购单
- 已扫明细
- 当前批次号 / 库位码上下文
- 当前异常状态
不能因为接口失败而丢失现场数据，否则会造成重复作业和人工补录。
数据与组件边界
建议将页面逻辑拆分为以下职责单元：
锁单上下文：负责采购单选择、锁定、切换、上下文字段映射扫码作业上下文：负责商品扫码、累计、异常判断、反馈文案最近扫描记录列表：负责最近记录展示、合并、撤销提交控制器：负责校验、提交、成功/失败收尾
实现时应优先复用现有能力：
- 扫码输入组件
- ERP 明细展示组件
- 采购入库现有数据结构与接口
避免将全部状态与条件判断继续堆在单个页面文件中。
错误处理与恢复策略
- 切换采购单前，如已有明细，需明确提示并确认
- 删除或撤销明细后，顶部进度立即回算
- 发生条码歧义时，进入人工选择而不是静默失败
- 明细为空时不得允许提交
- 页面刷新或重新进入时，若未设计暂存机制，则明确回到锁单态
测试关注点
测试应覆盖以下高风险路径：
- 未锁单时误扫商品
- 连续多枪同商品累计
- 同商品不同批次 / 库位分行
- 超量扫码拦截
- 条码命中多个订单行
- 撤销上一笔后进度与剩余数量回算
- 提交失败后现场状态保留
- PDA 回车触发下焦点能持续回到主扫码框
设计结论
采购入库扫码页应从“表单页”重构为“PDA 作业台页”：
- 先锁单，再作业
- 一枪一件，自动累计
- 正常路径绝不打断
- 异常路径明确、可恢复
- 明细区服务作业反馈，不服务传统录单表单
- 危险操作降级，提交操作集中
该方案优先满足工厂仓库高频扫码场景，同时保留手机摄像头作为备用输入方式。