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

705 Commits

Author SHA1 Message Date
yueli
f4a01be951 V3.81,9.16推送 2026-09-16 17:51:32 +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
511e822d12 feat(ui): 按钮级权限守卫与数量显示格式化 
按钮级权限（与后端 @permission_required 用同一批权限码）：
- 出库记录页「退回」按钮   -> v-permission="'outbound_return'"
- 不良品看板「修复回库」   -> v-permission="'defective_restock'"
- 不良品看板「报废销毁」   -> v-permission="'defective_scrap'"

  两个处置按钮是**独立权限**，可能有人只有其一，故分别判定、分别隐藏；
  两者都无时显示「无处置权限」。均保留响应式的 v-if 兜底——v-permission
  只在 mounted 执行一次，而 Element Plus 表格行会重渲染，两者用同一权限码
  判定一致。hasPermission() 内部已对 SUPER_ADMIN 放行，与后端装饰器的
  超管旁路对齐。

  另外去掉了出库记录页原本套用的 username === 'IRIS' 特例放行：退回是实物
  交接的 SOP 动作，后端不认这个特例，前端也不该认，否则会出现「按钮可见但
  接口 403」的错位。

数量显示格式化（新增 utils/format.ts，该文件原本是 0 字节空文件）：
- formatQty()    显示用：1.0000 -> '1'，2.5000 -> '2.5'
- normalizeQty() 数值用：同上但返回 number，供 el-input-number 的
                 v-model / :max —— 喂字符串会让步进与边界比较退化

  应用于 不良品看板（退回总数、剩余待处理、两个弹窗的在管数量与输入框）、
  出库记录页（已退 N 提示、退回弹窗三项数字）、退回记录页（退回数量列）。

  同时移除三个 el-input-number 上的 :precision="4" —— 它会把 1 强制渲染成
  1.0000，是截图上多余小数点的直接来源。数量本身仍支持小数（后端按
  numeric(19,4) 收），只是不再强制补零。

  表格列原本不受影响（接口返回 JSON 数字，1.0 经 JS 解析即 1），但后端有一批
  运算是 float 累加，可能吐出 0.30000000000000004 这类尾巴，格式化按
  numeric(19,4) 量纲先收敛到 4 位再做归一。
 2026-09-16 16:46:20 +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
ffd3e2652c V3.80,9.15推送 2026-09-15 13:27:42 +08:00
yueli
fe54d01391 fix(outbound): 序列号物料出库被误判超出计划数量 
现象：申请单里同一个物料有 2 个，扫第 2 个时报
「超出计划数量（计划: 1，已扫: 1，本次: 1）」。

根因：计划侧与已扫侧用了**不同的聚合方式**。
  已扫侧 .filter().reduce()  → 把【所有】匹配行加总
  计划侧 .find()             → 只取【第一条】匹配行
序列号物料在申请单里是「一物一行、每行 quantity=1」（因为每个序列号对应
一条独立库存行），于是 planQty 只拿到 1，而 alreadyScanned 是全部之和，
1 + 1 > 1 直接判超发。普通数量制物料计划单只有一行，两边一致，所以一直
没暴露 —— 只有序列号物料会踩中。

同一缺陷还有第二处：unscannedList 逐行比较 planQty 与「累计已扫」，
导致两行各自都被同一笔扫码"满足"，扫 1 个就把整个物料判为扫完、未扫清单漏报。

修复：
- validateAgainstPlan：计划侧改为 .filter().reduce() 汇总所有匹配行
- unscannedList：先按「名称+规格」合并计划行，再与同口径汇总的已扫数比较

用申请单 410（Opt1025 两行各 1 个）的真实数据模拟验证：
  修复前 扫第2个 → 超出计划数量（计划:1，已扫:1，本次:1）  ← 与现场报错逐字一致
  修复后 扫第2个 → 通过
  修复后 扫第3个 → 仍被拦（计划:2，已扫:2，本次:1），超发保护未失效
 2026-09-15 13:21:36 +08:00
yueli
b55119acbc V3.79,9.14推送 2026-09-14 17:35:07 +08:00
yueli
0481f917ee fix(stocktake): 修正页面容器高度 —— 真正解决按钮被裁的真根因 
前几轮都在 .idle-card 内层打转（min-height:0 / overflow / padding / 去居中），
全都没打到点上。真根因在页面容器**之外**：

  .app-wrapper  { height:100vh; overflow:hidden }        App.vue
    .app-content { flex:1; min-height:0; overflow:hidden }  ← 高度 = 100vh − 90px
      .app-main  { position:relative }                       ← 无高度
        .app-container { height:100vh }                      ← 就是本页

App.vue 里 .app-header 是 60px、.app-footer 是 30px，所以 .app-content 的实际
高度是 100vh − 90px。而本页容器写死 height:100vh，**比父容器高出整整 90px**，
超出的那一截被 .app-content 的 overflow:hidden 裁掉 —— 【开始新盘点】按钮
恰好就在那一截里，所以看不见也滚不到（滚动条属于被裁掉的那部分）。

