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

117 Commits

Author SHA1 Message Date
yueli
f4f887c2b4 feat(borrow): 全局提醒支持双向 —— 发起方也能收到「转交被拒绝」 
提醒组件从单向（待我接收）扩展为双向，一次轮询同时取回两类：

  ① 转交被拒绝 —— 我发起、对方拒收，物品责任仍在我手上
  ② 待我接收   —— 别人转给我、等我确认

弹窗（沿用中央 Modal + 遮罩，不进则已、进则打断）：
  标题「转交被拒绝」，列出被拒物品（物料名 + 单号 + 接收人，超过 5 笔折叠计数），
  按钮【去处理】(跳借还记录) /【知道了】。

★ 优先级：拒绝提醒优先于待接收提醒，且**一次只弹一个弹窗**。
  前者是「责任已回到你手上」的状态变更，后者是「等你确认」的待办；
  本次弹了拒绝就直接 return，待接收那条留给下一轮（此时拒绝已 ack），
  避免两个 Modal 叠加打扰。

★ 两条退出路径都算「已知悉」并 ack —— 否则每次登录都会再弹同一条，
  从提醒退化成骚扰。ack 失败不阻断，下一轮还会再提醒（宁可多提醒一次，
  也不能漏）。

防叠加沿用上一轮的模块标志 + DOM 探测，标题白名单扩为两个。

顺带：流转明细时间线为转交节点补状态标签（已拒绝/待接收），被拒的转交
不再与成功的长得一模一样。

验证（node 复刻判定链）
  既有拒绝、又有 2 件待接收 → 弹[转交被拒绝]；确认后 ack；
  下一轮 → 弹[待办通知] count=2；再轮询 → 不弹(未变)。
  拒绝优先、不叠加、ack 后待接收提醒正常补上。
 2026-09-17 10:44:07 +08:00
yueli
2c732a9a3a feat(borrow): 全局待办强提醒（接收人不再处于盲区） 
新增无渲染组件 PendingTransferNotifier，挂在 Layout（路由切换常驻、且只在
已登录区域渲染，天然保证「有 token 才查」）。

UI
----
ElNotification，type=warning、duration=0（不自动关闭，须用户处理或手动点掉）：
  标题：待办通知：借库转交
  内容：您有 X 件物品等待接收确认，请及时处理。【去处理 >】
点击【去处理】关闭通知并 router.push('/operation/records')（借还记录页）。
message 用 VNode 构造而非 dangerouslyUseHTMLString —— 不必把数量拼进 HTML 字符串。

防骚扰（两道）
----
· 会话级去重：sessionStorage 记「上次已提醒过的数量」，只有数量**变化**才再弹。
  用 sessionStorage 而非 Pinia —— 前者跨刷新存活，后者会重置，刷新即轰炸。
· 数量归零时清掉记录，下次新转交能重新提醒。

★ 加了 2 分钟低频轮询（超出需求所写，但需求目标需要它）：
  需求只要求「初始化时查一次」，而 SPA 只在首次进入时初始化 —— 已打开页面的
  用户永远收不到提醒，与「第一时间响应」的目标相悖。有去重逻辑兜底，
  轮询不会造成重复打扰。不需要的话删掉定时器即可。

错误一律静默：提醒是锦上添花，不能因接口抖动弹错误框刷屏。

验证：去重状态机用 node 复刻验证 —— 3→2→1 各弹一次，刷新与轮询均不重复，
归零后再来新转交能重新提醒。
 2026-09-17 10:30:13 +08:00
yueli
263f7ba3a1 feat(borrow): 前端适配整单转交与双向握手 
· 转交弹窗由「选择明细」改为**整单**：列出该单全部未还物品（只读），
  明确告知「发起后对方确认，责任才转移」。原先让用户挑一行，挑中就只转
  那一行 —— 正是单内撕裂的入口，现从 UI 上根除。
· 操作栏新增【接收转交】【拒绝】：仅对 pending_transfer.is_mine 的行显示，
  即「待我接收」的转交。已有 PENDING 时不再显示【转交】，避免重复发起。
· 状态列新增「转交待确认」：此时主表 current_holder 未变（东西还在原持有人
  手上），必须用状态列把「责任正在转移中」显式表达出来，否则界面上看不出
  任何变化。
