2 Commits

Author	SHA1	Message	Date
yueli	f7c49f41a8	fix(borrow): 统一归还/报废时间口径为北京时间，并修正过期注释 ... 时间口径（与归还流水同时引入，故随本轮一并修） ---- process_return 与 scrap_sources.deduct 原用 datetime.now() 写 return_time， 而 datetime.now() 取的是**容器本地时间**（Docker 下为 UTC）；同一行的 borrow_time 却由 beijing_time() 写入 —— 两个字段差 8 小时，台账时间线 自相矛盾，并会让新做的流转时间线出现「先借出、后归还，却显示归还更早」 的倒序假象。 统一改用 beijing_time()，并与新增的归还流水共用同一个时间戳，保证主表快照 与流水逐笔完全对齐。 （与 db_migrations/unify_approval_timezone.sql 处理的是同一类问题：aware/naive 与本地/北京时间的口径混用。） 注释修正 ---- borrow_service.submit_approval 的 docstring 写着「仅存储意向，不扣库存」， 但 Phase 1 起该函数已调用 reserve_for_items() 预占库存（扣 available_quantity）。 过期注释会误导后续开发者（尤其是做转交的人以为库存没动过），已改写为实际的 预占语义与三种释放路径（驳回 / 撤回 / 扫码执行）。	2026-09-17 09:18:02 +08:00
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