515 Commits

Author	SHA1	Message	Date
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	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
yueli	b4b79c68a9	fix(borrow): 借库转报废实物不足时报错回滚，不再夹断到 0 ... 原逻辑在 stock_quantity 减为负数时直接置 0。但借出时已扣减过 available_quantity，夹断会使 available_quantity > stock_quantity， 凭空多出可用库存，后续出库/借库可继续占用这批并不存在的实物。 改为不足即抛 ValueError，与同一事务内其余校验一致，整单回滚。	2026-09-10 10:14:36 +08:00
yueli	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
yueli	8b61cdb67d	fix(approval): 需审批判定改为 base_id → SKU → 名称+规格 三级降级 ... 原判定仅有 base_id 与「名称+规格字符串」两级，出库申请明细只有 name/spec、 无 base_id，只能走脆弱的字符串匹配，同名或同规格不同料极易误判。 新增 SKU 优先级：material_base 表本身没有 sku 列，SKU 只存在于 stock_buy / stock_semi / stock_product，故经明细自带 source_table 反查 sku → base_id 再回查物料，查不到才依次降级其余两张库存表。 查到物料即定论，不再往下走字符串兜底，杜绝误杀。	2026-09-10 10:14:17 +08:00
yueli	98e657e289	fix(scrap): TransScrap 补 scrap_request_no 列映射 ... 报废执行写台账时以关键字传入 scrap_request_no，但该列只存在于 DB （db_migrations/add_scrap_approval.sql）而未在 ORM 声明，执行报废必然抛 TypeError: 'scrap_request_no' is an invalid keyword argument for TransScrap， 被 500 捕获后连同库存扣减一起回滚，整条按单报废链路不可用。	2026-09-10 10:14:14 +08:00
yueli	1dbf74b7bc	feat(borrow): 借库审批补「完结」能力（对齐出库 status=4） ... - mark_completed 改为 1→4 已完结（真正扫码借出完成仍为 status=3） - 前端审批页新增「已完结」筛选项与状态映射；审批信息列对 3/4 显示审批人	2026-09-10 09:47:07 +08:00
yueli	ffbb2199f0	feat(scrap): 报废申请审批流 + 按单报废（后端） ... - ScrapApproval 模型 + ScrapApprovalService：提交/列表/审批/执行(锁库存扣 available_quantity 写 TransScrap) - 新路由 POST /scrap/request、/request/check-approval、GET /request、PATCH /request/<id>/approve、POST /request/<id>/execute；权限码 scrap_apply/scrap_approval/scrap_execute（无角色硬编码） - 旧 /scrap 直接报废入口保持不变 - /inbound/stock/list 每项返回 source_table，供按单流程精准选库存	2026-09-10 09:46:57 +08:00
yueli	044e6dbd98	feat(borrow,outbound): 库管(WAREHOUSE_MGR)代建申请强制审批 ... - submit/create 新增 force_approval：库管建单无视物料是否需审批，一律走审批 - 路由按当前角色为 WAREHOUSE_MGR 传 true；未选审批人返回明确业务错误	2026-09-09 16:19:38 +08:00
yueli	cd600f9fc2	fix(auth): 审批人列表按公司收窄——本公司主管 + 所有超管 ... - get_approvers：普通/主管仅见 department=本人公司 的 SUPERVISOR 与全部 SUPER_ADMIN；超管本人不受限	2026-09-09 15:23:51 +08:00
yueli	2a9e2e4560	fix(bom): BOM 三态互斥 + active_only排除归档 + 详情主备注 ... - get_bom_list active_only 补 is_archived==False，出库/借库“按BOM套餐”不再泄漏归档版本 - get_bom_detail 返回顶层 remark，详情弹窗主备注可回显 - 状态互斥：update_enabled 切启/停即清归档；update_archived 归档→废弃(enabled=False)、取消归档→启用；停用视图排除归档	2026-09-09 13:00:41 +08:00
yueli	eff9b62224	fix(borrow,outbound): 普通用户记录只看本人——按领用人/借用人姓名(不含账号前缀)匹配 ... - 出库记录/借还记录：非管理者视角时按 领用人(consumer_name)/借用人(borrower_name) 过滤 - 匹配取登录名 username.split(/)[0] 的姓名；兼容库里存“姓名/xiaolongxia”全名(姓名+/前缀) - 修复：管理员替员工创建、领用人=员工 的单，员工登录可见	2026-09-09 11:19:15 +08:00
yueli	67d3113fe1	fix(permission): 记录管理者视角仅超管/主管/仓库管理员，去掉入库员/出库员 ... - PRIVILEGED_VIEWER_ROLES 收敛为 SUPER_ADMIN/SUPERVISOR/WAREHOUSE_MGR - 入库员(INBOUND)、出库员(OUTBOUND)按普通处理：借还/出库记录只看自己	2026-09-09 11:19:09 +08:00
yueli	aa9322bcbc	feat(borrow): 借库申请后端必填校验——申请原因、预计归还日期(长期借用除外) ... - submit_approval 校验：申请原因非空；未勾长期借用时必须有 expected_return_time，否则 ValueError 拦截	2026-09-09 10:53:12 +08:00
yueli	4146f35010	feat(permission): “出库/借库需审批”开关权限化——仅主管/超管可见可改 ... - 新增权限码 material_list:isApprovalRequired，授予仅 SUPER_ADMIN/SUPERVISOR（收回其它角色） - 物料列表该列仅持码角色可见；后端批量端点与字段脱敏均改按新码校验，其余角色看不到值也无法改	2026-09-09 10:47:36 +08:00
yueli	6bdc8a82f2	feat(borrow,outbound): 申请预检按需显示审批人——默认不显示，命中需审批才出现并必选 ... - 后端新增 /borrow/request/check-approval 与 /outbound/request/check-approval 预检接口 - 申请弹窗默认隐藏审批人；提交前预检：命中需审批→显示审批人并红字列物料、未选拦截；未命中→隐藏并直接提交(approver=null) - 申请 items 补传 base_id 供后端 ID 精确判定	2026-09-09 10:47:29 +08:00
yueli	d06ce45a72	feat(borrow,outbound): 需审批判定收敛——ID优先 + 名称精确AND核心规格(斜杠前段) ... - approval_control 重写：带 base_id 按主键绝对判定；无 id 才名称100%一致 AND 核心规格(_code_of)一致兜底，杜绝同名不同规误杀 - 借/出库服务命中需审批但未选审批人时，报错列出需审批物料名/规格	2026-09-09 10:47:24 +08:00
yueli	4cd3eefdf4	feat(borrow,outbound): 默认免审批改造——命中物料需审批才走原流程 ... - models/base.py 加 is_approval_required 列及 isApprovalRequired 序列化；field_permissions 登记 - 新增 POST /inbound/base/batch-approval（批量设需审批，仿批量质检） - borrow_service.submit_approval / outbound_service.create_request：明细含需审批物料→须选审批人走原审批；否则创建即 status=1(待库管执行)、不发审批邮件 - 判定按 (name,spec_model) 反查启用物料	2026-09-09 09:31:18 +08:00
yueli	9622baf76e	fix(borrow,outbound): 记录查看按角色收窄——普通只看自己，库管/主管/超管/跨域看全部 ... - decorators 新增 is_privileged_viewer（SUPER_ADMIN/SUPERVISOR/WAREHOUSE_MGR 或 crossDomain） - 借库记录列表：非管理者强制 applicant_id=当前用户 - 出库记录列表+详情：非管理者强制只看自己/无权访问他人单(403)	2026-09-09 09:31:01 +08:00
yueli	2b0e335790	fix(inbound/buy): 批号自增改为按物料精准取最近一条 ... - 新增 get_latest_batch_record_by_base_id：SQL 直接 filter(base_id)+order by in_date/id desc first()，O(1) 不分页 - 新增 GET /inbound/buy/latest-record - 修复原“拉全表前1000条再前端过滤”导致的历史被截断→批号退回000001/重复入库被拦（如 CCAB0029）	2026-09-08 18:16:04 +08:00
yueli	66b3e4897f	fix(bom): get_bom_summary 关键词与 list 对齐 + 状态更新方法健壮化 ... - get_bom_summary 关键词过滤改为与 get_bom_list 同款子查询（同时匹配 bom_no、父件名/规格、子件名/规格），任意关键词下 summary 计数与 list 明细严格一致，消除“标题有数、表格为空” - update_enabled/update_archived 对 bom_no/version 做 strip 规范化，并细化“BOM不存在”报错（带上实际参数便于排查）	2026-09-08 13:58:43 +08:00
yueli	02f74278df	feat(bom): 归档业务闭环——状态筛选+归档/取消归档入口 ... - get_bom_list/get_bom_summary 状态过滤支持 archived，enabled 语义改为“启用且未归档” - get_bom_list 输出补 is_archived；新增 update_archived 与 POST /bom/archive（整组切换归档、清缓存、审计） - “未指定版本自动取最新”硬化为仅认启用且未归档（get_bom_detail / get_bom_no_by_parent） - 前端：状态按钮组加“归档”；列表状态列区分归档；操作列加“归档/取消归档”按钮	2026-09-08 11:13:38 +08:00
yueli	91fb6c1a03	feat(bom): 自制件子件选版本落库/强校验 + 独立启停 + 状态筛选 ... - save_bom 落库 child_bom_no/child_bom_version；自制件必选且须属于启用未归档配方集，外购件置空；跨版本查重纳入引用版本 - get_bom_detail 改为读存储列，空则回退最新启用配方；候选/校验/回退读取均排除 is_archived - 新增 GET /bom/self-bom-versions（子件候选版本）；新增 POST /bom/status 独立启停（update_enabled 清缓存） - 草稿链路 save_draft/get_draft_detail/publish 持久化引用版本 - get_bom_list/get_bom_summary 支持 status(enabled/disabled) 过滤	2026-09-08 10:14:44 +08:00
yueli	3dd8458de0	feat: BOM 子件展示自制件 BOM 版本号——子件列表与出库/借库 BOM 清单打印均显示	2026-09-07 18:01:16 +08:00
yueli	220f73acbd	feat: 首页全局搜索支持按 SKU 查库位——采购/半成品/成品库存纳入搜索并显示库位	2026-09-07 15:47:25 +08:00
yueli	478b90fe50	feat: 出库类型贯穿申请→扫码出库——申请单加 outbound_type，申请时选类型、扫码出库自动带出	2026-09-07 14:01:13 +08:00
yueli	73510d3a71	feat: 借还记录默认排序重构——有限期单按预计归还时间升序靠前，无限期单按借出时间升序靠后（优先关注快到期/逾期）	2026-09-04 16:17:42 +08:00
yueli	b274ed1ed1	feat: TransBorrow 归还人 to_dict 自动把数字 user id 映射为用户名（历史记录不再显示数字，lru_cache 防 N+1）	2026-09-04 16:12:36 +08:00
yueli	02f36b383c	fix: 借库归还/报废/借库执行操作人由 JWT 数字 ID 改为用户名（归还人不再显示数字）	2026-09-04 16:10:00 +08:00
yueli	808e491fe8	fix: BOM 匹配库存(bom_match_stock)加行级公司隔离（三表按 base 公司过滤，超管/跨域不受限）	2026-09-04 15:57:14 +08:00