KCGL/inventory-backend at e4d2b2ec68fade25c0ccc59f8ec78548cf3dd6c0 - KCGL

Files

yueli e4d2b2ec68 feat(scrap): 报废来源适配层（纯新增，零行为变更）

把「报废来源差异」从审批服务里抽出来，为后续把借出未还、在管不良品
接入审批流铺路。

背景
----
报废审批流原先只认三张库存表（ScrapApprovalService._stock_models 硬编码），
导致另外两类来源只能各走直报接口绕过审批 —— 与系统自陈的
「报废一律需审批」（SCRAP_ALWAYS_REQUIRES_APPROVAL）冲突，构成职责分离
漏洞：同一个库管可自行宣告实物销毁而无人复核。

三类来源的语义差异
------------------
  维度        库存行            在管不良品        借出未还
  执行模式    scan              scan              auto（免扫码）
  可报废量    available_qty     remaining_qty     quantity-returned
  扣减        available 与      只动在管台账，    只扣 stock_quantity
              stock 同扣       不碰任何库存表    （可用量已在借出时冻结）
  成本        沿用现口径        defective_unit_cost  0/0

★ 为什么在管不良品保留扫码、借出未还免扫码：
  坏件实物就在仓库里、有 SKU，扫码是有效的「申请报 A、实际毁 B」防护；
  借出物在借用人手上，物理上不可能扫到，且执行只改台账与总库存、
  不产生任何可被挪用的可用库存，风险等级不同量级。

其他要点
--------
- defective_unit_cost() 从 api/v1/inbound/stock.py 迁入本模块：服务层不得
  反向 import API 层。复用 inventory_reservation.stock_model_map()，
  避免第四份库存表字典。
- 提交期新增 submit_guard 钩子，用于修复「提交只校验 available、执行却校验
  both」的校验不对称（会出现申请通过、执行必失败的单据）。
- is_scan_source() 对未知来源返回 False（Fail-Closed）：扫码通道只接纳明确
  声明为 scan 的来源，杜绝 trans_repair 那类「扫得到、执行却拒绝」的错配。

本步不触碰任何现有路由，现网仍走老路径，可独立评审与验证。

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