改法：height 改为 calc(100vh - 60px - 30px)，两个高度提成 CSS 变量并注明
对应 App.vue 的哪个类，便于外壳改动时同步。

为何不用 height:100%：.app-main 是 auto 高度，百分比无从解析，会退化成 auto。

同时保留前几轮的成果（它们各自都是对的，只是不足以单独解决问题）：
- .idle-card { min-height:0; display:block; overflow:hidden auto }
- .idle-content { margin:0 auto; padding:20px 20px 60px }
- .scope-columns 高度 380 → 260，再省 120px
 2026-09-14 11:10:42 +08:00
yueli
66e0728957 fix(stocktake): 欢迎页补足上下安全边距，显式压过 el-card 的 overflow:hidden 
在 b7cdd5e 的 min-height:0 基础上补两处：

1. 顶部安全边距缺失：内容超高时 .idle-content 的 margin:auto 会塌缩为 0，
   文字直接贴着屏幕顶端。改用**容器自身的 padding: 40px 0** —— padding
   不参与 auto 塌缩，滚到顶/底都稳定保留 40px 呼吸空间。

2. 显式声明两轴 overflow：Element Plus 的 .el-card 默认 `overflow: hidden`
   （实测其 dist/index.css 确有该声明）。原先只写 overflow-y: auto，
   虽然 scoped 选择器（.idle-card[data-v-x]，特异性 0,2,0）能压过
   .el-card(0,1,0)，但意图不够显式。改为 `overflow: hidden auto` 一次写清
   「横向裁掉、纵向可滚」。

实测 style 块编译通过（12799 字符），min-height:0 / padding:40px 0 /
overflow:hidden auto / margin:auto 均已进入产物。
 2026-09-14 11:05:12 +08:00
yueli
b7cdd5e58b fix(stocktake): 补 min-height:0，真正解决欢迎页按钮被裁不可达 
上一轮只加了 overflow-y: auto 和 padding-bottom，没有生效。完整根因链：

  html,body { height:100%; overflow:hidden }   ← src/style.css:61 全局裁剪
    #app { height:100% }
      .app-container { height:100vh; flex column }     ← 自身无 overflow
        .idle-card { flex:1; overflow-y:auto }         ← 缺 min-height:0

flex 子项默认 min-height: auto，会**拒绝收缩到内容高度以下**。于是卡片被内容
撑破 100vh 容器，向上冒泡到 body 的 overflow:hidden 被裁掉 —— 卡片自己的
overflow-y 永远不会触发（它从没比内容矮过），所以按钮既看不见也滚不到。

补上 min-height: 0 后，卡片被约束为「容器剩余高度」，内部滚动才真正生效；
配合子元素的 margin:auto，内容不高时仍居中，超高时从顶部排下且保留
40px 底部安全边距。另加 -webkit-overflow-scrolling: touch 让平板惯性滚动。

注意：没有采用「把 .app-container 改成 overflow-y: auto」的方案 ——
该容器与扫码页的 .active-card 共用，改动会波及扫码态的整屏布局。
本次把修复严格限制在 .idle-card 内。

校验: style 块编译通过；min-height:0 / padding-bottom:40px / margin:auto
      四条关键规则均已进入产物。
 2026-09-14 11:04:06 +08:00
yueli
996ec43360 fix(stocktake): 欢迎页可滚动、明细列合并、弹窗备注组件统一 
【1. 修小屏按钮被截断】
根因不只是缺 overflow —— .idle-card 用了 justify-content: center，
flex 居中在内容超出容器时会把上下两端**同时裁掉**，这才是按钮只剩一半的原因。
改为：容器 overflow-y: auto + padding-bottom: 40px，居中交给子元素的
margin: auto（不高时正常居中，超高时 auto 塌缩为 0，可完整滚动到顶与底）。

【2. 批次/序列号合并为一列】
「批次 / 序列号」min-width=120，两者都有显示「批次 / SN」，只有一个只显示它，
都没有显示 '-'。

【3. 规格列压缩】min-width=120 → width=100 show-overflow-tooltip，给备注让位。

【4. 录入实盘数量弹窗的备注统一为 el-select】
textarea 换成与明细抽屉完全相同的 filterable allow-create
default-first-option 组件，共用同一份 REMARK_OPTIONS。
保存链路不变：inputRemark → syncToBackend → /draft/add（后端本就存 remark）。

★ 顺带修一个数据正确性 bug：openQtyDialog 从不重置 inputRemark，
  工人扫 A 填了备注后**取消**弹窗，再扫 B 时 A 的备注会残留并可能被写进 B。
  改成下拉选项后这个陷阱更隐蔽（离散值不像 textarea 那样扎眼）。
  现两处开窗分支都先清空 inputRemark。
 2026-09-14 10:57:29 +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
af7be6a051 fix(stocktake): 明细里改实盘数时「差异」列实时联动 
原 handleQuantityChange 只发请求，不回写 diff_qty，差异列要重新打开抽屉
才会刷新。