· 新增 acceptBorrowTransfer / rejectBorrowTransfer API；
  拒绝时用 prompt 收集可选原因，写入转交流水备注。

错误提示仍交由 request 拦截器统一 toast，不在本地重复弹出。
 2026-09-17 10:04:16 +08:00
yueli
ece5dd8d72 feat(borrow): 前端转交/流转明细 UI 与借用人选人适配 
转交 UI（借还记录页）
----
· 操作列新增【转交】，v-permission="'borrow_transfer'" + 按钮 loading 防抖
· 弹窗明示「仅支持整单全部转交」与「转交后须由接收人本人归还」，并在确认框
  复述接收人与转交数量
· 列表是 borrow_no 主子表结构，trans_borrow.id 在**明细行**上，而一张单的明细
  可各有不同持有人（转交是逐条明细进行的），故弹窗先让用户选定明细；单条明细
  时自动选中（实测 54/60 的单号只有 1 条，等于零额外点击）。
  该「单号按钮 → 弹窗选明细」范式沿用本页既有的「申请报废」。

流转明细时间线
----
· 操作列新增【流转记录】，无特殊权限要求（页面本身已由 op_records 把守）
· Drawer + el-timeline 倒序展示 借出 → 转交(可多次) → 归还 → 报废，
  每节点显示时间、动作、当事人（借用人 / 转出→接收 / 实际归还人）与经手库管，
  转交备注一并展示
· 主列表新增「当前持有人」列：转交后可能与「借用人」不是同一人；一张单的明细
  持有人可能不同，去重后逐个展示，已全部回库显示「已回库」

身份锚点适配
----
· 借出页：借用人由「自由输入姓名」改为「用户下拉」，提交 borrower_id
  （姓名无法唯一锚定一个人，重名即责任链断裂）
· 归还页：新增「实际归还人」下拉，默认取首件物品的当前持有人，提交 returner_id；
  主表新增「当前持有人」列提示库管该由谁来还
· 错误提示不再本地重复弹出 —— request 拦截器已按后端 msg 全局 toast，
  再弹一次会双份

验证：vite build 通过；接口契约经后端回归用例校验。
 2026-09-17 09:18:06 +08:00
yueli
d1337d12e1 fix(scrap): 修复扫码时库存行遮蔽在管不良品导致的「不在批准明细中」 
现象
----
报废申请单指向在管不良品时，待执行清单里明明能看到该 SKU，扫码却报
「不在该报废申请单的批准明细中，禁止报废」。

根因
----
在管不良品的 SKU 是从原库存行**复制**的（退回时 sku=getattr(stock_row,'sku','')），
因此同一个条码可能同时命中 stock_buy#M 与 trans_defective_goods#N —— 这是
**两个不同的实物**。

而 ScrapService.get_stock_by_barcode 原实现按固定顺序
（stock_product → stock_semi → stock_buy → trans_defective_goods）返回
**首个命中**。原库存行只要还在，就永远遮蔽在管不良品，扫码结果恒为
stock_buy。改造前双方都用 SKU 作为匹配键，遮蔽不暴露问题；上一轮给匹配键
加上来源表后，`sku:trans_defective_goods:X` ≠ `sku:stock_buy:X`，
问题才浮出水面。

实测复现（业务报障的 SKU 0000000590）：
    stock_buy#589           在库 6 件
    trans_defective_goods#24 在管 1 件（同一 SKU）
    批准明细期望 -> ('trans_defective_goods', 24)
    扫码实际返回 -> stock_buy#589   → 键不匹配 → 报错

修复
----
条码本身无法区分这两个实物，**只有单据上下文能决定该扫到哪一个**，故把
单据上下文引入扫码解析：

- get_stock_by_barcode(barcode, prefer_pairs=None)：改为**收集全部候选**，
  再按 prefer_pairs（当前申请单批准明细的 (source_table, stock_id) 集合）
  优先命中；无上下文时退回固定顺序，行为与改造前一致
- GET /scrap/scan 新增可选 request_id：据此加载该单的批准明细构造优先集。
  优先集构造失败不阻断扫码，仅告警并回退默认选路
- 前端 scanBarcode(barcode, requestId) 与 create.vue 调用处带上当前申请单 id

