duxingchen/KCGL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
927 Commits 5 Branches 0 Tags
a910a6ea72162f132224925a83f2644cf80a86f1
Commit Graph

927 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
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
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
yueli
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
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
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
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
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
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
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
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
da5357acb3 feat(scrap): 前端报废申请 / 报废审批页 + API（对齐出库版式） 
- api/scrap.ts 新增 submitScrapRequest/checkScrapApproval/getScrapApprovals/approveScrapRequest/executeScrapByRequest
- apply: 选库存(带 source_table+stock_id)/报废数量/原因/按需审批人提交
- approval: 顶部审批状态筛选+刷新、展开明细、列名对齐出库、分页含 sizes、按单执行弹窗
- 路由挂载 /scrap/apply、/scrap/approval
 2026-09-10 09:47:02 +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
3d8fb198c5 feat(scrap): 报废审批流 DB 迁移（建表 + 权限码） 
- scrap_approval 表（申请单，items_json 携带 source_table+stock_id 精准实物）
- trans_scrap 增加 scrap_request_no 关联申请单
- 注册权限码 scrap_apply / scrap_approval / scrap_execute 并按现有报废角色授予
 2026-09-10 09:46:52 +08:00
yueli
a12fcea86d fix(borrow,outbound): 库管弹窗必显审批人 + HTTP400去重toast 
- 审批人 el-form-item 显隐加入 role==WAREHOUSE_MGR 判断
- 提交 catch 仅对无响应(网络)弹错，HTTP错误由全局拦截器按后端 data.msg 弹一次，避免重复
 2026-09-09 16:19:45 +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
815ad01a5b V3.74,9.9推送 2026-09-09 13:19:49 +08:00
yueli
ffbf4689f1 fix(inbound/buy): 从采购申请导入时价格不受“是否可显示价格”权限拦截 
- 价格填充不再包在 hasFormFieldPermission(unit_price) 里，库管(前端不显示价格)也能把采购单价格带入隐藏字段用于成本
- 前端价格列/输入框仍按字段权限对库管隐藏
 2026-09-09 13:10:46 +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
c8cf2bd52b feat(db): BOM 三态互斥存量归一——归档(废弃)自动停用 
- 将历史“归档且仍启用(True/True)”的行归一为 归档且停用(True/False)
 2026-09-09 13:00:35 +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
e622697d7c feat(borrow): 借库申请前端必填拦截与星标——申请原因、预计归还日期(长期借用除外) 
- 提交前拦截：申请原因为空或(未勾长期借用且无归还日期)提示并 return
- 表单加必填星标：申请原因恒必填；预计归还日期仅在非长期借用时 required
 2026-09-09 10:53:16 +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
2abac8b3f9 feat(borrow,outbound): 申请页审批人改可选(默认免审批)，提示语更新 
- 出库/借库申请不再强制选审批人；命中需审批且未选人时由后端提示补选
- 成功提示改为：含需审批物料将进入审批，否则直接交库管执行
 2026-09-09 09:31:28 +08:00
yueli
93f149739d feat(material): 基础信息列表加“出库/借库需审批”开关列 
- material_base.ts 新增 batchSetApprovalRequired
- material/list.vue：列配置/权限/表格 switch，单行拨动即保存（乐观更新）
 2026-09-09 09:31:23 +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
e03c035ee0 feat(db): material_base 增加 is_approval_required 开关列(出库/借库需审批) 
- boolean NOT NULL DEFAULT false，存量默认不审批
 2026-09-09 09:31:12 +08:00
yueli
6aba09880c feat(borrow): 库管借库执行自动把申请单原因带入备注说明 
- 选中已审批借库申请单时 form.remark 自动填充该单 remark(申请原因)，无需重复手填，可再改
 2026-09-09 09:31:06 +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
578c15dc95 fix(bom): 另存为版本自增基准改响应式，修复 V1.1→V1.2 未升级 
- originalVersion/currentBomNo 为普通 let，computed 读不到变化；且 handleSaveAs 在赋值前就算版本候选，导致从 V1.1 另存得到 V1.1 覆盖原版本
- 新增响应式 upgradeBaseVersion/upgradeBaseBomNo，versionOptions 改读 ref；handleSaveAs 先锁定基准再计算
- 修复后：V1.1→V1.2、V1.9→V1.10、主版本→V2.0，占用号自动跳过
 2026-09-08 18:19:28 +08:00
yueli
00dde3a896 fix(inbound/buy): 采购入库表单批号续号改用精准接口 
- checkHistoryAndSetMode 改调 /inbound/buy/latest-record 续号，不再依赖 getBuyList 前1000条
- 采购单导入“仅有 base_id”分支也自动续批号并带历史库位
 2026-09-08 18:16:08 +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
b4971f057e fix(bom): 管理页启停/归档即时同步与界面健壮性大修 
- 只读启停用后端权威 bom_no/version，修复改状态报 BOM不存在(400)
- 成功路径统一 await reloadCurrentGroups()：先更新分组摘要，再静默覆盖已展开分类明细
- 本地秒移除 applyLocalRowState：按新状态+当前筛选把不符合行立即踢出缓存并强制 Map 换引用
- 接口层与界面层 try 分离：UI 刷新异常不再误报“状态更新失败”，避免红绿/黄提示同弹
- 遍历全部改为 Array.isArray/?.keys()/entries()/||[] 防御，杜绝 undefined 误报
- 兼容 el-collapse 手风琴(String)与多开(Array)：新增 isCategoryActive/setActiveList，修复 activeCategories.filter is not a function
 2026-09-08 13:58:48 +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