现改为在发请求的同时本地计算：
  row.diff_qty = val - row.stock_qty   （保留 4 位小数，与后端 round 一致，
                                        避免浮点尾差显示成 4.999999999）

★ 盲盘保护：后端在 blind 模式下把 stock_qty 置为 null（绝不下发账面数），
此时**完全跳过**减法，保持 diff_qty 原状（null → 渲染为「—」）。
若不判断，null 参与运算会算出错误差异，等于从 UI 侧绕过了盲盘限制。

请求失败时原有的 fetchInventoryList() 会拉回服务端数据，本地算出的差异
随之被覆盖，不会留下错误值。
 2026-09-11 15:21:45 +08:00
yueli
0e9941a2aa feat(stocktake): 明细抽屉补充「未扫需先扫码」的规则说明 
平板上 title 悬浮提示不生效，只在单元格里显示灰色的「未扫」二字，
工人未必知道下一步该做什么。在抽屉搜索栏下方加一行明文字：

  💡 未扫的行需先扫描条码才能填数
 2026-09-11 15:16:36 +08:00
yueli
04ed489ab5 fix(stocktake): 未扫码的行不允许直接填实盘数 
【问题】盘点明细抽屉列出全部在范围内的物料，其中尚未扫码的行也可以
直接在「实盘数」列填数字。填完前端发 POST /stocktake/update-quantity，
后端只会 UPDATE 已存在的草稿行、找不到就返回 404「未找到盘点记录」，
于是工人填的数字根本没保存，只弹一句「更新失败」。

【为什么不改成 UPSERT】那等于允许不扫码就填数 —— 任何人照账面抄一遍
就能"完成"盘点，扫码这道工序形同虚设，盘盈盘亏也无从查起。
所以这里保持"必须先有草稿行"的语义，改为在 UI 上把这条路堵住。

【改动】
- 前端：draft_id 为空的行不再渲染 el-input-number，改显示灰色「未扫」；
  已扫行照常可改。失败时提示改为透传后端 msg，并 fetchInventoryList()
  回滚本地被 v-model 改动的值。
- 后端：404 文案由「未找到盘点记录」改为
  「该物料尚未扫码，请先扫描条码后再修改实盘数」，作为绕过前端时的兜底。

实测:
  draft_id 已扫行=11379 → 可编辑；未扫行=None → 不可编辑
  绕过前端直接改未扫行 → 404 该物料尚未扫码，请先扫描条码后再修改实盘数
 2026-09-11 15:15:05 +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
d1694bf245 perf(stocktake): 去掉库位树的全展开渲染，并为推荐查询补索引 
业务反馈切到抽盘面板与点【获取推荐】时卡顿。实测定位：

【真正的原因在前端】先跑 EXPLAIN ANALYZE 排除了后端 ——
推荐查询在当前数据量下仅耗时 1.3ms，全走 Seq Scan + Hash Join，
Buffers shared hit=161 全部命中缓存。所以卡顿来自 DOM：
el-tree 原先带 default-expand-all，会把全库 3371 个库位节点一次性铺进 DOM。

去掉 default-expand-all 后初始只渲染根节点。勾选状态与 getCheckedNodes
不受影响 —— el-tree 的 Node store 会预先构建全树，展开与否只影响 DOM。

【索引仍补上，但说明白】实测 pg_indexes：stock_* 三表的 warehouse_location
已有索引，但 trans_outbound / trans_borrow 只有主键，时间字段与
(source_table, stock_id) JOIN 键都缺；三张库存表的时间字段也缺。
新增迁移 add_active_location_indexes.sql 补 7 个索引。

诚实说明写在迁移头部：当前数据量下加索引后本查询**仍会走 Seq Scan**，
这是小表下的正确计划，索引是为 90 天/半年后的数据增长做前瞻，不是修当前的慢。

【loading 状态】treeLoading / recLoading 已在既有实现中就位并闭环在
try/finally 中，分别绑在 el-tree 的 v-loading 与【获取推荐】按钮的 :loading 上，
本轮复核确认，未做无谓改名。

实测: 索引后执行计划仍为 Seq Scan，Execution Time 0.769ms（预期内）
 2026-09-11 14:38:40 +08:00
yueli
0b82609c55 fix(stocktake): 抽盘配置区定高不跳动，勾选只计末级库位 
【固定高度】.scope-columns 设 height: 380px + display: flex，左右两栏各自
flex:1 + overflow 独立滚动。关键点是给 flex 子项加 min-height: 0 —— 不写它
flex 子项默认不收缩，overflow 不会生效，高度照样被内容撑开。
原先树用 max-height: 300px、右栏用 height: 260px 各写各的，仍会随内容跳动。

【只计末级库位】syncSelectedPaths / buildScopeConfig 均改用
getCheckedNodes(true)（leafOnly）。勾选父级货架时右侧计数与提交给后端的
scope_config.locations 都只含末级库位，不再把父节点自身算进去 ——
符合现场「货架是容器、库位才是盘点对象」的心智模型。