验证（隔离数据端到端，非仅单元）：
    同一 SKU 建于 stock_buy#2202 与 trans_defective_goods#25
    不带上下文扫码 -> stock_buy#2202          （命中批准明细? False ← 旧行为）
    带上下文扫码   -> trans_defective_goods#25（命中批准明细? True）
    执行后：在管 2→0、状态=已报废；**库存行 10/10 分毫未动**（未误扣错误实物）
 2026-09-16 17:22:51 +08:00
yueli
6520f1c97c feat(scrap): 前端适配报废审批收口 
配合后端把三条报废旁路收口到审批流。

【删除】api/scrap.ts 的 createScrap()
  对应后端已删的 POST /api/v1/scrap。该函数此前已是死代码（全仓无调用方），
  页面早已切换到申请-审批-按单执行流程。

【改造】不良品看板 views/stock/defective/index.vue
  「报废销毁」→「申请报废」：弹窗新增「指定审批人」（必填，复用
  getApproversList）。API 由 scrapDefective 改为 submitDefectiveScrapRequest。
  ★ 弹窗与成功提示都明确写出「在管数量不会立即扣减，待审批通过并执行后才
    扣减」—— 申请不预占 remaining_qty，行数据看起来毫无变化，不说明会诱发
    重复提交。

【改造】借还记录页 views/transaction/records.vue
  「报废」→「申请报废」：弹窗新增「指定审批人」（必填）。原先内联的
  request() 调用挪到 api/transaction.ts 成为 submitBorrowScrapRequest，
  与全仓 API 分层一致。确认框文案改为「提交后进入审批流程」。
  顺带清理 canScrap 里硬编码的 `username === 'IRIS'` 后门 —— 该账号在
  sys_user 表中根本不存在，属死代码。

【改造】按单报废执行页 views/operation/scrap/create.vue
  按 scrap_mode 把批准明细分流：
    · scan 项（库存行 / 在管不良品）—— 走原有扫码购物车，逻辑不变
    · auto 项（借出未还）—— 实物在借用人手上、无法扫码，放入**只读区块**
      展示，不进购物车（购物车语义是「扫码证据」，混入会让扫码校验失效）
  纯 auto 单隐藏整个扫码区并提示「本单无可扫码物料，将按批准数量直接执行」；
  扫码进度只统计 scan 项（否则进度条永远满不了，会让操作员误以为没扫完）；
  提交守卫放宽为「购物车与 auto 项都为空才拦」；确认框追加
  「另有 N 项将按批准数量自动执行」，避免操作员误以为只报废了扫到的那些。
  matchKey 同步加入来源表（与后端 _match_key 保持逐字同口径），
  sourceLabel 补两种新来源的中文名。

存量单据没有 scrap_mode 字段，前端回落为 scan，行为与改造前完全一致。
 2026-09-16 17:14:29 +08:00
yueli
27436f5efe feat(ui): 菜单权限过滤与退回记录页 
侧边栏支持按权限隐藏菜单（Sidebar/index.vue）：
- 新增 canSee()：读取 meta.permissions（数组，满足任一即可）
- ★ 同时修了一个既有缺陷：原实现只过滤顶层路由，**子路由的权限判定不生效**，
  未授权用户仍能在菜单里看到入口。现改为递归过滤，父菜单的子项被过滤光后
  父菜单本身也不再显示。
- ★ 刻意只认 meta.permissions（新键），历史遗留的 meta.permission（单数，
  如「维修管理」的 inbound_repair）保持不生效——一旦开始消费它，会让若干
  菜单对部分角色突然消失，属于超出本次范围的静默行为变更。两者若要统一，
  建议单独排期逐个核对影响面。

路由守卫（router/index.ts）：
- 新增 meta.permissions 校验，未授权时提示并跳首页。侧边栏负责「菜单看不见」，
  守卫负责「直接敲 URL 也进不去」，后端负责「绕过前端直接调接口也不行」，
  三层任一失效都不至于越权。
- 顺带修了原守卫的分支结构：roles 通过时直接 next()，会跳过后续检查；
  改为不通过才中断，落到末尾统一 next()。

新增「退回记录」页（views/outbound/returns/index.vue）：
- 纯只读台账，无任何操作按钮，供库管核对历史退回
- 展示 退回时间 / 原出库单号 / 物料名称 / 规格 / SKU / 退回数量 /
  退回类型 / 退回原因 / 操作人
