yueli
c5356a27ed
fix(scrap): 补上遗漏的 phase14 迁移（不良品报废的库位/批次快照）
问题：前面几个报废提交里，inventory-backend/app/models/transaction.py 已经
引用了 db_migrations/phase14_defective_goods_location_snapshot.sql（两处注释
指向它），但**该文件本身没被提交** —— 代码与迁移对不上，别人拉下来跑不起来。
内容：为 trans_defective_goods 增加 warehouse_location / batch_number 两列，
并从源库存行回填存量。
为什么需要这两列：报废台账页与报废申请单明细上，凡是不良品来源的行，库位与
批次此前一律显示 "-" —— 因为应用层硬编码了空串，理由是「源库存行可能已被
物理删除」。该担忧对 material_name/spec_model 成立（所以它们有冗余快照），
但库位/批次当时**没有**快照列，一律置空等于放弃了「源行还在」这个绝大多数
情形。补上快照后，退回那一刻 stock_row 已 with_for_update() 锁在手里，
库位/批次随手可取，落库后即使源行日后被删除，报表依然有值。
口径：存「原库位」（这批货最初在哪），与三张库存表来源的报废记录一致；
不良品区的位置本系统未记录。batch_number 对 stock_product 来源存的是
serial_number（成品表无 batch_number 列），与 scrap.py 的 _from_stock 对齐。
安全性：纯追加式 DDL，无 NOT NULL、无 DEFAULT，幂等可重复执行。
已在本机执行验证：存量 1 行全部回填，源行已删取不到 0 行。
2026-09-23 17:16:08 +08:00
..
2026-09-11 14:38:40 +08:00
2026-09-08 10:14:40 +08:00
2026-09-21 14:13:13 +08:00
2026-09-16 16:44:46 +08:00
2026-09-09 09:31:12 +08:00
2026-09-09 10:47:36 +08:00
2026-09-16 16:44:46 +08:00
2026-09-16 16:44:46 +08:00
2026-09-10 17:21:14 +08:00
2026-09-10 09:46:52 +08:00
2026-09-10 09:46:52 +08:00
2026-09-10 10:14:19 +08:00
2026-09-11 11:33:04 +08:00
2026-09-11 13:28:43 +08:00
2026-09-08 10:14:40 +08:00
2026-09-17 10:51:31 +08:00
2026-07-17 13:07:12 +08:00
2026-09-16 15:45:02 +08:00
2026-07-17 15:29:59 +08:00
2026-09-09 13:00:35 +08:00
2026-09-16 15:45:22 +08:00
2026-09-16 15:45:22 +08:00
2026-09-17 09:17:51 +08:00
2026-09-17 09:17:51 +08:00
2026-09-17 10:04:05 +08:00
2026-09-17 10:12:31 +08:00
2026-09-17 10:44:00 +08:00
2026-09-17 10:46:31 +08:00
2026-09-17 11:07:50 +08:00
2026-09-17 11:26:36 +08:00
2026-09-17 11:56:38 +08:00
2026-09-17 12:07:21 +08:00
2026-09-18 09:27:17 +08:00
2026-09-18 09:34:44 +08:00
2026-09-23 09:10:55 +08:00
2026-09-23 15:17:44 +08:00
2026-09-23 15:17:44 +08:00
2026-09-23 17:16:08 +08:00
2026-09-10 10:14:19 +08:00