KCGL/app at 58fa42bff3d8f3c66cccace90466bdb98484771d - KCGL

Files

yueli 58fa42bff3 feat(scrap): 报废全链路收口到审批流

系统自陈的规则是「报废一律需审批」（SCRAP_ALWAYS_REQUIRES_APPROVAL = True），
但实际有 4 条写 TransScrap 的路径，其中 3 条绕过审批。本提交把三条旁路
全部收口，只保留「申请 → 审批 → 执行」一条写入路径。

【删除】直接报废 POST /api/v1/scrap
  同时移除 ScrapService.process_scrap()。该路径的一个连带影响是
  「维修件报废」能力随之消失 —— process_scrap 的 trans_repair 分支是
  repair_status='报废转出' 的唯一写入点。实测该能力零使用（报废转出 0 条、
  trans_scrap 来源 0 条），且早已半死：审批流的扫码校验会拒绝 trans_*
  来源。repair_service.py 的误导文案（原文指引操作员「前往报废管理进行
  扫码操作」，而那条路根本不通）已改为「维修件报废暂未开放」。
  权限元素 scrap_create:operation 保留不删 —— add_scrap_perm.sql 以它为
  scrap_apply/scrap_execute 的授权来源。

【改造】借库转报废 POST /borrow/scrap → POST /borrow/scrap-request
  TransService.scrap_borrow() 删除，逻辑迁入 BorrowScrapAdapter。
  沿用 op_return:operation 权限（零授权变更）。已归还/已报废的记录改为
  **直接报错**，不再静默 continue 返回 count=0（原缺陷：用户以为成功）。

【改造】不良品报废 POST /defective/<id>/scrap → POST /defective/<id>/scrap-request
  申请时**不预占** remaining_qty（与报废模块「仅锁定意向，不扣库存」的
  既有哲学一致）。副作用：同一批坏件可重复提交多张申请单，执行期由适配器
  按 Fail-Closed 拒绝超额的那几张。已在该接口注释与前端提示中写明。

【服务层】ScrapApprovalService 接入来源适配层
  - submit_approval 改由 get_adapter() 分派，并新增整单 scrap_mode 一致性
    校验（混合「需扫码/免扫码」两类来源直接拒绝，让 execute 分流保持简单）
  - _build_scanned_index 的来源校验改为 is_scan_source()：语义上是**收窄**
    而非放宽，扫码通道永远不接纳 trans_* 来源
  - execute 按模式分流：scan 项走原有扫码匹配（索引只由 scan 项构建），
    auto 项按批准量执行。签名与调用契约不变。
  - _match_key 加入来源表：不良品 SKU 是从原库存行复制的，不带来源时
    同一张单里的两者会**必然串键**，扫码量算到错误对象上。纯库存单两侧
    同源、键仍匹配，对既有流程零行为变更。

【修复】approve() 的 fail-open
  原实现 `if user_entries and str(operator_id) not in user_entries` ——
  allowed_approvers 为空时条件短路为假，**任何登录用户都能审批**。
  这与「报废一律需审批」直接矛盾，留这扇门等于没有审批。改为无名单即拒绝。
  已实测存量「无审批人」的在途单为 0 张，不会卡死历史数据。

【扫码通道】scrap/scan 的 trans_repair 分支改为 trans_defective_goods
  在管不良品按 SKU 匹配，在管量回填到既有字段形状，前端无需按来源分支。

【清理】scrap_approval_service 的 _stock_models 与 TransScrap 导入已移除
  （来源差异全部收敛到适配层）；trans_service / inventory_reservation 中
  指向已删方法的注释已更新指向 BorrowScrapAdapter。

2026-09-16 17:14:17 +08:00