- 退回类型用标签区分（不良品=红，良品=绿）
- 源库存行或原单被删除时显示占位文案而非空白，台账不留哑行

api/inbound/return.ts 补 getReturnList()。
 2026-09-16 16:46:02 +08:00
yueli
fd99d33a0d feat(return): 前端退回入口与不良品在管台账看板 
出库记录页（views/outbound/index.vue）：
- 明细行新增「退回」列，returnable_quantity <= 0 时按钮置灰，行内显示「已退 N」
- 对话框展示 原出库数量 / 已退回数量 / 本次可退最大，默认带入可退最大值
- 退回类型用下拉单选：良品（加回库存）/ 不良品（转入异常待处理）
- 退回原因必填，提交前三重校验；按钮 :loading + 函数内 submitting 双保险防抖
- 成功后刷新列表。错误提示不重复弹——request 拦截器对 HTTP 400 已取
  data.msg 展示，对话框 catch 只收尾

配套后端（services/outbound_service.py）：
- get_grouped_list 的出库明细补 id / returned_quantity / returnable_quantity。
  原先明细不带 id，退回接口无从指定 outbound_id

新增页面（views/stock/defective/index.vue，路由 /inventory/defective）：
- 展示 物料名称/规格/SKU/退回时间/操作人/退回总数/剩余待处理/状态
- 顶部 alert 提示在管总量，并明确「这批实物不在库存表中，盘点请以本台账
  为准」——在管坏件对盘点不可见是本方案的固有盲区，必须在页面上主动提醒
- 仅对 remaining_qty > 0 的行提供「修复回库」「报废销毁」，终态行显示已结案
- 两个弹窗均带数量上限约束与 loading 防抖，成功后刷新

新增 api/inbound/return.ts 承载四个逆向物流接口。

侧边栏由 router/index.ts 驱动，加路由即入菜单；注意侧边栏只过滤
meta.hidden、不看 meta.permission，故菜单对所有角色可见，访问控制由后端
接口负责（与既有「维修管理」一致）。
 2026-09-16 15:45:40 +08:00
yueli
b695592178 feat(stocktake): 明细去 SKU 改显批号/序列号，备注可选可填，列宽适配平板 
【1. 去 SKU】明细表删除 SKU 列，新增「批次号」「序列号」。
SKU 是账务口径的物料主键，现场照着它抄数等于把账面信息递给盘点人。
（搜索框仍支持按 SKU 搜，只是列表不展示。）

后端 merged-list 的 UNION ALL 需要小心：stock_product 表**没有
batch_number 列**（只有 serial_number），故该分支必须写 '' AS batch_number
占位，否则列数不齐 / column does not exist。实测成品行 batch='' serial='205'。

【2. 列宽】名称/规格改 min-width=120（超长省略+tooltip）；库位固定 120；
账面数/实盘数/差异固定 100，保证平板上输入框有足够触控面积；备注 min-width=160。

【3. 备注升级为可选项】el-input 换成 el-select(filterable allow-create
default-first-option)，预设 ['包装破损','找不到实物','标签丢失','账实不符','实物变质']，
可点选也可自行输入。

★ 顺带修一个真 bug：handleRemarkChange 原本是个空函数，只 console.log，
  备注填了**根本没落库**。现复用 update-quantity 接口保存，后端新增可选的
  remark 字段（用 `remark is not None` 判断，只改数量时不会清空备注）。
  未扫过的行没有草稿记录可挂，备注框同样禁用。

实测: 备注落库='包装破损'；只改数量后备注仍在（未被清空）。
 2026-09-14 09:45:38 +08:00
yueli
e573185ea4 perf(stocktake): 库位树按公司前缀后端裁剪，树与推荐并行请求 
【后端】/tree 支持 ?prefixes=Y 或 ?prefixes=C,L（逗号分隔）
只在**顶层**按 name / full_path 前缀过滤，命中即整棵子树保留 ——
不递归裁剪，避免把子树打散导致前端勾选语义错乱。不传则全量。
刻意不用懒加载：setCheckedKeys / getCheckedNodes 依赖全树已构建。

实测节点数（含子树）：
  全量 3371 → IRIS (Y) 500（↓85%）→ LICA (C,L) 2871（↓15%）
IRIS 收益很大；LICA 的前缀覆盖了树的大部分分支，故提升有限。

