704 Commits

Author	SHA1	Message	Date
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
yueli	8c18586a94	feat(borrow): 借库审批页备选库位，与出库保持一致 ... 借库的执行入口在审批页 —— 展开行即为工人查看/去扫码的物料明细。 申请单已把货预占在某库位，工人现场可能进不去，需要改扫同物料的其它 批次（后端执行端按 base_id 校验身份、允许换批次），但改造前系统不告诉 他还有哪些库位有货。 复用出库模块的 /api/v1/outbound/alternatives 端点（逻辑完全一致： 按 available_quantity > 0 过滤，只给真正能拿的库位，排除已被别单占满的行）， 在明细表的库位列加图标 + popover： [推荐] L5/1/2/1 可用 840 ← 本单锁定行 [备选] L2/1/2/1 可用 1 与出库页同款取舍： · trigger="click" —— 车间用扫码枪/触摸屏，hover 在触屏不可用 · @show 时才发请求 —— 展开单据时不会打出一片并发查询 · 附提示文案「现场取不到推荐库位时可直接扫备选库位条码借用」 注：借库申请经预占改造后 items_json 已带 base_id/stock_id/source_table， 故推荐行可正确标注；改造前的历史单无这些字段，此时全部显示为「备选」。	2026-09-10 15:02:22 +08:00