上一轮我曾以「非末级库位上有库存，leafOnly 会漏」为由建议不做，该判断
是错的：我把「层级」当成了「非末级」。实测这棵库位树深度不均匀，很多
level 1/2 的节点本身就是叶子 —— 真正存放在非末级库位上的库存，
IRIS 1126 行里仅 1 行(0.1%)、LICA 690 行里 0 行，排除面可忽略。

（活跃天数可编辑已在 709aeef 完成：recommendDays 默认 90、动态传参。）
 2026-09-11 14:33:23 +08:00
yueli
709aeefeda feat(stocktake): 活跃天数可编辑（默认 90 天）并补充勾选提示 
- 把写死的 30 天改为响应式 recommendDays（默认 90，范围 1~365），
  界面上是一个 el-input-number；【获取推荐】按 ?days=<recommendDays>&top_n=<N>
  动态传参，不再固定 30。
- 推荐条数默认由 50 调整为 10（与「前 N 个」的实际使用节奏一致）。
- el-tree 上方加一行灰色小字提示：
  「💡 提示：勾选父级货架，将自动涵盖其下属的所有末级库位及库存。」
  对应已确认的决策——保持 el-tree 原生级联、后端精确匹配，
  勾父节点时其全部子孙 full_path 都会进入提交范围，故提示属实。

已确认的两项决策（本轮无代码改动，记录备查）：
- 不使用 check-strictly，保留原生级联；右侧计数已足以提示规模
- 后端保持精确匹配，不做前缀匹配
 2026-09-11 14:29:13 +08:00
yueli
80bd45d5d4 feat(stocktake): 抽盘库位选择改为左右双栏，已选明细可逐个移除 
原库位树是单列、层级很深，用户勾完看不出到底选了哪些库位。

现改为左右双栏：
- 左 60%：el-tree（勾选），@check 触发 syncSelectedPaths
- 右 40%：已选明细面板 —— 顶部「已选 N 个库位」+ 清空按钮，
  el-scrollbar 内平铺 el-tag 展示完整路径（等宽字体）

双向互动：点击右侧标签的 × 会调 treeRef.setChecked(path, false, true)
同步取消左侧勾选后重算列表。注意 el-tree 的 setCheckedKeys / setChecked
都**不会**触发 @check 事件，因此这两处都显式调用了 syncSelectedPaths()，
保证左右状态强同步（获取推荐后右侧也会立刻渲染）。

★ 右侧刻意**不过滤非末级节点**，展示的就是提交给后端的 scope_config.locations
全集。原因：后端按 warehouse_location 精确匹配，而库存的库位可能落在层级 1/2
（实测 level1 有 9 个、level2 有 57 个），只提交叶子路径会把这些库存静默排除
在抽盘范围之外。面板所见 = 实际范围，才谈得上「强同步」。

配套：抽盘配置区是双栏、400px 窄容器装不下，故在展开该配置时把欢迎页
放宽到 780px（.idle-content.is-wide），其他状态维持原宽度。
 2026-09-11 14:22:14 +08:00
yueli
e9468673c0 feat(stocktake): 抽盘范围改为「系统推荐 + 人工在库位树上勾选」 
【后端】
- 新增 GET /stocktake/recommend-locations?days=30&top_n=50
  调 get_active_locations 返回推荐库位 full_path 列表 + moves/sku_count/
  last_move 明细。只推荐不落库，days/top_n 做范围钳制（1~365 / 1~500）。
- /draft/start-new 在 scope_type=active 时不再自行计算活跃库位，改为读取
  payload 的 scope_config.locations 并校验归一化（去空白、去重、保序、
  空列表 400、上限 2000）。范围决定权交还前端 UI —— 否则用户手改的勾选
  会被后端覆盖。

【前端】欢迎页选中「活跃库位抽盘」时展开配置区：
- 「近 30 天最活跃的前 [N] 个库位」+【获取推荐】
- el-tree（show-checkbox）数据取自 /v1/warehouse/tree，按公司前缀过滤
  （IRIS 只留 Y*，LICA 只留 C*/L*，复用 getAllowedLocPrefixes）
- 获取推荐后 setCheckedKeys 自动勾选；用户可自由增删
- 提交时 getCheckedNodes().map(n => n.full_path) 打包进 scope_config.locations

两个实现细节：
- 推荐里有、但树上勾不到的库位（不在当前公司前缀内等）会明确告警并打印，
  不让它们静默落选 —— 否则工人以为盘到了、实际没进范围。
- 已选库位数实时显示，因为 el-tree 默认级联：勾一个父节点会连带勾中整棵
  子树，规模可能远超推荐数量，需要让用户看得见。

实测:
  recommend-locations(top_n=10) → 10 个库位 + 明细
  start-new 传 3 个库位 → 落库正是这 3 个，总品项 36（全仓 1126）
  不传 locations → 400；勾选为空 → 400
  公司前缀过滤: IRIS→8 个(Y1~Y8)，LICA→25 个，无越界
 2026-09-11 14:13:10 +08:00