【前端】
- getWarehouseTree(prefixes?) 透传前缀，loadLocationTree 从
  getAllowedLocPrefixes(selectedCompany) 取；后端已做过滤，
  前端不再重复过滤，删掉冗余的 filterTreeByCompany。
- fetchRecommendLocations 改为 Promise.all 并行拉树与推荐，
  取代原来的串行 await（两段网络等待不再叠加）；
  setCheckedKeys 前仍保留 await nextTick() 等树渲染完。

【顺带修一个上一轮引入的 bug】
右侧自 leafOnly 改造后只存末级路径，而推荐返回的是库存级路径、可能是
非末级，原来的逐字比对必然对不上，会把正常勾选的库位误报成
「未能勾选」。改为按「自身或其祖先」判定覆盖。

实测: prefixes 过滤正确（IRIS 8 个顶层 / LICA 25 个 / 不传 33 个）
 2026-09-11 14:45:23 +08:00
yueli
1d1ca1b89e feat(web): userStore 暴露所属公司，盘点相关 API 支持按公司传参 
多设备协同盘点需要前端明确知道「在盘哪个公司」：

- userStore 从 JWT claim company_name 解出 companyName 并暴露，登录、
  刷新 token、登出时同步维护。后端 get_current_company_filter() 读的
  也是这个 claim，两侧口径一致。
- 新增 getStocktakeCompanies()，对应盘点页的公司下拉接口。
- 盘点 API 增加公司维度：scanStockByBarcode 加可选 company；
  getDraftMergedList / getAllStocktakeItems 加 company_name；
  updateStocktakeQuantity 加第二个参数。

公司标识一律走 query string 而非 body：后端 get_current_company_filter()
只读 request.args，POST 请求 body 里的 company_name 会被直接忽略。
 2026-09-11 11:33:19 +08:00
yueli
b313fefdfa fix(web): 扫码页与备选库位带单据ID，按有效可用量限流 
配合后端预占回加：扫码/借库/审批页面调用 /outbound/scan 与 /outbound/alternatives
时带上本单 id 与 biz_type，拿到的 available_quantity 即为「实时可用量 + 本单
预占」，本单锁定的行不会再因实时可用量为 0 而被拦住或从列表消失。

后端已在响应边界完成归一化，故前端模板与校验逻辑（:max、库存列展示、超量
警告、草稿存取）一律不动，只多传参数 —— 避免把同一语义散落到多个读写点。

- api/outbound.ts：getStockByBarcode / getStockAlternatives 加 requestId 与
  bizType 参数，导出 ScanBizType，ScanResult 补 reserved_quantity 等字段
- api/transaction.ts：同名的历史副本同步签名（当前无调用方，加注释指向唯一来源）
- views/outbound/create.vue、views/transaction/borrow.vue：各 3 处调用点带上
  单据 id；refreshStockFromDraft 改为显式透传 id，不依赖 computed 已解析
- views/borrow/approval/index.vue：审批页也带上本单 id，否则待审批单
  （预占已生效）锁定的行会因实时可用量为 0 而从备选列表消失

借库侧 request_id 是 BorrowApproval.id，靠 biz_type='borrow' 与出库单区分 ——
两张表 ID 空间独立，不可省。
 2026-09-11 10:34:23 +08:00
yueli
6f2f077751 feat(purchase): 采购页搜索区对齐出库记录版式 
原顶部工具栏是裸 div + 状态单选，现改为 el-form :inline 版式，与出库记录 /
报废记录一致：

  状态      全部 / 待审批 / 已通过 / 已驳回 / 已完成 / 已完结
  搜索      [搜索类型下拉] + 关键词输入，500ms 防抖
  采购日期  日期范围选择
  按钮      查询 / 重置 / 新建采购申请

交互细节：
· 搜索类型切换、清空输入时立即查询（取消防抖等待）；
· 「重置」恢复默认的「待审批」状态（该页默认视图），而非清成"全部"——
  与页面初始状态保持一致；
· 重置同时清空关键词、搜索类型、日期范围。

api/purchase.ts 的 getPurchaseList 补充新参数的类型定义。
 2026-09-10 17:41:29 +08:00
