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

47 Commits

Author SHA1 Message Date
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
yueli
0005a689dc fix(outbound): 补发申请人取原申请人，绝不再回退为库管 
问题
----
上一版在库管未指定「补发给谁」时，把补发单申请人回退成了**当前操作人（库管）**。
但补发是**原申请人的需求**，挂到库管名下逻辑不通 —— 那张单会出现在库管的
「我的申请」里，而真正该拿东西的人什么也看不到。

根因
----
trans_outbound 只有 consumer_name（**扫码时前端自由填写**的领用人/客户名，
既不可靠也可能是外部客户），没有任何指回原审批单的关联，所以当时只能退而求其次。

根治
----
一、trans_outbound 新增 applicant_id，**创建出库时从关联审批单带出**
    （request_id 已强制必填、approval 恒非 None，故新单据必然有值）。
    落这一列后，「退回 → 补发」即可自动找回真正的原申请人。
    ⚠ 存量行为 NULL —— 存量出库与其来源审批单之间没有任何可用关联，无从回填。
      刻意留 NULL 而不是按姓名猜（consumer_name 是自由文本，会重名错绑），
      与 dispatch_operator 同一取舍：宁可留空，也不猜。

二、退回接口的申请人优先级改为：
      ① 前端显式指定 reissue_applicant_id
      ② 原出库明细记录的 applicant_id（真实原申请人）
      ③ 都没有 → **报错要求指定**
    ★ 彻底移除「回退为当前操作人」—— 那正是本次要修的逻辑错误。

三、出库列表明细返回 applicant_id，供前端精确预填。

验证（9 项断言全通过）
  · 新单据 → 申请人 = 原申请人(12)，绝不是库管(7)
  · 显式指定优先于原申请人
  ★ 历史单据未指定 → 接口拒绝、要求选择「补发给谁」、整笔回滚、
    且**未生成任何挂在库管名下的补发单**
  · 历史单据 + 显式指定 → 正常
  库存与数据零残留。
 2026-09-17 12:07:21 +08:00
yueli
fbc9296056 feat(stock): status 硬隔离与出库通道封堵 
激活库存表长期「只写不读」的 status 列，使其成为分配准入的硬门槛。

- inventory_reservation: 新增状态语义单一事实来源（STOCK_STATUS_*/
  allocatable_filter/is_allocatable）；verify_scanned 增加状态准入校验
  （覆盖出库与借库两条提交路径）
- outbound: _allocate_bom_requirements 过滤条件加 allocatable_filter，
  非「在库」一律不进入候选集；扫码路由把 ValueError 转为 400
- outbound_service: create_outbound_batch 强制 request_id 必填。原先无单
  时会跳到所谓「散单」分支，而该分支的扣减逻辑从未落地（注释点名的
  _apply_reservation_override 全仓不存在），实测只写台账不扣库存，
  同一批货可被反复出库；get_stock_by_barcode 接入扫码准入；维修单扫码
  补排除「报废转出」；预占再平衡块补 rollback 兜底
- fill_missing_stock_status.sql: 把存量行刷回「在库」。该过滤是
  Fail-Closed 的，不先洗刷会让全库无法出库

破坏性变更：不传 request_id 的出库请求现在会被拒绝。
 2026-09-16 15:45:02 +08:00
yueli
06cb5f1cac fix(reservation): 实扫来源不可识别时整单失败，避免预占永久锁死 
出库与借库两条执行路径原先写作：

    _scanned = [i for i in items if i.get('source_table') != 'trans_repair']
    if _scanned:
        verify_scanned(...); restore_then_deduct(...)

`if _scanned:` 为假时校验与释放被整体跳过，而下方仍无条件把单据置为
status=3（已完成）。此时申请阶段 reserve_for_items() 扣掉的 available_quantity
无人归还，且 status=3 之后 /close（要求 status==1）与 /withdraw（要求
status∈(0,1)）都拒绝再释放 —— 预占就此永久锁死，成为谁也领不走的幽灵库存，
且没有流水可供追溯。

改为 Fail-Closed：实扫明细的来源必须全部落在 model_map 内，否则整单失败。
事务回滚后单据保持 status=1、预占原样保留，库管可重试执行，或走驳回/撤回 ——
任一路径都能正常归还预占。

- outbound_service.create_outbound_batch：以 model_map 白名单过滤，
  并要求 _scanned 非空
- trans_service.execute_dispatch：先显式校验来源合法性并列出非法值，
  再要求 _scanned 非空
 2026-09-11 10:34:55 +08:00
yueli
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
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
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
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
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
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
044e6dbd98 feat(borrow,outbound): 库管(WAREHOUSE_MGR)代建申请强制审批 
- submit/create 新增 force_approval：库管建单无视物料是否需审批，一律走审批
- 路由按当前角色为 WAREHOUSE_MGR 传 true；未选审批人返回明确业务错误
 2026-09-09 16:19:38 +08:00
