更新时间：2026年10月09日

仓储入库页面先区分预计到货、实际收到、验收合格和已入库存，不能把“扫到了商品”直接等同于“库存增加”。让仓管员沿单据确认、逐项收货、异常处理、复核提交推进，随时看清数量差异。可在Pixso 中梳理入库界面与状态，先验证一笔完整收货，再扩展更多单据类型。

用一张到货单定清业务边界

本次设计练习为普通零件采购收货：单据 IB-1009 预计到货 40 件，现场收到 40 件，其中 37 件完好、3 件外观破损。案例约定破损品进入隔离区，不计入可用库存；合格品确认库位并提交后入库。医药、冷链、危化品等行业还会有额外合规流程，不在这份普通收货案例中假定通用。

页面应明确呈现：预计 40、实收 40、合格 37、异常 3、待处理 0。数量一致不代表全部验收通过；如果只显示“完成 40/40”，仓管员可能误以为全部可上架。

先同业务负责人确认系统在哪个动作记账：收货、质检通过还是上架完成。不同仓库流程可能不同，设计稿要对应已经确定的规则。这里采用“合格品完成库位确认并提交后入库”，不能一边叫待上架，一边又展示全部库存可用。

操作区跟着收货任务排列

页面顶部放单号、供应商、仓库、单据状态及关联采购单；中部用明细行承载商品、规格、预计数量、实收数量、验收结论和库位；底部保留异常汇总与提交操作。字段很多时，优先固定商品身份、数量差异和处理状态，不让仓管员横向滚动后忘记正在修改哪一行。

默认先展示待处理行，已经完成的行仍能找回。不要让自动排序在每次录入后立刻移动当前行，导致下一次扫码写进错误商品。完成一行后是否跳到下一行，应结合扫描枪、键盘和现场操作习惯验证。

订单详情的资料密度可以很高，但录入焦点必须单一。扫描输入框、当前商品和最近一条反馈靠近，避免仓管员视线在表格顶部、页脚与右侧提示之间来回移动。

识别条码后先明确它匹配了哪个商品与包装单位。若一个条码表示整箱，而数量字段按件计量，必须展示换算关系；不能默认所有条码一次加 1 件。本例按单件条码录入，每次有效扫码增加当前实收数量。

重复扫描未必是错误：同一商品连续扫码可能意味着收到了多件。需要结合商品是否有唯一序列号、包装单位与当前模式来判断。UI 不能只按“条码字符串重复”拦截所有后续扫码，也不能在唯一序列号场景里无限累加。

对 IB-1009，仓管员录入实收 40 后，分配 37 件为合格、3 件为破损隔离。页面保持“合格 + 异常 + 待处理 = 实收”的关系，避免同一件既进入可用库存又进入异常数量。

异常原因需要能支持下一步动作，例如破损、规格不符或缺件；不用一个泛化“其他”吞掉所有问题。需要照片或备注时，清楚说明缺少哪项资料；异常未解决不一定要阻断所有合格品，但是否允许拆单提交应由业务规则决定。

合格品选择正常库位，破损品选择隔离位置，并标出用途。不要仅在两个相似下拉框里分别选择 A-01 和 Q-01，却不说明其库存性质。库位被停用、容量不足或无权限时，保留当前行并给出具体原因，不跳回整张单据起点。

提交前摘要写清本次动作：“37 件合格品入库，3 件破损品转隔离处理。”若仅完成收货、尚未上架，应使用对应动作名称，不能为了按钮简短统一写“完成”。需要二次确认时，摘要比通用“确定提交吗”更有帮助。

提交过程中防止重复触发；请求结果未知时先回读单据状态和已入库数量，不能立即创建另一笔入库。业务层的幂等与库存校验由研发实现，设计稿要明确等待、成功、失败和结果待确认的表现。

未提交的录入应有明确保存状态、操作者和更新时间。若允许多人处理一张单据，还需说明某行被其他人改动后如何提示、重新读取或合并，不能让后保存的一份静默覆盖先前结果。

把“扫码累计—数量分配—库位确认—提交摘要—结果回读”放在同一份 Pixso 原型里，请现场使用者沿完整流程指出打断操作的地方。后台结构的通用方法可参考后台管理 UI 的业务任务与布局，但仓储页面最终仍要由单据、数量和异常去向来判断是否好用。