yueli
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
yueli
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
yueli
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
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
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
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
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
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
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
93f149739d feat(material): 基础信息列表加“出库/借库需审批”开关列 
- material_base.ts 新增 batchSetApprovalRequired
- material/list.vue：列配置/权限/表格 switch，单行拨动即保存（乐观更新）
 2026-09-09 09:31:23 +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
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
424df231d5 feat(bom): 前端 BOM API——候选版本、独立启停、物料搜索支持公司 
- bom.ts 新增 getChildBomVersions(候选版本) 与 updateBomStatus(独立启停)
- inbound/buy.ts searchMaterialBase 增加可选 company 参数（跨域按公司过滤）
 2026-09-08 10:14:47 +08:00
yueli
3bd19c1ab5 feat: 借库审批支持手动完结——已通过(status=1)单可强制完结，库管/主管/超管可见 2026-09-04 14:52:31 +08:00
yueli
7cdc0bc3a1 perf: 库位选择器改为按需懒加载——新增 /warehouse/children 接口，WarehouseSelector 移除全量树依赖 2026-09-04 10:51:49 +08:00
yueli
bf7b2cc6d3 feat: BOM 库存接口支持按版本查询，修复同一编号多版本下拉回显错乱 2026-09-02 18:39:17 +08:00
yueli
bee037f925 feat: MOM 扫码入库对接 Track 产品身份证自动填充 
- 半成品/成品入库弹窗顶部新增'扫码入库'按钮,打开扫码面板(扫码枪/摄像头)
- 扫码 Track 身份证后自动填充物料信息与序列号,不再二次搜索
- 后端新增 track_query_service(httpx 调 Track lookup)、track-lookup 接口
- 入库成功后 notify_track 通知 Track 闭环
 2026-09-01 13:52:56 +08:00
yueli
893e7250db fix(api): update-stocktake-quantity 按 session_id 隔离更新，防止跨会话误改 
后端 update_stocktake_quantity 原只按 stock_id+source_table 查草稿，
不同盘点会话会相互覆盖实盘数。后端增加 session_id 过滤，
前端 handleQuantityChange 配套传入当前会话ID，API 类型同步补全。
 2026-08-31 16:00:20 +08:00
yueli
7e281cf285 fix(stocktake): 盘库扫码改为精确匹配，修复漏匹配与性能问题 
问题:
1. 准确性 bug: 前端用 getStockList({pageSize:10, keyword}) 模糊搜索 + find()
   当 SKU 前缀相同、目标不在前10条时，误报'未找到该物料库存'
2. 性能: 每次扫码全表 ilike %x% 搜索 3 张表，不走索引

修复:
- 后端 get_stock_info 改为精确匹配(==)优先，未命中再回退模糊搜索
- 新增 GET /inbound/stock/scan 扫码精确匹配接口，返回唯一命中
- 前端 onScanSuccess/handleManualInput 改用 scanStockByBarcode
  一次请求直接命中，不再依赖 pageSize:10 + find()
 2026-08-31 14:49:24 +08:00
yueli
1000deda2f feat(purchase): 采购单号改为 批次-批内序号 格式，显式体现同批 
按用户原始逻辑还原并扩展:
- 单号格式: PUR-日期-时间-批次-批内序号
  例: PUR-20260831-1021-0001-0001（今日第1次采购的第1条）
- generate_request_no 支持 batch_seq 参数生成批次+批内序号
- 新增 GET /purchase/next-batch-seq 返回今日下一个批次号
- 前端提交时获取批次号，同批所有行共享，循环提交生成连续批内序号
- 批次识别: 单号去掉末尾 -批内序号 即为批次前缀
- 保留旧格式兼容（无 batch_seq 时回退 PUR-日期-时间-流水）
 2026-08-31 13:54:03 +08:00
yueli
f499346f74 refactor(purchase): 批次概念改为基于 request_no 前缀推导，撤销数据库字段 
按用户反馈：不需要新增数据库字段，现有 request_no (PUR-20260831-1021-0001)
本身就能推导批次——去掉末尾4位流水号即为批次前缀。

- 撤销 purchase_request.batch_no 字段（模型/数据库）
- 撤销 create 接口的 batch_no 参数与 generate_batch_no
- 批次标识 = request_no 去掉末尾 -XXXX 段
  getBatchKey('PUR-20260831-1021-0001') = 'PUR-20260831-1021'