yueli
eff9b62224 fix(borrow,outbound): 普通用户记录只看本人——按领用人/借用人姓名(不含账号前缀)匹配 
- 出库记录/借还记录：非管理者视角时按 领用人(consumer_name)/借用人(borrower_name) 过滤
- 匹配取登录名 username.split(/)[0] 的姓名；兼容库里存“姓名/xiaolongxia”全名(姓名+/前缀)
- 修复：管理员替员工创建、领用人=员工 的单，员工登录可见
 2026-09-09 11:19:15 +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
478b90fe50 feat: 出库类型贯穿申请→扫码出库——申请单加 outbound_type，申请时选类型、扫码出库自动带出 2026-09-07 14:01:13 +08:00
yueli
1527d552d4 feat: 出库/借库记录记录并展示库位快照（DB加列+后端写入+记录页展示） 2026-09-04 11:42:44 +08:00
yueli
1b760f351e fix: 出库/借库扫码查库存与 BOM 子件物料选择加行级公司隔离（超管/跨域不受限） 2026-09-04 09:40:00 +08:00
yueli
2c092c4c01 feat: MOM 出库联动 Track 标记已出库 
- 发货出库时反查库存表 serial_number(Track 身份证),commit 后通知 Track mom-outbound
- notify_track 支持指定 webhook url(TRACK_OUTBOUND_WEBHOOK_URL)
 2026-09-01 13:53:00 +08:00
yueli
39f3f8af45 feat(outbound): 审批单手动完结/作废功能 
- 后端: outbound_service 新增 close_request 方法（状态 1-已通过 → 4-已完结）
- 后端: 新增 POST /api/v1/outbound/request/<id>/close 接口
- 模型: status_text 数组增加「已完结」
- 前端: create.vue 审批单选择区新增「强制完结此单」按钮
  完结后刷新列表，该单从已通过下拉中移除
- 权限: 超级管理员/审批人/拥有 outbound_create:operation 的用户可完结（库管可操作）
 2026-08-31 10:15:33 +08:00
yueli
05832e913b fix: can_approve 增加 outbound_approval:operation RBAC 权限判断，前端按钮权限与后端审批权限统一对齐 2026-07-17 15:17:26 +08:00
yueli
2556b77530 perf: 系统级性能优化与并发安全修复 
## 并发安全修复 (4处)
- scrap.py: 报废执行添加 SELECT FOR UPDATE 悲观锁，消除 TOCTOU 竞态
- stock.py (adjust_stock): 盘点调整添加 for_update=True 行锁
- outbound_service.py: 低库存预警 SMTP 调用移到 commit 之后，避免长事务
- trans_service.py: execute_dispatch 按 (source_table, id) 排序 items，消除死锁风险

## N+1 查询优化 (2处)
- inventory_task.py: _prefetch_inventory_map 单条 UNION ALL+GROUP BY 替代循环内逐条查询（N*4次→2次）
- stock.py (export_stocktake): get_borrowed_qty 批量 GROUP BY 替代逐条 TransBorrow 查询（~18000次→1次）

## BOM 列表性能重构
- bom_service.py: get_bom_list 单条 GROUP BY+string_agg+分页，消除 N+1 循环查询
- bom_service.py: 新增 get_bom_summary (轻量 GROUP BY category+COUNT)
- bom.py: 新增 /api/v1/bom/summary 路由，/list 支持 category 过滤

## Odoo 基础信息懒加载
- base_service.py: 新增 get_odoo_summary (GROUP BY category+COUNT)
- base.py: 新增 /api/v1/inbound/base/odoo-summary 路由
- buyOdoo.vue: 懒加载分组架构 (fetchOdooSummary + loadGroupItems)
- material_base.ts: 新增 getOdooSummary API

## 前端 Bug 修复
- BomManage.vue: 懒加载分组 (fetchBomSummary + loadGroupItems + collapse)
- BomManage.vue: 适配新 API 格式 (res.data.items 替代 res.data)
- buyOdoo.vue: 移除 "点击展开加载" 文字
- Selection.vue + borrow/apply/index.vue: openBomSelect 适配新 API 格式
 2026-07-15 17:37:57 +08:00
yueli
9988d1b7eb fix: 补全审计/出库审批/采购管理/借库审批的权限保护+公司隔离 
- audit.py: 补@permission_required(system_audit)+import, 审计日志通过split_part关联用户表过滤公司
- outbound.py: 出库审批5个端点全补@permission_required(outbound_list)
- purchase.py: 采购管理7个端点全补@permission_required(inbound_buy)
- borrow_service: 借库审批列表通过applicant_id关联用户表过滤公司
- outbound_service: 出库审批列表通过applicant_id关联用户表过滤公司
- purchase_service: 采购列表通过base_id+requester_id双路过滤公司
- base_service/search_material: 去除debug日志
- decorators: 去除debug日志
 2026-07-15 11:49:53 +08:00
