|
|
a8a3c82331
|
fix(stock): 补行级防穿仓与入库改量下限，杜绝可用数变负
available_quantity 一旦为负，预占/释放/盘点的全部算术都会失真。此前有两处
缺口，本次一并堵上，使 available_quantity >= 0 成为不变量。
1) 执行阶段逐行扣减无下限校验（inventory_reservation.restore_then_deduct）
物料级校验只保证「Σ实扫 ≤ Σ可用」这一总量关系，拦不住「总量守恒但单行
穿仓」：同物料下 A 批可用 2、B 批可用 8，工人把 5 件全压在 A 批上，总量
5 ≤ 10 通过，A 批却被扣成 -3。借库走 deduct_stock=False，连实物数校验都
跳过，是裸扣。
已实测复现：借库与出库路径均可把单行扣成 -3。
校验放在 release_reserved() 之后，故不会误拒合法的换批次（物理覆盖）：
释放后每行 available 已含本单预占，扫自己预占过的批次时 raw >= 0 保证
必然放行；改扫其它批次时，该批次实时可用量就是它自己的上限。
2) 下调入库数量可把可用数压成负（buy/product/semi 三处 update_inbound）
按 diff 同步增减 stock/available，但无任何下限检查。该批次若已有部分被
预占/出库/借出，向下调整即产生负可用数。现在下调前校验可用数是否够扣。
正常数据下 stock >= available 恒成立，故守住 available 同时守住 stock。
配套：三个 update_* 端点此前只捕获 Exception → 500，没有 ValueError 分支
（同文件的 delete_* 早就有）。补上 400 分支，使业务校验失败不再被记成
服务端故障。
验证（事务内执行并回滚，未落库）：跨批次穿仓被拦、合法换批次放行、全额执行
本单预占批次放行、下调击穿被拦（API 返回 400，三个端点一致）、上调不受影响、
真实借库单 52 行全额执行正常、全库无负可用数。
|
2026-09-11 10:34:15 +08:00 |
|
|
|
cbcedecba2
|
fix(outbound): 扫码/备选库位回加本单预占，修正可用数重复计数
出库选单提交申请时 reserve_for_items() 会立即扣减 available_quantity（预占，
防超卖），但扫码页拿到的仍是这个已被本单扣过的值，并当作「本单能扫多少」的
上限。对本单而言它自己锁掉的货当然该能扫，于是同一批货被算了两次：
· 某行被本单占满时 available=0，工人直接扫不进去，提示「库存不足或已出库」
· /alternatives 按 available_quantity > 0 过滤，被本单占满的行从列表消失
· 草稿恢复时刷新实时库存，误报「实际库存已少于你扫的数量」
改法：扫码阶段的可用量 = 实时可用量 + 本单在该行的预占量。别人单子的预占
不回加，防超卖能力不丢。该值与后端 restore_then_deduct() 释放预占后用于校验
的数字精确相等，是同一口径而非近似。
后端：
- inventory_reservation.py 新增 reserved_index()/reserved_qty() 纯读工具
- outbound.py 新增 _own_reserved_index()，改造 /scan 与 /alternatives
- outbound_service.py 的 _format_scan_result 返回归一化可用量
两道门禁：
- biz_type 区分出库/借库两张审批单（独立表、ID 空间独立，而两个端点被
出库页与借库页共用），否则借库单 ID 会命中另一张出库单
- 单据状态仅放行 status ∈ {0,1}。set_items() 只在创建时调用，执行/驳回后
items_json 里的 reserved=True 仍原样保留而库存早已归还，门禁一松就会
二次回加 → 真超卖（现有 3 张已完成单据即属此形态）
不满足门禁时静默降级为不回加（fail-closed），并回传 reservation_applied。
|
2026-09-11 10:34:00 +08:00 |
|
|
|
b8561f69f7
|
V3.77,9.11推送
|
2026-09-11 09:39:59 +08:00 |
|
|
|
f702a70fe5
|
fix(borrow): 借出只冻结可用数，不再扣减实物库存
问题
----
上一轮库存预占改造（b57c21a）把借库执行改用了 restore_then_deduct()，
而该函数是按**出库语义**设计的（物品永久离开仓库），会同时扣减
available_quantity 与 stock_quantity。借库是可逆的，于是产生两个缺陷：
1) 借出再归还后，实物库存永久少一份
初始 (stock=20, avail=20)
借出5 (stock=15, avail=15)
归还5 (stock=15, avail=20) ← 实物没回来，丢了 5
2) 借出后转报废会重复扣减
scrap_borrow 的注释明确写着「扣减总库存（该物品确认损失）；
可用库存已在借出时冻结，无需重复扣」—— 它假设借出**没动实物**。
借出已扣 stock 后，转报废再扣一次：
借出5 stock=15 → 转报废 stock=10（正确应为 15）
修复
----
restore_then_deduct 增加 deduct_stock 参数：
出库 deduct_stock=True （默认）—— 可用数、实物数同时扣
借库 deduct_stock=False —— 只冻结可用数，实物数不动
★ 这是**恢复原有设计**，不是新设计。git 历史显示从最初的
04ee938 借库逻辑实现 起，历经 7ef22a3 / 83b3db6 / b79b0f9 /
2556b77 / 1527d55 六次提交，一直是：
stock.available_quantity = float(stock.available_quantity) - qty
（只减可用，不动实物）。b57c21a 把它替换掉了。
盘点的差异计算也印证了该口径的正确性：
adjusted_stock_qty = stock_quantity - 借出未还
diff_qty = 实盘数 - adjusted_stock_qty
这段逻辑要求 stock_quantity **包含**借出未还的实物，否则会重复扣减。
最终语义
--------
stock_quantity = 账面实物总数（含借出未还）
available_quantity = 实际可取用数
出库申请(预占) — available ↓
出库执行 stock ↓ available ↓
借库申请(预占) — available ↓
借库执行 — available ↓
借库归还 — available ↑
借库转报废 stock ↓ —
实测（stock, available）
------------------------
借还循环：初始(20,20) → 借出5(20,15) → 归还5(20,20) 完全可逆
出库： 预占4(20,16) → 执行(16,16) 实物确实减
转报废： 借出3(20,17) → 转报废(17,17) 实物减一次，不重复
|
2026-09-11 09:39:20 +08:00 |
|
|
|
e5a7cb2736
|
V3.76,9.11推送
|
2026-09-11 09:07:14 +08:00 |
|
|
|
ce767e39ac
|
feat(scan): 扫码时检测单据失效，避免白扫一场
场景
----
库管正在扫码，这张单被撤回/驳回/执行了。若不检测，库管会一直扫到
提交时才发现单据已作废（后端会拒绝），前面的工作白做。
实现
----
新增 checkRequestStillValid()：重新拉一次「已通过(status=1)」列表，
看当前单据是否还在其中。不在 → 已被撤回/驳回/执行，立即弹窗告知并
清空界面（草稿后端也已同步清除）。复用现有列表接口，无需新增端点。
触发时机（覆盖两类场景）：
· 页面重新可见时（visibilitychange）—— PDA 熄屏唤醒、切回标签页
· 每 60 秒一次 —— 库管一直在页面上扫、没切走
三点取舍：
· 仅购物车非空时检测（正在作业才打扰），空清单不发请求；
· 60 秒轮询而非实时推送 —— 引入 WebSocket 长连接成本过高，
此处最多浪费 1 分钟扫码，相比"扫完几十分钟才发现"已足够；
· 检测失败不阻断作业（仅 console.warn）—— 后端提交时仍会做最终校验，
前端检测是为了早发现，不是安全防线。
出库 create.vue 与借库 borrow.vue 两页同款实现。
|
2026-09-11 09:06:51 +08:00 |
|
|
|
33acdc758c
|
fix(scan-draft): 撤回申请单时清理其扫码草稿
问题
----
草稿按 (user_id, biz_type, request_id) 存储，而撤回逻辑原先只做两件事：
释放预占、把状态置为 4。没有任何草稿清理 —— 撤回后草稿成为孤儿数据：
· 单据状态变为 4，不再出现在扫码页的下拉里（那里只拉 status=1），
草稿从此永远读不到；
· 若不清理会持续累积，每行是一个整单 JSON 快照。
实测（撤回前 2 份草稿）：撤回后该单草稿数归 0。
★ 清的是**所有用户**在这张单上的草稿，而非仅撤回者自己的 ——
可能有多人扫过同一张单，只清自己的会留下他人的孤儿数据。
出库 outbound_service._release_and_close
借库 borrow_service._release_and_close
两处共用底层，一并补上。
|
2026-09-11 09:06:43 +08:00 |
|
|
|
6f2f077751
|
feat(purchase): 采购页搜索区对齐出库记录版式
原顶部工具栏是裸 div + 状态单选，现改为 el-form :inline 版式，与出库记录 /
报废记录一致：
状态 全部 / 待审批 / 已通过 / 已驳回 / 已完成 / 已完结
搜索 [搜索类型下拉] + 关键词输入，500ms 防抖
采购日期 日期范围选择
按钮 查询 / 重置 / 新建采购申请
交互细节：
· 搜索类型切换、清空输入时立即查询（取消防抖等待）；
· 「重置」恢复默认的「待审批」状态（该页默认视图），而非清成"全部"——
与页面初始状态保持一致；
· 重置同时清空关键词、搜索类型、日期范围。
api/purchase.ts 的 getPurchaseList 补充新参数的类型定义。
|
2026-09-10 17:41:29 +08:00 |
|
|
|
e93107458a
|
feat(purchase): 采购列表支持关键词搜索与日期范围
背景
----
采购管理此前只有状态筛选，无法按单号/物料/申请人检索，也无法按采购
日期收窄范围。现对齐出库/报废记录的搜索语义，便于用户迁移使用习惯。
后端
----
PurchaseService.get_purchase_list 新增参数：
keyword / search_type / start_date / end_date
search_type 取值（与出库、报废一致）：
all 单号 | 物料名称 | 规格型号 | 备注 | 申请人
no 单号
name 物料名称
spec_model 规格型号
requester 申请人
实现要点
--------
· 申请人姓名存在 SysUser.username，格式「姓名/账号」（如 韩善龙/hanshanlong），
ilike 直接匹配整串即可命中；
· 该类字段只在 SysUser 上，故**按需 join** —— 单号/名称/规格分支不联表，
避免无谓开销；
· 公司隔离分支也需 join SysUser，与关键词分支可能重复 join 同一目标，
会产生笛卡尔积导致结果翻倍，故按需补 join 并用 distinct 兜底；
· 日期范围按 purchase_date 过滤（该列是 Date，无需补时分秒）。
实测：名称'充电器'→1 单，申请人'韩善龙'→21 单，日期 05-13→2 单，
关键词不存在→0 单，状态+搜索组合→14 单。
|
2026-09-10 17:41:22 +08:00 |
|
|
|
a4a9afb6db
|
feat(scan): 出库/借库扫码页接入草稿，切换单据不清空
交互
----
无需「暂停」按钮 —— 在下拉框切换单据这个动作本身就是暂停：
切走 → 自动存当前单据的进度
切回 → 自动恢复，并提示「已恢复上次的扫码进度（N 项）」
下拉框对扫到一半的单据显示橙色「已扫 N」徽标，不必逐个点开试。
提交成功后自动清除该单据的草稿。
修复的三个 bug
--------------
1) 切换时把 A 的内容存到了 B 名下
v-model="selectedRequestId" 的 computed setter 会**先于** @change 把
selectedRequest 改成新单，故 handleRequestChange 里读到的是新单。
新增 activeRequestId ref 记录「界面上真正显示的是哪张单」，
保存时显式传入离开的那张单的 ID。
2) 切回时把目标单的旧草稿删了
原先写了「购物车为空则清除草稿」，但切换瞬间购物车必然为空，
于是切回 A 时触发了清除。现改为空清单只跳过保存、不清除；
清理由「提交成功」或「用户点清空列表」显式触发。
3) 恢复后名称/规格为空、出库数显示 NaN
draftPayload 只存了 4 个字段（stock_id/source_table/sku/quantity），
而购物车表格绑定的是 name/spec_model/available_quantity/out_quantity
—— 全都没存。现保存完整快照，并在恢复时归一化
（out_quantity ?? quantity）以兼容已存在的旧草稿。
补充：恢复后刷新实时库存
------------------------
草稿里的 available_quantity 是扫描那一刻的快照，跨时间恢复可能已过期
（期间别人出库/借出会消耗可用量）。恢复后复用 /alternatives 端点拉一次
实时可用量：数量超了会明确提示「N 项物料的实际库存已少于你扫的数量」，
避免工人扫满后到提交时才被后端拒绝。失败不阻断，沿用草稿快照。
另：离开页面（路由跳转）时存草稿并弹确认；beforeunload 用 sendBeacon
尽力保存（该路径无法带 Authorization 头，可能失败，但防抖保存已覆盖
绝大部分内容）。
|
2026-09-10 17:21:24 +08:00 |
|
|
|
ec66c33b06
|
feat(scan-draft): 扫码草稿表与接口，支持暂停后继续扫码
场景
----
扫码出库/借库的作业可能很长（一张单几十项），工人常需中途暂停去处理
更紧急的单据。改造前切换单据会清空已扫内容，刷新/退出页面则全部丢失。
由于库存在申请审批通过时已**预占**，暂停期间货不会被他人抢走 ——
因此草稿只记录「扫到哪了」，**不涉及任何库存操作**。即使草稿丢失也只是
需要重扫，不会造成库存错乱。
隔离粒度
--------
按 (user_id, biz_type, request_id) 一人一单：每个人扫自己的草稿，互不影响；
同一人可同时持有多张单据的草稿（正是「暂停 A 去出 B」的场景）。
user_id 一律取自 JWT，不接受入参覆盖，故不可能读写他人草稿。
为什么整单存一个 JSON（而非每条明细一行）
------------------------------------------
1. 保存是「全量覆盖」语义，逐行存无增量更新的收益；
2. 恢复时需要物料名称/规格/库位等展示字段，逐行方案只能回查申请单的
items_json —— 而历史单据的 items_json 不含 stock_id，回查会错配。
整单快照把展示字段一并存下，恢复零依赖，对老单据同样可靠。
接口
----
GET /api/v1/scan-draft 读取草稿
POST /api/v1/scan-draft 保存（全量覆盖；空清单则删除）
DELETE /api/v1/scan-draft 清除（提交成功后调用）
GET /api/v1/scan-draft/overview 各单据进度，供下拉徽标
实现要点
--------
· items_json 列是 jsonb，模型必须用 db.JSON —— 用 db.Text 会让 psycopg2
拿到 Python list/dict 时无法适配，报 "can't adapt type 'dict'"，而异常
被接口的 except 吞掉后 POST 仍返回"成功"，问题极难发现（开发中实际踩到）；
· 概览接口做防御：残留的空草稿不参与展示。
实测：保存/读回、跨单据隔离（B 读 A 的草稿为 0 项）、全量覆盖、
提交后清除，全部符合预期。
|
2026-09-10 17:21:14 +08:00 |
|
|
|
a07432981e
|
feat(borrow): 扫码借库页的清单对齐扫码出库页
问题
----
扫码借库页（views/transaction/borrow.vue）的「审批计划清单」与扫码出库页
的「计划出库清单」样式不一致：
· 标题：审批计划清单 / 计划出库清单
· 类型列：借库有、出库已删
· 数量列：借库用「审批数量」且排在最右；出库是「计划数量」且前置
· 备选库位：借库没有
· 清单容器：借库灰底 #f5f7fa，出库是淡绿 #f0f9eb + 边框
改动（五项全部对齐）
--------------------
· 标题改为「计划借用清单」；
· 移除「类型」列；
· 「计划数量」前置到序号之后，橙色 #E6A23C 加粗 15px；
· 新增备选库位：库位格子整体可点击 + popover（与出库页逐字相同的实现）；
· 清单容器改为淡绿背景 #f0f9eb + #e1f3d8 边框 + 圆角，标题绿色加粗。
备选库位复用了出库模块的 /alternatives 端点。已核实前提：借库申请单的
items_json 由预占改造写入 base_id / stock_id / source_table，故「推荐/备选」
标注可正常工作（对历史单据无这些字段时会安全回退为纯文本）。
定位说明
--------
借库有三个页面（选单 / 扫码 / 审批），上一轮按「计划清单」关键词搜索时
命中了审批页的展开行，改错了位置。本提交修正的是真正的扫码借库页。
|
2026-09-10 16:17:50 +08:00 |
|
|
|
f8267c6ee2
|
style(borrow): 审批页物料明细数量前置，清单标题对齐出库
背景
----
借库审批页展开行的「计划数量」排在表格最右（库位之后），与扫码出库页
的前置做法不一致 —— 列多时容易被容器裁掉，工人看不到数量。
改动
----
· 计划数量从最右移到序号之后，橙色加粗 + 字号 15px；
· 清单标题由朴素文字改为与出库页同款的标题栏结构
（planned-header + planned-title + 绿色标签）；
· 补上 .planned-header / .planned-title 样式定义（该页原先没有）。
注：本轮定位时曾误以为这是用户反馈的「扫码借库页」，实际扫码借库页是
views/transaction/borrow.vue（见下一提交）。此处是同类问题的另一处，
一并修正，非误改。
|
2026-09-10 16:17:42 +08:00 |
|
|
|
eeefaeb528
|
V3.74,9.10推送
|
2026-09-10 15:59:13 +08:00 |
|
|
|
d69ec9f5ec
|
style(outbound,borrow): 库位格子整体可点击，图标放大
问题
----
备选库位浮层的触发区原先只有一个小图标（默认 1em），工人需要精准
点击才能弹出 —— 戴手套或在触屏上操作时命中率很低。
改动
----
· #reference 从「仅图标」改为「库位文字 + 图标」整体，
点格子任意位置都能弹出；
· 悬停时整格高亮（#ecf5ff），给出可点击的视觉反馈；
· 图标放大到 18px；
· 库位文字着蓝色（#409EFF），并加 title 提示；
· 无 base_id 时回退为纯文本（历史单据）——原先这种情况下会渲染空白。
出库执行页与借库审批页同款实现，一并同步。
注：编辑过程中曾因残留旧的 popover 闭合标签导致模板结构损坏
（SFC PARSE ERR），已通过编译检查发现并修复。
|
2026-09-10 15:57:26 +08:00 |
|
|
|
ea52c78f9e
|
feat(outbound): 计划出库清单数量前置，移除类型列
问题
----
计划出库清单的「计划数量」列排在表格最右侧（名称/规格/库位之后）。
表格共 6 列且名称规格会撑宽，最右列容易被容器裁掉，工人反馈"看不见数量"。
改动
----
· 「计划数量」从最右移到「序号」之后，橙色加粗 + 字号放大到 15px；
· 移除「类型」列（material_type）；
· 库位列宽 150 → 170。
注：该列一直存在且数据正常（items_json 的 quantity 字段），
此前是可见性问题而非数据缺失。
|
2026-09-10 15:57:20 +08:00 |
|
|
|
851c3a9c1f
|
feat(my-requests): 主列表展示数量，移除类型列
问题
----
主列表只有「物料数 N 种」（种类数），具体数量藏在展开行的明细表里，
不展开就看不到。
改动
----
· 移除「类型」列（type_label）；
· 新增「数量」列，紧跟申请单号，橙色加粗；
· 新增 totalQty() 汇总单据总数量。
totalQty 只认 quantity 字段，无需按 type 分支 —— 因为聚合端点已做字段
归一化（报废的 scrap_qty → quantity）。这正是当初做归一化的价值。
数值经 Number(sum.toFixed(4)) 处理，去掉 1.0000 这类无意义的小数尾巴。
顺带移除已无引用的 typeTagType()。
|
2026-09-10 15:57:15 +08:00 |
|
|
|
dc4a0ae7a0
|
style: 统一申请单状态配色（四个页面一致）
配色方案
--------
0 待审批 → 蓝（primary，待处理）
1 已通过 → 绿（success，正向结果）
2 已驳回 → 红（danger）
3 已完成 → 灰（info，终态、不再需要关注）
4 已撤回 → 黄（warning，需留意但非错误）
范围
----
「我的申请单」新页面按上述配色实现后，发现出库/借库/报废三个审批页
仍是旧配色（0:warning, 3:info, 4:info）—— 同一套状态码在两个页面
显示不同颜色，用户来回切换会困惑。故一并统一。
改动：my-requests/index.vue（新配色）+ 三个审批页的 statusTagType。
补充：el-tag 的 primary 类型已核实可用 —— Element Plus 2.13.1 的
tagProps 中 primary 为默认值，theme-chalk/el-tag.css 含 .el-tag--primary
的蓝色样式定义；vue-tsc 类型检查通过。
|
2026-09-10 15:47:07 +08:00 |
|
|
|
29fc00a818
|
fix(my-requests): 修正 withdraw_endpoint 路径前缀导致撤回 404
现象
----
在「我的申请单」页面点撤回，前端控制台报：
POST /api/api/v1/outbound/request/351/withdraw 404
根因
----
aggregate 端点在每条记录上回传 withdraw_endpoint，但拼接时多写了 /api：
返回的: /api/v1/outbound/request/351/withdraw
axios baseURL: /api
实际请求: /api + /api/v1/... = /api/api/v1/... → 404
后端路由本身是对的（/api/v1/outbound/request/<id>/withdraw 已正确注册），
问题纯在前端拼接。其它 API 封装的正确写法是只传 baseURL 之后的部分
（如 url: '/v1/outbound/my-requests'），本处是唯一破坏该约定的地方。
修复
----
返回 /v1/... 而非 /api/v1/...，并加注释说明约定。
借库项同时从 close 改为 withdraw（配合上一提交的申请人端点）。
验证方式
--------
按**前端真实的拼接方式**验证（'/api' + endpoint），而非直接调后端路由：
[outbound] /v1/outbound/request/381/withdraw → 200
[borrow ] /v1/transactions/borrow/request/44/withdraw → 200
[scrap ] /v1/scrap/request/5/withdraw → 200
教训：上一轮用 test_client 直接调后端路由验证，绕过了 axios 的 baseURL
拼接，所以后端测试全绿、前端一跑就 404。验证「前端能否调通」必须模拟
前端的请求方式。
|
2026-09-10 15:47:02 +08:00 |
|
|
|
077fd2f2cf
|
feat(borrow,scrap): 补齐申请人撤回端点，与出库对齐
背景
----
出库已有独立的申请人撤回端点（仅 @jwt_required + 服务层归属断言），
但借库/报废没有：
· 借库撤回复用 close 端点，权限是 op_borrow_approval（管理路径），
普通员工调用返回 403；
· 报废撤回带 @permission_required('scrap_apply')，同样挡住普通申请人
（scrap_apply 只授予 INBOUND/OUTBOUND/SUPERVISOR/SUPER_ADMIN）。
结果是「我的申请单」页面里，借库/报废的撤回按钮对普通员工点了报错。
借库
----
服务层拆成与管理路径并列的两条入口（与出库同构）：
mark_completed —— 管理路径，需 op_borrow_approval，仅 status==1
withdraw_request —— 申请人路径，仅校验单据归属，status 0 或 1
两者共用 _release_and_close()，释放逻辑只有一份实现。
新增 POST /transactions/borrow/request/<id>/withdraw（仅 @jwt_required）。
报废
----
withdraw() 增加 require_owner 参数区分两条路径：
require_owner=True （默认，申请人路径）→ 断言 applicant_id == operator_id
require_owner=False（管理路径） → 由调用方权限装饰器鉴权
WITHDRAWABLE_STATUS 从 (1,) 放宽到 (0, 1)，与出库/借库对齐。
移除端点上的 @permission_required('scrap_apply')，改走归属校验。
安全实测
--------
借库 B 撤 A 的单 → 403，库存仍是 27（未被释放）
借库 A 撤自己的单 → 200，30 完全释放
报废 B 撤 A 的单 → 403
报废 A 撤自己的单 → 200
主管代撤员工的单（特权路径）→ 200
|
2026-09-10 15:46:55 +08:00 |
|
|
|
c999aac1e3
|
fix(scrap): 撤回按钮改用 scrap_approval 权限，修正错配
报废审批页的「撤回」按钮原先复用了执行按钮的 canExecute 条件
（scrap_execute）。但 scrap_execute 比 scrap_approval 多授予 INBOUND 角色 ——
意味着只具备执行权、无审批权的人也会看到撤回按钮。
撤回是对单据的处置动作，应与审批同权限等级。新增 canWithdraw 计算属性
（SUPER_ADMIN 或 scrap_approval），替换原 canExecute。
注：申请人在「我的申请单」页有自己的撤回入口，走的是单据归属校验，
不依赖此处权限。
|
2026-09-10 15:37:17 +08:00 |
|
|
|
20d49c0b0d
|
feat(my-requests): 我的申请单独立模块（采购管理之后）
路由位置
--------
放在「采购管理」之后，作为独立一级模块：
采购管理
我的申请单 ← 新增（icon: Tickets）
借库管理
★ 独立模块而非挂在某个业务页下：申请人可能提交出库/借库/报废三类单据，
放在任一业务模块下都会让其它模块的人找不到。
页面功能
--------
· 类型筛选：全部 / 出库 / 借库 / 报废
· 状态筛选：全部 / 待审批 / 已通过 / 已驳回 / 已完成 / 已撤回
· 展开行显示物料明细（数量字段已由后端归一化）
· 撤回按钮仅对 status 0/1 可见（已预占但未执行）
撤回不硬编码 URL —— 使用后端回传的 withdraw_endpoint 分发：
const res = await request({ url: row.withdraw_endpoint, method: 'post' })
这样将来模块端点调整（如借库从 close 换成正式 withdraw），前端无需改动。
权限说明
--------
菜单不做权限过滤（Sidebar 只过滤 meta.hidden），所有角色都会看到本页。
这正是预期 —— 申请人本就不应需要任何权限码。数据由后端强制按
applicant_id 过滤，看不到他人单据。
顺带清理
--------
移除先前加在 Selection.vue 的重复实现（约 110 行模板/脚本/样式），
改为一个跳转链接「查看我的申请单 >」；并移除随之失效的 3 个导入
（onMounted / Refresh / 两个 API 函数）。
验证：新页面 SFC 编译零告警；Selection.vue 清理后编译通过。
|
2026-09-10 15:37:11 +08:00 |
|
|
|
b67d577616
|
feat(my-requests): 跨模块聚合端点，一个页面看全部申请
动机
----
出库/借库/报废三个模块各有一套审批流，申请人此前没有统一入口。
新增只读聚合视图，把三类单据合并返回。
为什么单独建蓝图
----------------
权限模型不同：审批端点是「管理视角」，本端点是「申请人视角」。
把两者塞进同一端点（if not privileged: applicant_id = me）会让管理逻辑
与用户逻辑混流，一旦 is_privileged_viewer() 判定出错即越权。
本模块从设计上就没有「看别人」的分支 —— applicant_id 硬编码为当前用户。
只读保证
--------
本模块只做查询，不修改任何数据。撤回等写操作仍由各模块自己的端点承担
（因为三者释放逻辑不同：出库/借库已接入预占，报废尚未接入）。
把风险锁在只读层，即使聚合逻辑有 bug 也不会破坏业务数据。
字段归一化
----------
三个模块的 items_json 存在差异，统一在服务端抹平：
· 数量字段：报废用 scrap_qty，出库/借库用 quantity → 统一为 quantity
· 库位字段：报废用 location → 统一为 warehouse_location
这专门避免「报废行的数量列显示空白」这类不报错的隐性 bug。
健壮性
------
单个模块查询失败时记日志并跳过，其余模块照常返回
（例如某张表尚未迁移时，其它两类仍可用）。
响应中附带 withdraw_endpoint 字段，前端据此分发撤回请求，
无需硬编码三个模块的 URL 映射。
实测
----
普通员工（INBOUND 角色，无任何审批权限）访问 → 200，18 单
三类单据齐全，type_label 正确
报废明细数量字段归一化成功（quantity=1.0）
B 看不到 A 的单 → 0 条
type=scrap 过滤 → 全部为报废
|
2026-09-10 15:37:05 +08:00 |
|
|
|
bcbee8a194
|
feat(outbound): 申请人撤回自己的申请单 + 我的申请单端点
背景
----
出库审批页是管理视角（需 outbound_approval 权限），普通申请人提交后
**没有任何入口看回自己的单据**，更谈不上撤回。
服务层：抽出共用释放逻辑
------------------------
新增 OutboundApprovalService.withdraw_request()，与既有的 close_request()
（管理路径）形成两条独立入口：
close_request —— 管理路径，需 outbound_approval 等权限，仅 status==1
withdraw_request —— 申请人路径，仅校验「单据归属」，status 0 或 1 均可
两者各自完成权限与状态校验后，调用**同一个** _release_and_close()。
释放逻辑只有一份实现，不会因修改其中一处而漏掉另一处。
为什么单独开一条路径，而不是在 close_request 里加 if 分支：
权限模型不同（管理角色 vs 单据归属）。混在一个函数里，后续修改容易
互相影响 —— 这正是需要避免的访问控制风险。
API
---
POST /outbound/request/<id>/withdraw 申请人撤回（仅 @jwt_required）
· 归属断言：非本人且非特权 → 403「无权撤回他人的申请单」
· 状态守卫：仅 0/1 可撤回；执行成功后 status 会被置 3，故该判断
本身即执行守卫，已执行或已撤回的单都进不来
GET /outbound/my-requests 我的申请（仅 @jwt_required）
· applicant_id 硬编码为当前登录用户，不接受任何入参覆盖
两者都**不做模块权限校验** —— 普通申请人无需持有 outbound_approval
（那是管理权限）。与「给审批端点加 if 降级放行」是两条路：后者把管理
逻辑与用户逻辑混在一个端点里，一旦 is_privileged_viewer() 判定出错
即越权；本端点从设计上就没有「看别人」的分支。
安全实测
--------
普通员工查我的申请（此前 403） → 200
B 查列表看不到 A 的单 → 39 单中无 A 的单
B 撤回 A 的单 → 403，且库存未被释放
A 撤回自己的单 → 200，库存 17→20 完全释放
主管代撤他人工单 → 200（特权路径）
待审批(status=0) 撤回 → 200，库存释放
重复撤回 → 400「当前状态不可撤回」
|
2026-09-10 15:36:59 +08:00 |
|
|
|
d1dd3dd404
|
feat(approval): 三端审批页「撤回」入口，明确告知会释放库存
后端已支持撤回时释放预占（见上一提交），前端同步：
一、文案与语义
按钮 完结 → 撤回，颜色 danger → warning（语义从「危险操作」变为
「可逆的库存释放」）。确认弹窗明确告知会释放多少项库存：
确定撤回申请单【APR-OUT-...】吗？
撤回后该单将被作废，其预占的 5 项物料库存会立即释放，
可供其它申请使用。此操作不可恢复。
用户看到的「1 件货」背后其实是一批被锁定的库存，不写清楚会让人
以为撤回只是「关掉一张单」。
二、报废新增撤回入口
报废审批页原先只有「执行报废」，没有撤回。补上按钮 + handleWithdraw()，
并新增 API 封装 withdrawScrapRequest()。
状态映射同步补充 4: '已撤回'（statusText / statusTagType）。
三、成功提示改为透传后端消息
后端会返回「申请单已撤回，释放 N 项预占库存」，比前端写死的文案
更有信息量，故改为 res?.msg 优先、前端文案兜底。
按钮可见性沿用 row.status === 1（已通过但未执行），与后端的执行守卫
（执行成功后 status 置 3）一致，故已执行或已撤回的单不会出现该按钮。
|
2026-09-10 15:08:43 +08:00 |
|
|
|
9925bf2b99
|
fix(inventory): 撤回/作废单据时释放预占库存，消除库存泄漏
问题
----
系统原本已有「完结」功能（出库/借库），但它只改状态、不释放预占：
approval.status = 4 # 已完结
db.session.commit() # ← 库存没还回去
申请阶段 reserve_for_items() 扣掉的 available_quantity 就此永久泄漏 ——
货被一张永不执行的作废单锁死，谁也领不走。
核查存量 23 张 status=4 的单，所幸均为预占改造前提交（items_json 无
stock_id），尚未造成实际损失。但缺陷本身是真实的。
改动（三个模块统一）
--------------------
出库 outbound_service.close_request
借库 borrow_service.mark_completed
· 调用 release_reserved(approval.get_items()) 按 items_json 原样归还；
· 明确「仅 status==1（已通过待执行）可撤回」—— 执行成功后
create_outbound_batch / execute_dispatch 会把 status 置为 3，
故该状态判断本身即执行守卫，已执行或已撤回的单都进不来；
· 返回消息带上释放条数，便于操作者确认。
报废 scrap_approval_service.withdraw（新增能力）
· 报废原先只有 approve/reject，没有撤回入口，补齐；
· 复用同一个 release_reserved()：报废当前尚未接入预占，调用它会安全
跳过（无 reserved 标记），但将来报废接入预占时该段代码自动生效；
· 新增端点 POST /api/v1/scrap/request/<id>/withdraw（权限 scrap_apply）。
未采用按流水表二次校验：request_no(APR-OUT-…) 与 outbound_no(OUT-…)
格式不同、无关联字段，按单号比对是无效的，状态判断已足够。
实测
----
决定性用例（证明释放真实生效，非账面功夫）：
A单预占5 → available=1
B单要5 → 400 拒绝（被A占住）
撤回A → available=6
B单再要5 → 200 成功，available=1 ★ 释放的库存真的可被复用
三模块：
出库 撤回后 4→10 完全恢复，stock 未变（货没动）
借库 撤回后 6→10 完全恢复
报废 撤回成功，重复撤回被正确拒绝
状态码说明：报废复用出库/借库已有的 4=已完结 作为「已撤回」，
而非引入 -1，避免同一系统出现两套编号（其 2 已被「已驳回」占用）。
|
2026-09-10 15:08:32 +08:00 |
|
|
|
8c18586a94
|
feat(borrow): 借库审批页备选库位，与出库保持一致
借库的执行入口在审批页 —— 展开行即为工人查看/去扫码的物料明细。
申请单已把货预占在某库位，工人现场可能进不去，需要改扫同物料的其它
批次（后端执行端按 base_id 校验身份、允许换批次），但改造前系统不告诉
他还有哪些库位有货。
复用出库模块的 /api/v1/outbound/alternatives 端点（逻辑完全一致：
按 available_quantity > 0 过滤，只给真正能拿的库位，排除已被别单占满的行），
在明细表的库位列加图标 + popover：
[推荐] L5/1/2/1 可用 840 ← 本单锁定行
[备选] L2/1/2/1 可用 1
与出库页同款取舍：
· trigger="click" —— 车间用扫码枪/触摸屏，hover 在触屏不可用
· @show 时才发请求 —— 展开单据时不会打出一片并发查询
· 附提示文案「现场取不到推荐库位时可直接扫备选库位条码借用」
注：借库申请经预占改造后 items_json 已带 base_id/stock_id/source_table，
故推荐行可正确标注；改造前的历史单无这些字段，此时全部显示为「备选」。
|
2026-09-10 15:02:22 +08:00 |
|
|
|
24b7fd8373
|
fix(audit): 模块下拉中文化，消除 image_embeddings 等英文遗留值
问题
----
模块筛选下拉仍出现 image_embeddings、purchase_request、sys_element 等
英文值。它们来自改造前的全局监听器：那时无白名单，系统表/草稿表/向量表
都会被审计，而 _infer_module_name 对未登记的类名直接回退成表名。
下拉取 DISTINCT module，这些英文值就混了进来。
处理
----
新增 moduleMap（21 项）+ moduleLabel()，并应用到**三处**渲染：
下拉选项、列表列、详情弹窗的模块标签。
value 保留原始字符串，筛选行为完全不变。
除覆盖现存 3 个英文值外，另预置了 18 个白名单表名（sys_user / stock_buy /
trans_outbound 等）。新监听器已保证 module 为中文，但若将来有数据从旧
路径写入或手工导入，这些值会再次出现，预置可避免同类问题复发。
其中 image_embeddings 标注为「图像特征(历史)」以提示其为改造前的产物。
实测：image_embeddings → 图像特征(历史)，purchase_request → 采购申请，
sys_element → 系统元素；中文模块名原样保留。
|
2026-09-10 14:59:22 +08:00 |
|
|
|
209b29c10f
|
feat(outbound): 备选库位可见性，让「物理覆盖」不再盲扫
问题
----
预占会把货锁定在某个库位，但工人到现场可能进不去/找不到该库位，
需要改扫同物料的其它批次。后端执行端已支持按 base_id 校验、允许换批次，
但系统从不告诉他「还有哪些库位有货」—— 工人只能凭记忆或挨个翻。
后端：新增 GET /api/v1/outbound/alternatives
--------------------------------------------
入参 base_id（必填）、source_table/stock_id（可选，用于标注推荐行）
返回该物料全部可用库存行 + 合计可用量，推荐行置顶、其余按可用量降序。
为什么不复用 stock/list 或 bom-match-stock 的查询模式：
那两处按 stock_quantity > 0 过滤，会把「有货但已被别单全部预占」的库位
也列出来，工人跑过去才发现拿不到。实测库中有 14 行处于该状态。
本接口按 available_quantity > 0 过滤，只给真正能拿的库位。
前端：计划清单库位列加图标 + popover
------------------------------------
[推荐] Y1/2/1 可用 5 ← 本单锁定行（来自 items_json 的 stock_id）
[备选] Y2/3/4 可用 10
[备选] Z1/1/1 可用 2
三处取舍：
· trigger="click" 而非 hover —— 车间用扫码枪/触摸屏，hover 在触屏不可用
· @show 时才发请求 —— 计划清单可能几十行，渲染即请求会打出一片并发
· 附提示文案「现场取不到推荐库位时可直接扫备选库位条码出库」
注：历史单据的 items_json 无 stock_id，此时所有库位显示为「备选」
（不影响可用性，仅少了推荐标记）；预占改造后新提交的单可正确标注。
实测：造 3 批次 Y1/2/1(5) Y2/3/4(10) Z1/1/1(2)，预占首个后其 available=0，
接口正确排除该库位，返回两个备选、合计可用 12。
|
2026-09-10 14:59:17 +08:00 |
|
|
|
b57c21a4cd
|
feat(inventory): 库存预占生命周期，消除出库/借库超卖
问题：库存超卖
--------------
改造前出库/借库申请只记录「要什么、要多少」，不绑定具体库存行，
真正的 available_quantity 扣减发生在执行阶段。于是多张申请可以同时
claim 同一批货，等到工人拿扫码枪时才发现货已被别人领走。
生命周期（三阶段）
------------------
提交申请（预占） reserve_for_items()
用分配器把需求落到具体库存行，立即扣减 available_quantity，
并把 (stock_id, source_table, allocated_qty, reserved) 写回 items_json。
驳回（释放） release_reserved()
遍历 items_json 把预占量还回池子，避免货被永不执行的单永久占住。
扫码执行（覆盖） verify_scanned() + restore_then_deduct()
校验实扫身份/数量未超批准范围 → 释放全部预占 → 对实扫批次
同时扣减 available_quantity 与 stock_quantity。
身份键：base_id 主键 + SKU 兜底（重要设计决策）
-----------------------------------------------
本系统中 SKU 是**批次级**编号：同一 base_id 下每个入库批次各有不同的
SKU（实测 stock_buy 有 183 个物料是多批次的，如 base_id=2405 下有
0000001685 与 0000001974 两个 SKU）。
若以 SKU 作为身份主键，「申请时锁定 A 批、工人现场改扫 B 批」会被判为
身份不符而拒绝 —— 恰好否定了「物理覆盖」这个核心能力。
故改用 base_id（物料级、跨批次稳定，spec_model 由其唯一确定），
历史数据无 base_id 时降级为 (name, spec_model)。
可用量校验按物料汇总，而非按单批次
----------------------------------
开发中修正的一处缺陷：若逐行要求「该批次可用量 >= 该批次扫码量」，
工人改扫小批次时会被误拒。例如本单预占 A 批 5 件，改扫 B 批 2 件 +
C 批 3 件，B 批自身只有 2 件可用，逐行校验即失败。实际这 5 件都是本单
锁定的货，理应允许。现按物料汇总校验可用量，按行校验实物库存。
改动文件
--------
· 新增 app/services/inventory_reservation.py（通用服务层）
· outbound_service.create_request —— Phase 1 预占
· outbound_service.approve(reject) —— Phase 2 释放
· outbound_service.create_outbound_batch —— Phase 3 覆盖（移除原逐行扣减）
· borrow_service.submit_approval —— Phase 1
· borrow_service.approve(reject) —— Phase 2
· trans_service.execute_dispatch —— Phase 3，并用统一身份键替换
原有的 (name, spec_model) 字符串匹配
实测（真实 HTTP 全链路）
------------------------
初始 available=10
① 提交申请(需5) → 200，available 10→5 预占生效
② 审批通过 → available 仍为 5 预占保留
③ 扫码执行(改扫另一批次 4 件) → 200
原批次恢复满额、实扫批次扣减(0,0)，available=6, stock=6
单场景验证：预占 A 批改扫 B 批放行；驳回后可用量完全恢复；
扫其他物料被拒；批准 6 扫 8 被拒。
|
2026-09-10 14:59:10 +08:00 |
|
|
|
0a70e5688a
|
refactor(bom): 前端改为消费后端分配结果，删除本地分配与跨页数据污染
一、删除前端分配算法
Selection.vue 与 borrow/apply/index.vue 原先各自维护一套
rowsByBaseId 归并 + 跨行分配循环（近 80 行），现全部移除。
改为：构造 requirements → 调用 bomMatchStock → 直接 push 返回的 items。
二、缺料提示
后端返回 shortages 时，用 ElMessageBox.alert 逐项列出
「物料名：需 X，实配 Y，缺 Z」，替代原先笼统的「跳过 N 种缺货物料」。
全部满足则不弹窗，仅提示添加成功。
三、API 封装支持双签名（api/outbound.ts）
bomMatchStock(requirements | { requirements })
同时兼容旧的 bomMatchStock(childIds)，未改造的调用方不受影响。
四、清除 loadStockForBom（两个页面）
该方法会把 BOM 匹配结果整体写入 stockList.value，而 stockList 同时是
「手动选单弹窗」的数据源 —— 操作过 BOM 后再打开手动选单，看到的会是
BOM 匹配结果而非库存列表。BOM 流程不再触碰 stockList 后，该交叉污染
一并消除，方法随之删除。
注：借库选单页存在逐字相同的 .find() + Math.min 缺陷，本次一并修复，
使两个 BOM 入口行为一致。
SFC 编译通过；vue-tsc 无新增错误（残留 6 处告警为既有问题）。
|
2026-09-10 14:16:52 +08:00 |
|
|
|
a910a6ea72
|
feat(bom): 后端承接 BOM 库存分配，消除多批次物料只能加 1 件的缺陷
问题现象
--------
BOM 选单中物料显示需求 10、聚合可用 839，加入购物车却只剩 1 件，
并提示库存不足。
根因
----
两个接口口径不一致：
· GET /bom/stock/<bom_no> 按 base_id 聚合 → current_stock=839
· POST /outbound/bom-match-stock 不聚合，每批次一行 → 某行只有 1
前端用 stockList.find(s => s.base_id == child_id) 只取第一条库存行，
若首行恰好只剩 1 件，需求量又被 Math.min 压到 1，现象即如此。
为何必须放在后端
----------------
前端 stockList 由多个入口写入（手动选单/搜索/BOM），随时可能被覆盖；
且 base_id 与 stock_id 的类型差异会让匹配静默落空，表现同样是「库存不足」。
更关键的是：分配需要「该 base_id 全部可用库存行」的完整视图，
而这必须与出库扣减（create_outbound_batch 按 stock_id 逐行加锁扣减）
使用同一份数据源。
改动
----
bom-match-stock 新增分配模式：
请求 { requirements: [{base_id, required_qty, name, spec_model}] }
响应 { items: [...已分配行], shortages: [...缺料明细] }
_allocate_bom_requirements() 在 DB 层完成：
1. 三张库存表按 base_id 一次性取全部 available_quantity > 0 的行
（带公司隔离，join base 取名称规格）；
2. 可用量降序排序 —— 优先进大行，减少购物车拆分行数；
3. 逐物料扣减 required_qty，产出真实 stock_id + source_table + allocated_qty；
4. 分配不足记录 shortage 但不阻断其它物料。
每行仍携带 uniqueKey，前端可直接入购物车。
返回前剥离价格成本字段（Fail-Closed）。
旧查询模式（child_ids）保留，兼容未改造的调用方。
顺带修复一处静默失败
--------------------
查询块的 except 原为直接 continue，会把 NameError 等错误吞成「该物料无库存」。
改为 logger.error 输出，避免同类问题再次以业务结论的形式出现。
实测（base_id=2405，聚合 841，需 10）：分配 1 行 stock_id=1961 分配 10，无短缺；
base_id=2963（9 行各 1），需 5 → 5 行各 1 合计 5；
需 20（聚合仅 9）→ 9 行合计 9，短缺 11。
|
2026-09-10 14:16:47 +08:00 |
|
|
|
6068625562
|
feat(audit): 审计日志业务化——对象名与字段中文化、操作来源与类型筛选
一、target_name 业务化（后端 audit_listener.py）
优先级：业务标识（request_no/outbound_no/borrow_no/sku/bom_no…）→
名称字段 → 关联物料名 → 「中文表名 - 业务号或ID」。
新增 TABLE_LABELS 表名到中文的映射（18 张白名单表全覆盖）。
用户看到的从 scrap_approval ID:371 变为
「出库申请单 - APR-OUT-20260805-1550-0005」这类可理解的对象描述。
二、前端字段中文化（AuditLog.vue）
· fieldMap 由 11 项扩充到 110+ 项，覆盖审批单/流水/库存/主数据/系统管理五类；
· 修复关键 bug：fieldMap 原先只作用于「变更对比」区，「删除快照」与
「新增详情」两区直接渲染原始 key（label 直接取 String(key)），
这正是详情里满是英文列名的直接原因。现三区统一经 fieldLabel() 取值。
三、时间显示修正
后端已改写北京时间，前端原先补 Z 当 UTC 解析会造成二次 +8 小时，
改为按 +08:00 理解该字符串。
四、新增两类筛选
· 操作来源（真实用户 / 系统操作 / 全部），默认「真实用户」。
历史存量含约 1.8 万条 username=system 的噪声日志，会把列表刷屏。
· 操作类型别名归一：历史数据中 action 有两套写法（早期装饰器写中文
新增/修改/删除，现行监听器写大写 CREATE/UPDATE/DELETE），导致下拉
同时出现二者、且选中文项只能搜到 3-4 月的老数据。现 ACTION_ALIASES
把任意写法归一化后展开匹配，下拉只暴露 3 个规范值，
历史数据无需迁移即可被正确检索。
|
2026-09-10 14:16:39 +08:00 |
|
|
|
4808a48594
|
refactor(audit): 审计架构清理——复活白名单监听器、停用噪声监听器、清除僵尸装饰器
一、统一为单一监听器实现
原先两套 SQLAlchemy 事件监听器并存：
· app/utils/audit_events.py —— 全局监听 db.Model、无白名单、无请求上下文守卫（实际在跑）
· app/core/audit_listener.py —— 白名单制、有守卫、有模型级开关（从未生效）
后者失效的根因：注册代码写在 extensions.py 的 init_extensions() 内，
而该函数全仓库只有定义、没有任何调用（create_app 直接内联调用 db.init_app 等）。
现统一由 app/core/audit_listener.py 承担，并在 create_app() 中显式注册。
extensions.py 的死函数 init_extensions 整体删除，避免后人误以为它是有效入口。
二、修复监听器三处致命缺陷（此前注册了也写不进数据）
1. 事件回调第二个参数是 Connection，原代码却调用 Connection.add()（不存在），
每次写日志都抛 AttributeError 并被 except 吞掉 → 改为 connection.execute()
2. register_audit_listeners 从 app.models 批量 import 多个未导出的模型，
ImportError 被上层 try/except 吞掉 → 改为按表名从 db.metadata 取模型
3. 本项目有 31 处函数体内延迟导入模型（如 scrap.py 内部才 import ScrapApproval），
一次性注册会静默漏表 → 增加 ensure_audit_listeners() 惰性补绑，
并在模型预加载段补全审批单/BOM/采购等模型
三、强约束
· WHITELIST_TABLES：仅 18 张核心业务表，系统表/草稿表/向量表不再自审
· has_request_context() 守卫：系统初始化与后台定时任务不再产生 username=system 噪声
· IGNORE_FIELDS 增加 password/password_hash/salt/token/secret/api_key（安全红线）
· created_at 显式写 beijing_time()，与全系统时间口径一致
四、清除僵尸装饰器
@audit_log 早已退化为直接透传的空壳（module/action 参数全被忽略，
数据库中零星的中文 action 即其历史遗留产物），却仍挂在 38 处路由上。
连同 13 个文件的 import 一并移除；audit_events.register_audit_events 改为空操作。
验证：应用上下文中的写操作不产生日志；HTTP 请求产生 5 条日志，
对象为业务单号（APR-SCRAP-... / SKU），模块中文，操作人真实，时间为北京时间。
|
2026-09-10 14:16:27 +08:00 |
|
|
|
1ef9ae4ad9
|
feat(records): 报废记录接入高级筛选
复用 app/utils/advanced_filter.py，但报废有两处与出库/借还不同，需特殊处理：
一、scrap_request_no 可为 NULL（历史直接报废）
出库/借还可直接对单号列做 IN，报废不行——「单号 IN」永远匹配不上 NULL 行，
会把历史单整体漏掉。此处统一用「行级等价键」表达同单关系：
有单号 → scrap_request_no 相等
无单号 → 同一分钟(date_trunc) + 同一操作人（与 Python 侧分组逻辑完全一致）
二、物料名不能用单号传递结果
物料名需三表联查，但联查结果若用「单号 IN」回接，同样会漏掉 NULL 单号行。
改用 tuple_(source_table, stock_id).in_(pairs) 元组定位报废行。
三、否定操作符
命中行 → 折算同单等价键谓词 → 否定时整体取反（~pred），实现整单排除。
前端 scrap/index.vue 新增「高级筛选」el-popover，与出库/借还版式一致。
验证（库中当前唯一报废单含 SKU 0000000272）：
sku contains 0000000272 → 1 单
sku ne 0000000272 → 0 单（整单排除，符合预期）
material_name not_contains 白板 → 0 单（该单物料名含白板，被排除）
单号 ne（父级） → 1 单（父级否定语义不变）
|
2026-09-10 13:06:07 +08:00 |
|
|
|
fd0bfd3d9c
|
feat(records): 借还记录接入高级筛选
复用 app/utils/advanced_filter.py 的解析与谓词逻辑：
· 父级字段（单号 borrow_no、借用人 borrower_name）走标准 SQL 谓词
· 子级字段（SKU、物料名称）经单号子查询过滤，否定操作符走 NOT IN 整单排除
· 物料名经三表联查（buy/semi/product JOIN material_base）
借还的单号维度查询基于 order_subq 子查询分页，故此处把过滤条件施加在
order_subq.c.borrow_no 上，与既有的状态/日期/公司隔离过滤保持同一层次。
前端 records.vue 新增「高级筛选」el-popover（字段/操作符/值 + 添加条件/
应用筛选/重置），序列化为 advancedFilters JSON 字符串随查询下发。
验证：sku ne 0000000002 → 52 单（库中无单含该 SKU，正确不减）；
sku contains 0000 → 52 单（52 单的 SKU 全部含 0000，数据巧合）。
|
2026-09-10 13:06:03 +08:00 |
|
|
|
e437b3cece
|
feat(records): 高级筛选引擎 + 出库记录接入
一、新增共享工具 app/utils/advanced_filter.py
系统内已有该模式（material/list.vue、stock/inbound/buy.vue），
沿用其既有约定：参数名 advancedFilters、值为 JSON 字符串、
操作符 eq/ne/contains/not_contains/ge/le。
· parse_advanced_filters() 解析并规整，坏输入退化为空列表不影响主查询
· build_predicate() 单条件 → SQLAlchemy 谓词，未登记字段返回 None 杜绝列注入
· build_material_name_select() 物料名三表联查（buy/semi/product JOIN material_base）
二、★ 父子关系处理（本次核心）
记录接口返回的是**按单号分组的订单**，而用户筛选字段多落在**明细行**上。
若直接 .filter(TransOutbound.sku.ilike(...))，会在 GROUP BY 前收窄明细范围，
展开行里的兄弟明细会凭空消失。正确做法是先求「含匹配明细的单号集合」
再让主查询按单号 IN 过滤。
实测对照（单 OUT-20260811-1519-0003，21 条明细）：
按其中一条 SKU 筛选 → 子查询法保住全部 21 条；直接 filter 只剩 1 条。
三、★ 否定操作符语义（NOT IN）
子级字段的 ne / not_contains 不能直接用 SQL != / NOT LIKE —— 那表达的是
「本单存在某条不等于 X 的明细」，多明细单几乎必然成立，等于筛选失效。
用户意图是**整单排除**，故 apply_child_condition() 统一：
肯定 → order_no IN (含匹配明细的单号)
否定 → order_no NOT IN (含匹配明细的单号)
两者子查询完全一致（都用肯定形式谓词），仅外层取反。
父级字段（单号/操作人）仍走标准 SQL 谓词，语义无歧义。
四、出库记录接入（前端弹窗 + 后端接线）
验证：
eq 0000000002 → 1 单；material_name contains 白板 → 16 单
sku ne 0000000002 → 394 = 395-1，含该 SKU 的单被整体排除
material_name not_contains 白板 → 379 = 395-16
|
2026-09-10 13:05:59 +08:00 |
|
|
|
c35ec9a659
|
feat(records): 出库/借还记录统一高级搜索版式
三个记录页（出库/借还/报废）此前搜索区形态各异：出库用裸 div + 分散样式，
借还缺日期范围，报废只有 SKU 输入框。现统一为 el-form :inline="true" +
.filter-form 版式，并补齐缺失的过滤维度。
借还记录（新增日期范围能力）：
· 后端 get_records 增加 start_date/end_date 参数，按「借出时间」过滤；
· 边界补全时分秒（YYYY-MM-DD → 当日 00:00:00 / 23:59:59），
与出库记录同口径，解决零点截断导致当天记录漏查的问题；
· API 层透传两个新参数。
出库记录：
· 版式统一为 inline 表单，日期选择器加 label；
· 新增「重置」按钮；
· 搜索类型切换由 500ms 防抖改为立即查询。
借还记录：
· 新增「重置」按钮；搜索类型/状态切换改为立即查询（取消防抖）。
实测（SUPER_ADMIN）：
报废 全部/单号/SKU/操作人/物料名/日期 六类过滤均 200 且命中正确；
借还 无过滤 52 单 / 本月 18 单 / 空区间 0 单（日期过滤生效）；
出库 无过滤 395 单 / SKU 277 / 姓名 7 / 物料名 16 / 单号 OUT-2026 命中 395。
|
2026-09-10 12:06:08 +08:00 |
|
|
|
23a7fc65f1
|
feat(scrap): 报废记录按单号分组 + 可展开明细 + 高级搜索
一、后端按「订单」分组（原为平铺明细列表）
有 scrap_request_no → 按单号分组；
无单号（历史直接报废）→ 按 操作时间(精确到分钟) + 操作人 虚拟分组，
生成 LEGACY-<yyyyMMddHHmm>-<操作人> 形式的虚拟单号，避免历史数据成为无主记录。
每单返回 items 明细数组、损失合计、报废总数、申请人（取自 ScrapApproval）。
二、物料解析改为批量预加载
原实现逐条记录 N+1 查询，且 5 条来源路径（stock_buy/semi/product、
trans_borrow、trans_repair）各自 query.get()。改为按 (source_table, stock_id)
收集 ID → 批量 joinedload 查询 → 内存拼装。
三、损失金额改为按权限可见
原 /records 无条件剥离 total_loss，导致持有 scrap_list:loss_amount 的角色
也看不到金额，与权限元素的存在相矛盾。改为对齐 outbound 的
filter_item_by_permissions：无权限置 None，前端 v-if 隐藏整列。
四、新增 keyword / search_type 高级搜索参数
（单号/SKU 在 SQL 层过滤，操作人/申请人/物料名在分组后过滤）
五、修复申请人显示
ScrapApproval._user_name() 返回 '杜邢宸/duxingchen' 全名，统一经
_display_name() 去掉 '/账号' 后缀。
前端 scrap/index.vue 重写为 el-table type=expand 嵌套表格，对齐出库记录版式，
搜索区改用统一 el-form inline 版式（含重置按钮）。
实测：3 单（1 张申请单 2 明细 + 1 组 legacy 合并 2 条），申请人/损失合计/
虚拟单号均正确。
|
2026-09-10 12:06:04 +08:00 |
|
|
|
3cadd42338
|
refactor(scrap): 报废管理子菜单按业务流排序
顺序调整为：报废申请 → 按单报废 → 报废记录 → 报废审批。
侧边栏由 layout/components/Sidebar/index.vue 的 v-for="child in
route.children" 直接按路由数组顺序渲染，无排序逻辑，故仅需调整数组元素。
原「按单报废执行」标题缩短为「按单报废」（四字，与同级菜单一致）。
注：父菜单 redirect 仍指向 /scrap/index（报废记录），与出库模块
redirect 指向「出库记录」的既有惯例保持一致，未改动。
|
2026-09-10 11:33:01 +08:00 |
|
|
|
1aa31334b1
|
fix(scrap): 报废申请页搜索/选择解耦，审批人常驻必填
一、搜索丢失已选（核心 bug）
主表格 :data="stockList" 同时充当搜索结果与选择容器。Element Plus 的
setData 在 reserveSelection 为假时走 clearSelection()，进而 emit
selection-change([])，故每次重新搜索都会清空选中态、「已选 N 条」归零。
（源码路径：table/src/store/index.mjs:34-52 → store/watcher.mjs:145-152）
改为「购物车 + 选择弹窗」结构，对齐出库选单页：
· 主表格数据源改为 cart（已选清单），删除复选列，改「移除」按钮；
· 新增「选择库存物品」弹窗，搜索框移入其中；
· 表格 row-key + :reserve-selection="true"，跨搜索/翻页保留勾选；
· 点行勾选、改数量自动勾选、数字框 @click.stop 防冒泡反转勾选；
· 服务端搜索（350ms 防抖）+ 分页 20/50/100/200；
· uniqueKey 取 source_table_id（三表主键各自独立，必须带表名前缀）。
二、审批人字段不显示
原为 v-if="approvalVisible"，仅库管代建或命中需审批物料时才渲染。
因全库仅 1 个物料标记 is_approval_required，该条件几乎从不成立。
现改为常驻，并用 el-form rules 声明 approver_id / remark 双必填；
打开弹窗即调用 checkScrapApproval 预检并展示提示文案。
三、顺带修复
库位列此前恒为空：三张库存表 to_dict 只输出 warehouse_loc，而模板绑定
warehouse_location。已在 loadStockList 中归一化。
SFC 编译与 vue-tsc 通过，无新增类型错误。
|
2026-09-10 11:32:56 +08:00 |
|
|
|
e152f16ebc
|
feat(scrap): 报废一律需审批，不再按物料标记区分
业务规则变更：所有报废申请都必须由指定审批人审批通过后才能执行。
原逻辑走 resolve_approval_control 判定是否需审批，而 material_base 表中
仅 1/3012 个物料标记了 is_approval_required，意味着 99.97% 的报废申请会
走免审批分支——status 直接置 1、actual_approver_id 被赋为申请人自己、
审批人参数被静默丢弃。前端即便做了必填也只是摆设。
改动（规则收敛到单一来源）：
· 新增 SCRAP_ALWAYS_REQUIRES_APPROVAL = True，作为唯一开关；
· submit_approval() 无审批人一律拒绝；恒置 status=0（待审批）；
删除免审批自动通过分支；
· resolve_approval_control 仍调用，但仅用于生成提示文案，
不再参与是否审批的判定；
· /request/check-approval 返回 need_approval=SCRAP_ALWAYS_REQUIRES_APPROVAL，
否则该接口会继续返回 false，导致前端预检结果失真。
实测：不传审批人 → 拒绝；传审批人 → status=0 且 actual_approver_id 为空。
⚠ 注意：此前自动通过的单据今后一律进入审批队列。
|
2026-09-10 11:32:51 +08:00 |
|
|
|
f589962e5c
|
feat(scrap): 新增报废专用库存查询端点，解耦出库选单权限
报废申请页原复用 /inbound/stock/list，该端点权限是 outbound_selection。
持有 scrap_apply 的角色目前恰好也都持有该权限，故能跑通，但属隐性耦合：
任一角色授权脱钩就会静默 403，被前端 catch 掩盖成「加载库存失败」。
照抄借库既有先例（transactions.py 的 /borrow/stock-list），新增：
GET /v1/scrap/stock-list @permission_required('scrap_apply')
★ 同步把 'scrap_apply' 登记进 stock.py 的 SELECTION_PREFIXES。
_make_price_stripper 仅当前缀为 None 或已在集合中时才剥离价格，
漏登记会导致价格/成本字段泄露给报废申请人（Fail-Closed 失效）。
实测：OUTBOUND/WAREHOUSE_MGR 均 200，无 token 401，
响应中 unit_price/total_price/sale_price 等价格字段零泄漏。
|
2026-09-10 11:32:44 +08:00 |
|
|
|
f556514e72
|
refactor(scrap): 扫码校验改用 SKU 主键，与后端同口径
前端 validateAgainstPlan 由 (source_table, stock_id) 改为 SKU 主键：
· normSku() 去首尾空白，与后端 _norm_sku 一致；
· matchKey() 与后端 _match_key 完全同构（sku: 前缀 / row: 回退）；
· approvedQtyByKey() 聚合同一 SKU 的批准总量，兼容批准单同 SKU 多行；
· 扫码不在批准明细内、或该 SKU 累计量超批准量时，红色 toast + 震动阻断，
不入购物车；
· 购物车去重与 maxScrapFor 上限同步改为按 SKU 计算。
已通过 SFC 编译与 vue-tsc（无新增类型错误）。
|
2026-09-10 10:21:53 +08:00 |
|
|
|
ed351f96ec
|
refactor(scrap): 按单执行校验改用 SKU 主键匹配
架构要求以 SKU 为唯一校验键，原实现按 (source_table, stock_id) 匹配。
已核验数据前提：SKU 在同一库存表内唯一（0 重复），且不存在跨表重名
（stock_buy / stock_semi / stock_product 交叉 0 冲突），故 SKU 可安全
作为跨来源标识。
改动：
· 新增 _match_key()：SKU 非空时以 'sku:<SKU>' 为键；个别历史库存行
SKU 为空，回退 'row:<table>#<id>'，前缀区分确保绝不串键；
· _build_approved_index() 按 SKU 聚合，累加批准量并保留各行的
source_table + stock_id（rows 列表）；
· 校验拆为两步并给出明确文案：SKU 是否在批准明细内、同 SKU 累计量
是否超批准量；
· ★ 扣减改为按批准单配对的 source_table + stock_id 定位库存行加锁，
不再信任前端传来的 stock_id —— 实测前端传伪造 stock_id=99999 时，
仍从批准单指定的库存行扣减，台账同样记录批准单的 stock_id；
· 同一 SKU 在批准单占多行时，按批准顺序依次分配扣减量。
实测 7 项校验用例 + 多行分配 / 批准行已删除 / 可用不足 均符合预期。
|
2026-09-10 10:21:50 +08:00 |
|
|
|
af2d1c10c6
|
feat(scrap): 报废作业页重构为「按单扫码执行」，对齐出库版式
create.vue 由「直接报废」页（492 行）重写为按单执行页：
· 顶部选择已批准申请单（scope=executable, status=1）；
· 载入 items_json 为待执行清单，逐项显示批准数量与已扫数量；
· 扫码头按 (source_table, stock_id) 匹配批准明细，
不在单内或超批准量时红色 toast + 震动阻断，禁止入车；
· 支持 ?requestId= 深链直达；提交实扫 payload 到 execute 接口。
审批页的「执行报废」由弹窗盲执行改为跳转本页（router.push + query.requestId），
移除 executeVisible/confirmExecute 等已失效代码；路由标题改为「按单报废执行」。
executeScrapByRequest 增加 items 参数。
|
2026-09-10 10:14:43 +08:00 |
|
|
|
7719943779
|
feat(scrap): 报废执行改为按单扫码校验，废弃盲执行
execute() 原先只吃 request_id，按申请单快照全量扣减，用户反馈「扫码与报废脱节」。
现改为接收实扫明细 scanned_items：
· 强制按单：未提交实扫明细一律拒绝执行；
· 键为 (source_table, stock_id)，与申请单 items_json 同口径，
同一物品多次扫码自动累加，兼容「逐件扫」与「输数量」两种操作；
· 校验实扫项必须落在批准明细内，且累计量不得超批准量，否则整单拒绝；
· 允许合法子集（少扫 = 本次不报废该行）；
· 扣减以实扫量为准，同时扣 available_quantity 与 stock_quantity
（报废即实物销毁，上一版只扣可用库存会让总库存虚挂）。
接口 POST /scrap/request/<id>/execute 由无 body 改为接收 {items:[...]}。
|
2026-09-10 10:14:40 +08:00 |
|
|
|
b4b79c68a9
|
fix(borrow): 借库转报废实物不足时报错回滚，不再夹断到 0
原逻辑在 stock_quantity 减为负数时直接置 0。但借出时已扣减过
available_quantity，夹断会使 available_quantity > stock_quantity，
凭空多出可用库存，后续出库/借库可继续占用这批并不存在的实物。
改为不足即抛 ValueError，与同一事务内其余校验一致，整单回滚。
|
2026-09-10 10:14:36 +08:00 |
|
|
|
8755837fe8
|
fix(timezone): 审批单据时间统一为 naive 北京时间，消除 8 小时偏差
成因：approved_at / executed_at 列是 timestamp without time zone，而赋值用了
带时区的 datetime.now(timezone(timedelta(hours=8)))。psycopg2 对 naive 列不会
剥掉 tzinfo，而是转成 naive UTC 再写入，结果比同为北京时间的 created_at 早 8 小时。
（代码里并无 datetime.utcnow()，真实成因是 aware 值被驱动的隐式 UTC 转换。）
改动：
· outbound_service / borrow_service 的审批分支
datetime.now(beijing_tz).replace(tzinfo=None) → beijing_time()
（免审批分支已在上一轮改为 beijing_time，此处补齐审批分支）；
· purchase_service 审批/完结分支同源缺陷一并修复；
· scrap_approval / scrap_approval_service 的 _beijing()、_beijing_now() 由
tz-aware 改为 naive —— 配合上述迁移把列类型改为 naive，
若仍返回 aware 值，timestamptz→timestamp 后会反向早 8 小时。
实测四表（scrap/outbound/borrow/purchase）created_at 与 approved_at 差值
均在同一秒内（-1ms ~ -12ms）。
|
2026-09-10 10:14:31 +08:00 |
|
|
|
2045a89330
|
feat(db): 审批单据时间口径统一 + 补注册 scrap_selection 权限
unify_approval_timezone.sql：
· scrap_approval 的 4 个时间列由 timestamptz 改为 timestamp without time zone，
与 outbound/borrow 对齐（该表当时无业务数据，转换零损失）；
· 三张审批表 created_at/updated_at 的 DB 默认值由 UTC 的 now()/CURRENT_TIMESTAMP
统一为 timezone('Asia/Shanghai', now())，杜绝绕过 ORM 的写入偏 8 小时。
add_scrap_selection_perm.sql：
GET /scrap/scan 一直声明需要 scrap_selection，但该权限码从未写入
sys_element / sys_role_permission，精确匹配与前缀展开匹配全部落空，
导致除 SUPER_ADMIN 外没有任何角色能调用扫码接口。现补注册，
并授予所有已持有 scrap_execute（按单报废执行）的角色。
|
2026-09-10 10:14:19 +08:00 |
|