- 按批次查询/批量审批接口改用 batch_key (request_no LIKE 前缀)
- 前端列表批次号列、整批弹窗、一键审批本批均基于前缀推导
- 零数据库迁移，历史数据立即可用
 2026-08-31 13:49:11 +08:00
yueli
664127ee30 feat(purchase): 采购批次号支持，同一批提交的记录可分组查看/统计 
背景: 循环提交把一批物品生成多条独立申请，无法识别'哪些是同一批采购'

后端:
- purchase_request 模型新增 batch_no 字段（同一批提交共享）
- create 接口接收 batch_no，无则自动生成 BATCH-yyyyMMdd-HHmm-随机
- 新增 GET /purchase/batch/<batch_no> 按批次查询所有记录
- 批量审批接口支持按 batch_no 一键审批整批

前端:
- 提交时生成 batch_no 共享给所有行
- 列表新增批次号列（可点击）
- 新增'整批查看'弹窗：显示同批次所有记录 + 一键批量通过本批
- 操作列新增'整批'按钮

数据库需执行: ALTER TABLE purchase_request ADD COLUMN batch_no VARCHAR(100);
 2026-08-31 13:46:46 +08:00
yueli
4b62c81baa feat(purchase): 采购申请批量审批（解决循环提交需多次审批） 
问题: 一次提交 10 个物品生成 10 条独立申请，审批人需操作 10 次

后端:
- 新增 POST /api/v1/purchase/batch-approve 批量审批接口
  接收 ids + action，循环审批，成功/失败分别返回

前端:
- 待审批列表加多选列（仅 status=0 可勾选）
- 顶部批量操作栏：批量通过 / 批量驳回 / 取消选择
- 批量驳回弹窗统一填写驳回原因
 2026-08-31 13:41:25 +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
0074d96163 fix: 权限配置页 GET 请求加 _t 防浏览器缓存 + 保存后自动刷新 UI 2026-07-17 16:13:12 +08:00
yueli
8c10bb0903 feat: 盘点合并列表 — 服务端JOIN+DB分页，消除99999全量加载 
## stock.py
- 新增 GET /draft/merged-list: UNION ALL三表+LEFT JOIN draft
  数据库级 LIMIT/OFFSET 分页，不再加载全量到Python内存
- 参数: session_id, keyword, status_filter, page, pageSize
- 返回: list, total, total_scanned (已扫去重数)

## stock.ts
- 新增 getDraftMergedList() API函数

## stocktake/index.vue
- fetchInventoryList: 改用merged-list单次调用替代99999全量+find()
- resumeSession: limit 99999→1 先检查存在,再limit 500加载
 2026-07-16 13:08:29 +08:00
yueli
329820117f perf: 消除 outbound/borrow BOM 匹配的 while(true) 全量加载 
## 后端
- outbound.py: 新增 POST /api/v1/outbound/bom-match-stock 端点
  接收 child_ids[]，服务端按 base_id IN 查询三表有库存记录并返回

## 前端
- outbound.ts: 新增 bomMatchStock(childIds) API 函数
- Selection.vue: loadAllStockForBom (while(true) 全量) → loadStockForBom (单次 API)
- borrow/apply/index.vue: 同上

## 效果
- BOM 匹配从 ~90 次 HTTP 请求降为 1 次
- 浏览器内存从 ~18000 条降为 ~8-50 条
 2026-07-15 17:52:08 +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
4934cd4d8f feat: 采购管理税率+分开单价总价列 + 按单出/借库锁定扫描 + 含税法计算 
- purchase: 新增tax_rate字段(model+service+frontend), 表格拆分为不含税单价/总价/税率三列
- buy.vue: 含税法计算(含税总价=数量×含税单价), 含税总价自动计算可手动覆盖
- create.vue: 按单出库模式下未选审批单时锁定摄像头和SKU输入
- borrow.vue: 未选审批单时锁定摄像头和SKU输入
- deploy_production.sql: 整合全部数据库变更(表结构+权限码+角色分配)
 2026-07-15 16:07:59 +08:00
yueli
0651eb07fa fix: 彻底解耦出库/借库权限联动 + 路由去硬编码roles + 补API权限保护 
根因: 借库选单页面14处硬编码outbound_selection:operation, 导致两模块权限联动