yueli
e1417d740a feat: 全模块公司隔离 + crossDomain权限码动态跨域控制 
- get_current_company_filter: 新增_has_cross_domain_permission, 权限码替代硬编码
- 补全11个Service的get_current_company_filter调用(semi/product/service/outbound/bom/trans/scrap/summary)
- base/search修复: search_material此前无隔离, 已补全
- get_current_company_filter兜底: JWT缺company_name时返回__NO_COMPANY__防止放行
- permission.py: _get_operator_company补全返回值, 修复权限页保存逻辑
- 新增crossDomain迁移脚本, element_type=element挂system_mgmt下
 2026-07-15 11:11:40 +08:00
DXC
5c0c1632c3 fix(审批邮件): items_json序列化Bug修复 + 邮件方法出库/借库物理隔离 2026-06-12 15:04:57 +08:00
DXC
48651ffd01 perf: 消除出库列表和还库操作的 N+1 查询，改用批量 IN + joinedload 2026-05-19 09:49:30 +08:00
DXC
3dae206828 feat(outbound): 完善出库审批邮件通知逻辑，支持申请人与审批人同时收到邮件（带物料明细），审批通过后申请人和库管均收到带物料明细的通知 2026-05-12 13:42:15 +08:00
DXC
c86da38a70 chore(pre-change): 准备修改出库审批邮件通知逻辑与自审批能力 2026-05-12 13:36:18 +08:00
dxc
259f3a7e0d 4.29扫码获取库位小工具接口 2026-04-29 15:40:43 +08:00
DXC
8276597a67 fix(email): 审批通知逻辑重构 - 通过时同时通知库管和申请人，驳回仅通知申请人；精简 DEBUG 日志 2026-04-29 09:10:34 +08:00
DXC
ccbce82c2e fix(email): 审批通过后库管通知增加明细+DEBUG日志，修复MAIL_DEFAULT_SENDER格式问题 2026-04-28 16:46:12 +08:00
DXC
62c0e3738e fix(outbound+trans): 修复POST接口错误数据清洗导致的sku/quantity字段被清除Bug，并新增出库审批工作流全链路 2026-04-28 16:02:34 +08:00
DXC
0a9c8cd39c fix(repair): add edit action, mandatory validations, default date, and fix outbound SN mapping 2026-04-09 08:49:50 +08:00
DXC
09936cb045 fix(outbound): integrate TransRepair into global barcode scanning and outbound checkout flow 2026-04-09 08:38:48 +08:00
DXC
f612c47143 fix(filter): append 23:59:59 to end_date to resolve midnight truncation bug in date range queries 2026-04-07 17:39:14 +08:00
DXC
30ab1c186c fix: filter zero quantity items in inventory export and add batch/sn traceability to outbound record details 2026-04-07 16:41:53 +08:00
DXC
c8810891d8 fix(api): globally replace invalid material_base/material_name attributes with correct base relationship 2026-03-26 17:14:26 +08:00
DXC
71e5f075d2 feat: implement composite debounced search with prepended select and wipe out duplicate root permission nodes 2026-03-20 10:26:45 +08:00
DXC
3bb3975022 fix: use .c to access SQLAlchemy subquery columns correctly 2026-03-20 10:15:11 +08:00
DXC
34629b432a fix: correct SQLAlchemy join condition to resolve MaterialBase AttributeError 2026-03-20 10:06:22 +08:00
DXC
74089c7d7d fix: clean orphaned permission tree nodes and enhance outbound search with material name/spec model 2026-03-20 09:53:32 +08:00
dxc
09a2af0b55 refactor: rename unit_price to pre_tax_unit_price in outbound service 
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat>
 2026-02-27 16:43:30 +08:00
dxc
b98f89bfe4 chore: add .material->.base refactor check comments 
Co-authored-by: aider (openai/DeepSeek-V3.2-Thinking) <aider@aider.chat>
 2026-02-10 11:34:50 +08:00
dxc
c1ddb8093f 出库进行修改，确保可以进行多个样例的出库以及出库的记录展示 2026-02-05 16:54:11 +08:00
dxc
4f90e02dcf 修改时间时区问题 2026-02-05 14:36:36 +08:00
dxc
f3b60dfc54 出库操作逻辑上面实现，成功跑通 2026-02-05 10:20:52 +08:00
dxc
797b611530 出库逻辑添加，扫码识别编码成功，后续对应逻辑没有完成 2026-02-04 17:22:20 +08:00