yueli
325cc44469 fix(stocktake): 拉开主副按钮层级防误触，明细增加库位列 
【按钮层级】场景 A（已有进行中的盘点）
原实现主按钮是「加入当前盘点」，次入口是个不起眼的文字链接
「开启新一轮盘点」—— 二者视觉权重接近，而后者会终结本司其他 PDA
正在使用的会话，误触代价高。

现改为：
- 主按钮：绿色「继续当前盘点」，高度放到 66px、字号 19px
  （新增 .action-btn-hero），平板大屏上一眼可辨、一按即中
- 次按钮：红色镂空「结束当前并开启新盘点」，点击走 10 秒倒计时强确认
- 确认弹窗措辞由「原有数据将保留」改为明确告知**会话将被终结**：
  「该会话将标记为已结束，其他设备不能再加入」
- 倒计时确认通过后展开配置表单（而非直接开会话），让用户仍能选模式/范围；
  表单提交不再二次弹窗，避免重复确认

【库位列】明细抽屉新增「库位」列，紧跟规格之后 —— 找货刚需。
后端 merged-list 已下发该字段，实测单行返回含 warehouse_location='Y2/4/3/4'，
无需改动。
 2026-09-11 13:53:53 +08:00
yueli
eabe70b00a feat(stocktake): 落地动盘（活跃库位抽盘）与导出盲盘保护 
【导出收尾】/export-stocktake
会话 active 且 mode=blind 时，汇总表/差异明细/账实相符/未盘点四张 Sheet 的
账面数与差异数一律输出 '—'，实盘数照常输出。会话 finished 后自动解锁 ——
盘点结束后核对差异是正常流程，否则报告本身没法用。
批量替换时误伤了 update_stocktake_quantity 里的差异计算，被静态检查脚本
抓出（会拿占位符 '—' 做减法），已改回按真实账面值计算。

【动盘算法】get_active_locations(company_name, days=30, top_n=50)
近 N 天异动最频繁的库位。出库经 (source_table, stock_id) 回查库存表取库位
（trans_outbound.warehouse_location 历史上 900 条里 829 条为空，实测回查
覆盖率 298/299）；入库以库存表自身的 in_date / production_date 计时；
借出用 trans_borrow.location。报废/维修表无库位字段，未纳入。

【范围冻结】/draft/start-new
移除 scope_type=active 的 400 拦截，改为在开单时算出活跃库位并**冻结**进
scope_config。必须开单时算好 —— 若各接口实时计算，两次调用之间活跃度变化
会导致范围漂移，结束盘点时把已掉出范围的库存误判成盘亏。

【同源过滤】all-items / merged-list / generate-missing
三者都读同一份冻结的 scope_config。generate-missing 是重中之重：漏盘比对
只针对范围内库存，绝不把范围外未盘库存标成盘亏。
merged-list 一并加了过滤（原指令未提），否则抽屉仍会列出范围外物资，
与「总品项」对不上。

【前端】移除「活跃库位抽盘」的 disabled。

实测（IRIS，全仓 1126 → 抽盘 537）：
  生成盘亏 537 条 | 落在抽盘范围内 537 | 落在范围外 0
  导出: 盲盘 active → 账面数/差异数 = '—'；盲盘 finished → 76 / -76（解锁）
 2026-09-11 13:41:56 +08:00
yueli
97c1a9131c feat(stocktake): 明/盲盘由后端强制驱动，前端解除屏蔽 
原实现是前端把「账面数」「差异」两列用 HTML 注释藏掉 —— 数据仍在
HTTP 响应里明文下发，抓包或用改过的客户端即可看到，等于没有屏蔽。

【后端】/draft/merged-list 先查该 session_id 的 StocktakeSession.mode：
- blind：stock_qty 与 diff_qty 一律置 None，真实账面数不出现在响应中
- open ：正常下发
差异必须一并置空 —— diff_qty 由账面数算出，下发差异等于变相泄漏账面数。
响应新增 data.mode 供前端提示。

Fail-Safe：查不到会话行时按盲盘处理。宁可界面少显示两列，也不能因为
会话记录缺失就把账面数泄漏出去。

【前端】删除屏蔽用的 HTML 注释，恢复两列正常渲染，不再承担数据屏蔽职责。
但 null 必须渲染为「—」而非 0：原 差异 模板用 `row.diff_qty || 0`，
会把「未下发」显示成「无差异」，工人会误以为账实相符。
另在抽屉表头加模式标签，便于核对。

实测:
  盲盘 → 账面数=None 差异=None   mode=blind
  明盘 → 账面数=1.0  差异=-1.0   mode=open
  未知 session_id → 同盲盘（Fail-Safe 生效）
 2026-09-11 13:34:36 +08:00
yueli
091847596e feat(stocktake): 欢迎页改为创建盘点任务表单 
无活跃会话时不再只有一个孤零零的按钮，而是先配置再开始：

- 盘点模式：明盘 / 盲盘，默认明盘
- 盘点范围：全仓盘点 / 活跃库位抽盘

