|
|
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 |
|
|
|
ffd3e2652c
|
V3.80,9.15推送
|
2026-09-15 13:27:42 +08:00 |
|
|
|
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 |
|
|
|
b55119acbc
|
V3.79,9.14推送
|
2026-09-14 17:35:07 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
0e9941a2aa
|
feat(stocktake): 明细抽屉补充「未扫需先扫码」的规则说明
平板上 title 悬浮提示不生效，只在单元格里显示灰色的「未扫」二字，
工人未必知道下一步该做什么。在抽屉搜索栏下方加一行明文字：
💡 未扫的行需先扫描条码才能填数
|
2026-09-11 15:16:36 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
091847596e
|
feat(stocktake): 欢迎页改为创建盘点任务表单
无活跃会话时不再只有一个孤零零的按钮，而是先配置再开始：
- 盘点模式：明盘 / 盲盘，默认明盘
- 盘点范围：全仓盘点 / 活跃库位抽盘
有活跃会话时表单隐藏，显示绿色「加入当前盘点」，提示语带出该会话的
模式与范围（如「盲盘 · 全仓盘点，已扫 12 件，发起人：韩善龙」）。
次要入口「开启新一轮盘点」改为展开配置表单，并在表单内提示
「开启新一轮会把当前进行中的盘点置为已结束（历史数据仍保留）」，
提交时仍走原有的 10 秒确认弹窗。
「活跃库位抽盘」选项置灰并注明原因：范围过滤尚未实现，此时若放开，
结束盘点会把抽盘范围外的全部库存批量标成盘亏。后端同样以 400 拦截，
前后端一致，避免绕过 UI 直接调接口。
activeSession 类型与 checkServerDraft 同步补上 mode / scope_type。
|
2026-09-11 13:28:53 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
f7cae9d84e
|
fix(stocktake): 探测会话失败时不再静默降级为「无盘点」
checkServerDraft 原本在请求异常时把 activeSession 置空，界面于是从绿色
「加入正在进行的盘点」退回蓝色「开始新盘点」—— 网络抖动一下，库管点下去
就会新建会话，把多人协同拆开。
现把「探测失败」独立成 probeFailed 状态：失败时保持 activeSession 不变，
界面切到「无法确认是否有进行中的盘点 + 重新检测」，不提供进入按钮。
宁可挡住操作，也不能让库管误开新会话。
|
2026-09-11 11:39:35 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
c6694043d4
|
V3.78,9.11推送
|
2026-09-11 10:35:34 +08:00 |
|
|
|
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 |
|
|
|
b8561f69f7
|
V3.77,9.11推送
|
2026-09-11 09:39:59 +08:00 |
|
|
|
e5a7cb2736
|
V3.76,9.11推送
|
2026-09-11 09:07:14 +08:00 |
|
|
|
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 |
|
|
|
6f2f077751
|
feat(purchase): 采购页搜索区对齐出库记录版式
原顶部工具栏是裸 div + 状态单选，现改为 el-form :inline 版式，与出库记录 /
报废记录一致：
状态 全部 / 待审批 / 已通过 / 已驳回 / 已完成 / 已完结
搜索 [搜索类型下拉] + 关键词输入，500ms 防抖
采购日期 日期范围选择
按钮 查询 / 重置 / 新建采购申请
交互细节：
· 搜索类型切换、清空输入时立即查询（取消防抖等待）；
· 「重置」恢复默认的「待审批」状态（该页默认视图），而非清成"全部"——
与页面初始状态保持一致；
· 重置同时清空关键词、搜索类型、日期范围。
api/purchase.ts 的 getPurchaseList 补充新参数的类型定义。
|
2026-09-10 17:41:29 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
f8267c6ee2
|
style(borrow): 审批页物料明细数量前置，清单标题对齐出库
背景
----
借库审批页展开行的「计划数量」排在表格最右（库位之后），与扫码出库页
的前置做法不一致 —— 列多时容易被容器裁掉，工人看不到数量。
改动
----
· 计划数量从最右移到序号之后，橙色加粗 + 字号 15px；
· 清单标题由朴素文字改为与出库页同款的标题栏结构
（planned-header + planned-title + 绿色标签）；
· 补上 .planned-header / .planned-title 样式定义（该页原先没有）。
注：本轮定位时曾误以为这是用户反馈的「扫码借库页」，实际扫码借库页是
views/transaction/borrow.vue（见下一提交）。此处是同类问题的另一处，
一并修正，非误改。
|
2026-09-10 16:17:42 +08:00 |
|
|
|
eeefaeb528
|
V3.74,9.10推送
|
2026-09-10 15:59:13 +08:00 |
|
|
|
d69ec9f5ec
|
style(outbound,borrow): 库位格子整体可点击，图标放大
问题
----
备选库位浮层的触发区原先只有一个小图标（默认 1em），工人需要精准
点击才能弹出 —— 戴手套或在触屏上操作时命中率很低。
改动
----
· #reference 从「仅图标」改为「库位文字 + 图标」整体，
点格子任意位置都能弹出；
· 悬停时整格高亮（#ecf5ff），给出可点击的视觉反馈；
· 图标放大到 18px；
· 库位文字着蓝色（#409EFF），并加 title 提示；
· 无 base_id 时回退为纯文本（历史单据）——原先这种情况下会渲染空白。
出库执行页与借库审批页同款实现，一并同步。
注：编辑过程中曾因残留旧的 popover 闭合标签导致模板结构损坏
（SFC PARSE ERR），已通过编译检查发现并修复。
|
2026-09-10 15:57:26 +08:00 |
|
|
|
ea52c78f9e
|
feat(outbound): 计划出库清单数量前置，移除类型列
问题
----
计划出库清单的「计划数量」列排在表格最右侧（名称/规格/库位之后）。
表格共 6 列且名称规格会撑宽，最右列容易被容器裁掉，工人反馈"看不见数量"。
改动
----
· 「计划数量」从最右移到「序号」之后，橙色加粗 + 字号放大到 15px；
· 移除「类型」列（material_type）；
· 库位列宽 150 → 170。
注：该列一直存在且数据正常（items_json 的 quantity 字段），
此前是可见性问题而非数据缺失。
|
2026-09-10 15:57:20 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
24b7fd8373
|
fix(audit): 模块下拉中文化，消除 image_embeddings 等英文遗留值
问题
----
模块筛选下拉仍出现 image_embeddings、purchase_request、sys_element 等
英文值。它们来自改造前的全局监听器：那时无白名单，系统表/草稿表/向量表
都会被审计，而 _infer_module_name 对未登记的类名直接回退成表名。
下拉取 DISTINCT module，这些英文值就混了进来。
处理
----
新增 moduleMap（21 项）+ moduleLabel()，并应用到**三处**渲染：
下拉选项、列表列、详情弹窗的模块标签。
value 保留原始字符串，筛选行为完全不变。
除覆盖现存 3 个英文值外，另预置了 18 个白名单表名（sys_user / stock_buy /
trans_outbound 等）。新监听器已保证 module 为中文，但若将来有数据从旧
路径写入或手工导入，这些值会再次出现，预置可避免同类问题复发。
其中 image_embeddings 标注为「图像特征(历史)」以提示其为改造前的产物。
实测：image_embeddings → 图像特征(历史)，purchase_request → 采购申请，
sys_element → 系统元素；中文模块名原样保留。
|
2026-09-10 14:59:22 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
6068625562
|
feat(audit): 审计日志业务化——对象名与字段中文化、操作来源与类型筛选
一、target_name 业务化（后端 audit_listener.py）
优先级：业务标识（request_no/outbound_no/borrow_no/sku/bom_no…）→
名称字段 → 关联物料名 → 「中文表名 - 业务号或ID」。
新增 TABLE_LABELS 表名到中文的映射（18 张白名单表全覆盖）。
用户看到的从 scrap_approval ID:371 变为
「出库申请单 - APR-OUT-20260805-1550-0005」这类可理解的对象描述。
二、前端字段中文化（AuditLog.vue）
· fieldMap 由 11 项扩充到 110+ 项，覆盖审批单/流水/库存/主数据/系统管理五类；
· 修复关键 bug：fieldMap 原先只作用于「变更对比」区，「删除快照」与
「新增详情」两区直接渲染原始 key（label 直接取 String(key)），
这正是详情里满是英文列名的直接原因。现三区统一经 fieldLabel() 取值。
三、时间显示修正
后端已改写北京时间，前端原先补 Z 当 UTC 解析会造成二次 +8 小时，
改为按 +08:00 理解该字符串。
四、新增两类筛选
· 操作来源（真实用户 / 系统操作 / 全部），默认「真实用户」。
历史存量含约 1.8 万条 username=system 的噪声日志，会把列表刷屏。
· 操作类型别名归一：历史数据中 action 有两套写法（早期装饰器写中文
新增/修改/删除，现行监听器写大写 CREATE/UPDATE/DELETE），导致下拉
同时出现二者、且选中文项只能搜到 3-4 月的老数据。现 ACTION_ALIASES
把任意写法归一化后展开匹配，下拉只暴露 3 个规范值，
历史数据无需迁移即可被正确检索。
|
2026-09-10 14:16:39 +08:00 |
|
