yueli
191724a176
fix(outbound): 修复扫码出库 500 —— applicant_id 用了尚未赋值的 approval
现象
----
所有扫码出库报 500（前端 create.vue 提交即失败）。
根因
----
上一个提交把 'applicant_id': approval.applicant_id 写进了 common_data，
但 common_data 构造在第 234 行，而 approval 直到第 269 行（「强制按单出库」
那一段）才查询赋值 —— 典型的变量先用后赋，直接 UnboundLocalError。
它影响的是**每一条**出库请求，属于必然复现而非偶发。
修复
----
把赋值移到 approval 取出并校验**之后**：common_data['applicant_id'] = ...
并在原处留注释说明为什么不能写在字典字面量里，避免后人搬回去。
★ 我的测试为什么没抓到
上一轮只测了「退回 → 补发」这条路径，而 applicant_id 的写入在**扫码出库**
路径上 —— 两条路径不重合，所以漏了。本次补测了完整的
「出库申请(预占) → 扫码出库(扣减)」链路。
验证（6 项断言全通过，走真实接口链路）
申请单创建（status=1，申请人=12，预占 stock_buy#2058 两件）
→ 扫码出库不再抛 500
→ 出库明细生成且 applicant_id = 12（不再是 NULL）
→ consumer_name 照常写入
→ 审批单置为已完成
→ 库存实际扣减 2
清理后库存与数据零残留。
★ 顺带在真实数据上得到印证：生产库中已有一笔由业务方重试成功的出库
（OUT-20260917-1333-0001），其 applicant_id 正确等于所关联申请单的申请人。
2026-09-17 13:35:47 +08:00
..
2026-05-21 14:09:57 +08:00
2026-09-17 11:26:36 +08:00
2026-05-27 09:57:01 +08:00
2026-09-10 10:14:17 +08:00
2026-08-03 09:22:50 +08:00
2026-09-08 10:14:44 +08:00
2026-09-09 13:00:41 +08:00
2026-09-17 09:18:02 +08:00
2026-07-13 15:12:22 +08:00
2026-08-03 15:53:10 +08:00
2026-09-17 09:26:42 +08:00
2026-07-16 11:26:12 +08:00
2026-09-17 13:35:47 +08:00
2026-07-17 16:22:59 +08:00
2026-09-10 17:41:22 +08:00
2026-09-16 17:14:17 +08:00
2026-09-17 09:18:02 +08:00
2026-09-01 13:52:56 +08:00
2026-09-01 13:52:56 +08:00
2026-09-17 10:46:31 +08:00