有活跃会话时表单隐藏，显示绿色「加入当前盘点」，提示语带出该会话的
模式与范围（如「盲盘 · 全仓盘点，已扫 12 件，发起人：韩善龙」）。
次要入口「开启新一轮盘点」改为展开配置表单，并在表单内提示
「开启新一轮会把当前进行中的盘点置为已结束（历史数据仍保留）」，
提交时仍走原有的 10 秒确认弹窗。

「活跃库位抽盘」选项置灰并注明原因：范围过滤尚未实现，此时若放开，
结束盘点会把抽盘范围外的全部库存批量标成盘亏。后端同样以 400 拦截，
前后端一致，避免绕过 UI 直接调接口。

activeSession 类型与 checkServerDraft 同步补上 mode / scope_type。
 2026-09-11 13:28:53 +08:00
yueli
cc176f6e8b fix(stocktake): 扫码落库改为确认后反馈，并增加最近扫码记录 
【修复静默丢数据】
原 syncToBackend 是乐观更新：addDraft 还没返回就先弹「已记录实盘」，
UI 提示早于落库确认。网络抖动时工人以为扫进去了，这条实盘记录实际已丢，
而状态标签还可能被后续成功的请求覆盖成绿色，失败也无人重试。

现改为：
- 只有 addDraft 真正 resolve 后才提示成功、记流水、刷统计
- catch 时用 10 秒停留 + 可关闭的错误提示，明确告知
  「网络异常，上一笔条码 [XXX] 录入失败，请重试！」

【新增最近扫码记录】
统计看板下方增加 recentScans（最多 10 条），落库成功后 unshift
物料名称/规格/数量/时间，用轻量列表展示并高亮最新一条，
供安卓平板大屏即时确认。切换/加入会话时清空，避免看到上一轮残留。

【统一统计口径】
totalScannedCount 原被 all-items 与 merged-list 两处写入。核对后端
两个接口的 SQL 实际完全一致（均为 COUNT(DISTINCT (source_table, stock_id))
且都包含 system 自动漏盘记录），故数值本身不会分歧；但仍去掉 all-items
那一处写入，统一由 merged-list（fetchInventoryList）作为唯一来源。

【清理死代码】
删除从未使用的 allScannedDrafts 与 listTotal。
 2026-09-11 13:20:15 +08:00
yueli
5b0c7c1382 feat(stocktake): 欢迎页识别跨域角色，完善场景 A 提示 
- 公司选择器原先只对 SUPER_ADMIN 解锁，漏掉了同样持有 crossDomain
  权限的 WAREHOUSE_MGR —— 它同样不受后端公司隔离约束，盘点范围完全
  由所选公司决定，必须一并要求显式选择。
  注意 SUPER_ADMIN 的权限是通配符 ['*']，permissions.includes('crossDomain')
  对其恒为 false，故角色与权限码两个条件都要判。

- 场景 A 提示改为「当前公司已有盘点在进行中，已扫 XXX 件，发起人：XXX」，
  使用后端新增的 scanned / initiator 字段（scanned 已排除系统自动漏盘记录）。
  按钮文案统一为「加入当前盘点」。

- 清理 serverDraftCount：提示语改用 activeSession.scanned 后它只写不读，
  属死状态，一并移除。

- 确认弹窗文案原先指向已不存在的「继续上次盘点」入口，改为说明开新会话后
  「加入当前盘点」只会进入最新会话。
 2026-09-11 12:44:10 +08:00
yueli
97ff63523c fix(export): 公司隔离移出 if filters 判定，确保无条件执行 
export_excel 的行级公司隔离原本嵌套在 `if filters:` 内部：
只要调用方不传或传空筛选条件，整段隔离会被跳过且不抛错 —— 静默失效。
（实测: 修复前 export_excel({}, None) 会导出跨公司全部 1816 行。）

现把 get_current_company_filter() 及其 filter_conditions.append 提到
if filters: 之前，无论有无筛选条件都绝对执行。

同时清理路由里 filters 字典的 'company' 死键 —— export_excel 从不消费它，
真正生效的是 get_current_company_filter() 直接读 request.args 上的公司标识。

注意：前端 handleExport 的 company 参数必须保留（已在代码中加注说明）。
实测 WAREHOUSE_MGR 带 ?company=IRIS 导出 1126 行仅 IRIS，不带则 1816 行
涵盖 IRIS+LICA —— 跨域角色按公司收窄范围完全依赖这个 query 参数。

实测(修复后):
  SALES/IRIS          filters={}          → 1126 行, 仅 IRIS
  SALES/IRIS          filters={keyword:''}→ 1126 行, 仅 IRIS
  WAREHOUSE_MGR       ?company=IRIS       → 1126 行, 仅 IRIS
  WAREHOUSE_MGR       (无参数)            → 1816 行, IRIS+LICA
 2026-09-11 12:41:27 +08:00
yueli
f7cae9d84e fix(stocktake): 探测会话失败时不再静默降级为「无盘点」 
checkServerDraft 原本在请求异常时把 activeSession 置空，界面于是从绿色
「加入正在进行的盘点」退回蓝色「开始新盘点」—— 网络抖动一下，库管点下去
就会新建会话，把多人协同拆开。