修复:
- borrow/apply: 14处outbound_selection:operation→op_borrow_apply:operation
- stock.py: 拆分_do_get_stock_list裸逻辑, 出库/借库各绑独立权限码
- transactions: 新增/borrow/stock-list端点(@permission(op_borrow_apply))
- transaction.ts: 新增getBorrowStockList前端API函数
- outbound.py: 出库审批4端点改用独立outbound_approval权限码
- transactions.py: 借库审批3端点补@permission(op_borrow_approval)
- purchase.py: 采购管理7端点补@permission(inbound_buy)
- audit.py: 审计日志补@permission(system_audit)
- router: 清除全部6处硬编码roles, 交由动态权限树控制
 2026-07-15 14:33:11 +08:00
yueli
538b6cb818 feat: 采购单导入自动填充采购人/邮箱/详情链接 + 实时搜索 
- PurchaseRequest.to_dict() 新增 requester_email
- 导入时自动填入: 采购人(requester_name) + 邮箱(requester_email) + 详情链接(supplier_link)
- 移除原始链接/详情链接的历史 autocomplete, 改为纯输入框+权限守卫
- 采购单导入搜索改为实时输入搜索(300ms防抖), 保留搜索按钮
 2026-07-14 16:29:19 +08:00
yueli
a11b7972c3 feat: 打通采购申请与入库的按单入库链路 
后端变更:
- PurchaseRequest 新增 base_id 硬关联 MaterialBase，StockBuy 新增 request_id 关联采购单
- handle_inbound 支持 request_id 入参，入库后自动反写采购单状态为已完成
- 新增 get_approved_requests 接口，返回已审批未入库采购单列表（含物料信息+历史数据回退匹配）
- create_purchase_request 新增 name+spec_model 自动匹配 MaterialBase
- 新增 SQL 和 Alembic 数据库迁移脚本

前端变更:
- 入库表单新增"从采购单导入"弹窗，支持搜索/选中已审批采购单并一键填充物料和商务信息
- 单价/总价交叉推算，缺项自动补全
- 选中行蓝色高亮+点击整行选中，行级交互优化
 2026-07-14 15:25:00 +08:00
yueli
4f5965db02 feat: JWT多租户数据权限隔离 & 主管系统管理权限 & 含税单价补齐 
## 多租户公司数据隔离
- 新增 get_current_company_filter() 工具函数 (decorators.py)
  SUPER_ADMIN: 可传company_name参数过滤或传ALL看全量
  其他角色: 强制隔离到JWT中的company_name
- 重构 base_service.py / buy_service.py: 用集中式函数替换内联公司过滤
- SysRolePermission 表新增 company_name 字段，支持同角色不同公司权限
- get_user_permissions() 新增 company_name 参数，查公司定制+全局模板权限
- permission.py API 新增 @permission_required 拦截 + 公司过滤
- 19个API/service文件传递 company_name 到权限查询

## 主管系统管理权限
- delete_user() 允许SUPERVISOR删除同公司用户 (原仅SUPER_ADMIN)
- get_all_users() 新增 company_name 参数过滤
- 用户列表/权限分配 API 应用 get_current_company_filter()
- 前端 UserCreate.vue: 超管可见公司下拉框，主管隐藏部门字段

## 前端多租户适配
- material/list.vue / buy.vue: 公司下拉框仅超管可见，默认ALL
- UserCreate.vue: 新增搜索栏公司筛选，部门字段按角色显隐
- auth.ts: getUserList() 支持 params 参数

## Bug修复: 含税单价字段补齐
- buy.vue: 表格列/高级筛选/排序/权限映射新增 post_tax_unit_price
- buy_service.py: allowed_fields/sort_field_map 新增 post_tax_unit_price
 2026-07-13 15:12:22 +08:00
dxc
c1092407ad V3.50 2026-06-25 15:21:43 +08:00
DXC
7ef22a3830 feat(借库审批流): 完整前后端实现 2026-06-12 14:08:19 +08:00
DXC
c7b84ff3c6 fix: BOM草稿模块缺陷修复（事务回滚 + 外键约束 + 前端状态清理） 2026-06-10 11:30:07 +08:00
DXC
8a2da1ac1e 半成品/成品入库：BOM 编号下拉按父件规格联动过滤（前后端双端改造） 
- 后端 /inbound/{semi,product}/search-bom 增加 parent_spec 可选参数，Service 层在 MaterialBase.spec_model 上加等值过滤
 2026-06-04 16:01:48 +08:00