现把「探测失败」独立成 probeFailed 状态：失败时保持 activeSession 不变，
界面切到「无法确认是否有进行中的盘点 + 重新检测」，不提供进入按钮。
宁可挡住操作，也不能让库管误开新会话。
 2026-09-11 11:39:35 +08:00
yueli
32cb5469c4 feat(stocktake): 欢迎页改为公司维度状态驱动，多设备共享盘点会话 
原入口只有一个「开始新盘点」，多台 PDA 各开各的会话，无法协同。

- 新增公司选择器：普通用户锁定并默认本公司（后端本就强制隔离），
  超管必须显式选择，未选时入口按钮禁用；本公司若不在下拉列表中
  则补进去，避免 el-select 显示为空。
- 选定公司后调用 /draft/active-session 探测该公司是否已有进行中的
  盘点。服务端为唯一事实来源，localStorage 仅作缓存。
- 状态驱动渲染入口按钮：
  场景 A（已有活跃会话）→ 绿色「加入正在进行的盘点」，并提示当前
    进度项数；同时保留次要入口「开启新一轮盘点」，否则公司一旦有过
    草稿就永远开不了新一轮，点击走 10 秒确认弹窗。
  场景 B（无活跃会话）→ 蓝色「开始新盘点」。
- 切换公司时清空本地会话并重新探测，避免跨公司串会话。
- 移除此前「刷新后请求 /draft/list 取第一条草稿猜 session_id」的逻辑：
  该列表无会话/用户过滤，取到的是全库 SKU 字典序最小的那条草稿，
  与当前用户和公司都无关。
- 所有盘点请求携带当前公司；导出、生成漏盘、改实盘数等 POST 请求
  亦经 query string 传递公司。
 2026-09-11 11:33:26 +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
c6694043d4 V3.78,9.11推送 2026-09-11 10:35:34 +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
b8561f69f7 V3.77,9.11推送 2026-09-11 09:39:59 +08:00
yueli
e5a7cb2736 V3.76,9.11推送 2026-09-11 09:07:14 +08:00
yueli
ce767e39ac feat(scan): 扫码时检测单据失效，避免白扫一场 
场景
----
库管正在扫码，这张单被撤回/驳回/执行了。若不检测，库管会一直扫到
提交时才发现单据已作废（后端会拒绝），前面的工作白做。

实现
----
新增 checkRequestStillValid()：重新拉一次「已通过(status=1)」列表，
看当前单据是否还在其中。不在 → 已被撤回/驳回/执行，立即弹窗告知并
清空界面（草稿后端也已同步清除）。复用现有列表接口，无需新增端点。

触发时机（覆盖两类场景）：
  · 页面重新可见时（visibilitychange）—— PDA 熄屏唤醒、切回标签页
  · 每 60 秒一次 —— 库管一直在页面上扫、没切走

三点取舍：
  · 仅购物车非空时检测（正在作业才打扰），空清单不发请求；
  · 60 秒轮询而非实时推送 —— 引入 WebSocket 长连接成本过高，
    此处最多浪费 1 分钟扫码，相比"扫完几十分钟才发现"已足够；
  · 检测失败不阻断作业（仅 console.warn）—— 后端提交时仍会做最终校验，
    前端检测是为了早发现，不是安全防线。

出库 create.vue 与借库 borrow.vue 两页同款实现。
 2026-09-11 09:06:51 +08:00
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
a07432981e feat(borrow): 扫码借库页的清单对齐扫码出库页 
问题
----
扫码借库页（views/transaction/borrow.vue）的「审批计划清单」与扫码出库页
的「计划出库清单」样式不一致：

  · 标题：审批计划清单 / 计划出库清单
  · 类型列：借库有、出库已删
  · 数量列：借库用「审批数量」且排在最右；出库是「计划数量」且前置
  · 备选库位：借库没有
  · 清单容器：借库灰底 #f5f7fa，出库是淡绿 #f0f9eb + 边框

改动（五项全部对齐）
--------------------
· 标题改为「计划借用清单」；
· 移除「类型」列；
· 「计划数量」前置到序号之后，橙色 #E6A23C 加粗 15px；
· 新增备选库位：库位格子整体可点击 + popover（与出库页逐字相同的实现）；
· 清单容器改为淡绿背景 #f0f9eb + #e1f3d8 边框 + 圆角，标题绿色加粗。

备选库位复用了出库模块的 /alternatives 端点。已核实前提：借库申请单的
items_json 由预占改造写入 base_id / stock_id / source_table，故「推荐/备选」
标注可正常工作（对历史单据无这些字段时会安全回退为纯文本）。

定位说明
--------
借库有三个页面（选单 / 扫码 / 审批），上一轮按「计划清单」关键词搜索时
命中了审批页的展开行，改错了位置。本提交修正的是真正的扫码借库页。
 2026-09-10 16:17:50 +08:00
yueli
f8267c6ee2 style(borrow): 审批页物料明细数量前置，清单标题对齐出库 
背景
----
借库审批页展开行的「计划数量」排在表格最右（库位之后），与扫码出库页
的前置做法不一致 —— 列多时容易被容器裁掉，工人看不到数量。

改动
----
· 计划数量从最右移到序号之后，橙色加粗 + 字号 15px；
· 清单标题由朴素文字改为与出库页同款的标题栏结构
  （planned-header + planned-title + 绿色标签）；
· 补上 .planned-header / .planned-title 样式定义（该页原先没有）。

注：本轮定位时曾误以为这是用户反馈的「扫码借库页」，实际扫码借库页是
views/transaction/borrow.vue（见下一提交）。此处是同类问题的另一处，
一并修正，非误改。
 2026-09-10 16:17:42 +08:00
yueli
eeefaeb528 V3.74,9.10推送 2026-09-10 15:59:13 +08:00
yueli
d69ec9f5ec style(outbound,borrow): 库位格子整体可点击，图标放大 
问题
----
备选库位浮层的触发区原先只有一个小图标（默认 1em），工人需要精准
点击才能弹出 —— 戴手套或在触屏上操作时命中率很低。

改动
----
· #reference 从「仅图标」改为「库位文字 + 图标」整体，
  点格子任意位置都能弹出；
· 悬停时整格高亮（#ecf5ff），给出可点击的视觉反馈；
· 图标放大到 18px；
· 库位文字着蓝色（#409EFF），并加 title 提示；
· 无 base_id 时回退为纯文本（历史单据）——原先这种情况下会渲染空白。

出库执行页与借库审批页同款实现，一并同步。

注：编辑过程中曾因残留旧的 popover 闭合标签导致模板结构损坏
（SFC PARSE ERR），已通过编译检查发现并修复。
 2026-09-10 15:57:26 +08:00
yueli
ea52c78f9e feat(outbound): 计划出库清单数量前置，移除类型列 
问题
----
计划出库清单的「计划数量」列排在表格最右侧（名称/规格/库位之后）。
表格共 6 列且名称规格会撑宽，最右列容易被容器裁掉，工人反馈"看不见数量"。

改动
----
· 「计划数量」从最右移到「序号」之后，橙色加粗 + 字号放大到 15px；
· 移除「类型」列（material_type）；
· 库位列宽 150 → 170。

注：该列一直存在且数据正常（items_json 的 quantity 字段），
此前是可见性问题而非数据缺失。
 2026-09-10 15:57:20 +08:00
yueli
851c3a9c1f feat(my-requests): 主列表展示数量，移除类型列 
问题
----
主列表只有「物料数 N 种」（种类数），具体数量藏在展开行的明细表里，
不展开就看不到。

改动
----
· 移除「类型」列（type_label）；
· 新增「数量」列，紧跟申请单号，橙色加粗；
· 新增 totalQty() 汇总单据总数量。

totalQty 只认 quantity 字段，无需按 type 分支 —— 因为聚合端点已做字段
归一化（报废的 scrap_qty → quantity）。这正是当初做归一化的价值。
数值经 Number(sum.toFixed(4)) 处理，去掉 1.0000 这类无意义的小数尾巴。

顺带移除已无引用的 typeTagType()。
 2026-09-10 15:57:15 +08:00
yueli
dc4a0ae7a0 style: 统一申请单状态配色（四个页面一致） 
配色方案
--------
  0 待审批 → 蓝（primary，待处理）
  1 已通过 → 绿（success，正向结果）
  2 已驳回 → 红（danger）
  3 已完成 → 灰（info，终态、不再需要关注）
  4 已撤回 → 黄（warning，需留意但非错误）

范围
----
「我的申请单」新页面按上述配色实现后，发现出库/借库/报废三个审批页
仍是旧配色（0:warning, 3:info, 4:info）—— 同一套状态码在两个页面
显示不同颜色，用户来回切换会困惑。故一并统一。

改动：my-requests/index.vue（新配色）+ 三个审批页的 statusTagType。

补充：el-tag 的 primary 类型已核实可用 —— Element Plus 2.13.1 的
tagProps 中 primary 为默认值，theme-chalk/el-tag.css 含 .el-tag--primary
的蓝色样式定义；vue-tsc 类型检查通过。
 2026-09-10 15:47:07 +08:00
yueli
c999aac1e3 fix(scrap): 撤回按钮改用 scrap_approval 权限，修正错配 
报废审批页的「撤回」按钮原先复用了执行按钮的 canExecute 条件
（scrap_execute）。但 scrap_execute 比 scrap_approval 多授予 INBOUND 角色 ——
意味着只具备执行权、无审批权的人也会看到撤回按钮。

撤回是对单据的处置动作，应与审批同权限等级。新增 canWithdraw 计算属性
（SUPER_ADMIN 或 scrap_approval），替换原 canExecute。

注：申请人在「我的申请单」页有自己的撤回入口，走的是单据归属校验，
不依赖此处权限。
 2026-09-10 15:37:17 +08:00
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