|
|
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 |
|
|
|
fc95357662
|
feat(stocktake): 跨公司扫码给精准报错，0 库存盘盈在明细中可见
【跨公司拦截】
get_stock_info 带 company_name 过滤后，扫到别家公司的货会直接查不到，
返回 404「未找到物料」—— 与「条码根本不存在」完全无法区分，现场人员
既不知道是扫错了还是扫了别人的货。
新增 find_stock_owner_company()：不施加公司过滤地全局查条码归属；
get_stock_info 未命中时由 _classify_missing_stock() 复核，区分两种情形：
· 条码存在但属于别家公司 → 403「条码 [X] 属于【LICA】，请勿跨公司盘点」
· 条码不存在 → 404「未找到该物料库存: X」
该方案的前提「SKU/条码全系统唯一」已核验成立：三张库存表的表内重复、
跨公司重复、跨表重复六项检查均为 0，故归属至多命中一条，无歧义。
/scan 与 /draft/add 两个入口均已接入。
【0 库存盘盈可见性】
merged-list 的 union_sql 原本严格要求 stock_quantity > 0，导致账面为 0、
但已被扫入的盘盈物料不出现在明细抽屉里，而 total_scanned 却把它计入
「已盘」—— 工人看到已盘 +1 却在明细里找不到，以为系统丢了数据。
现改为 stock_quantity > 0 OR id IN (本会话该表的草稿 stock_id)。
条件严格限定在**本会话**的草稿，不会把全库 0 库存物料都放出来。
实测:
IRIS 扫 LICA 条码 → 403「条码 [0000002097] 属于【LICA】，请勿跨公司盘点」
扫不存在条码 → 404「未找到该物料库存: NOPE-99999」
已扫的 0 库存物料 → 明细可见（账面 0 / 实盘 5 / 差异 +5 / 库位 Y3/3/3/4）
未扫的 0 库存物料 → 明细 0 行（范围正确）
|
2026-09-11 14:05:59 +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 |
|
|
|
3f964614e3
|
feat(stocktake): start-new 落库会话配置，active-session 改查会话表
- /draft/start-new 接收 mode / scope_type / scope_config，插入一条
StocktakeSession(status='active')。同一公司原有活跃会话先置为 finished
（同一事务），否则会撞 uq_stocktake_session_one_active。
公司取值：普通用户强制本公司；跨域角色必须显式指定，否则 400。
scope_type 目前只放行 'full' —— 抽盘的范围过滤尚未实现，此时放行会导致
结束盘点时 generate-missing 把抽盘范围外的库存批量标成盘亏。
- /draft/active-session 改为直接查 stocktake_session
(company_name + status='active')，并返回 mode / scope_type 供前端展示。
旧实现靠 max(scan_time) 从草稿行猜，空会话识别不了。
- /stocktake/generate-missing 漏盘比对完成后把会话置为 finished，
否则 active-session 会继续把它当活跃会话，其他 PDA 会加入一个已结束的盘点。
实测:
① 超管+IRIS 创建 blind/full 会话 → 200
② SALES/IRIS 查活跃会话 → 拿到同一 session_id 与 mode=blind
（scanned=0 的空会话也能查到，旧实现此处返回 null）
③ 再开一轮 → superseded_count=1，旧的转 finished
④ scope_type=active → 400「活跃库位抽盘尚未实现」
⑤ DB 层验证唯一索引拒绝重复活跃会话
|
2026-09-11 13:28:49 +08:00 |
|
|
|
aeb852c64d
|
feat(stocktake): 新增盘点会话表 StocktakeSession
盘点原本只有 stocktake_draft（草稿行），没有会话实体，导致三个问题：
1. 盲盘/明盘、全盘/抽盘这类**会话级配置**无处存放，塞进草稿表就要每行
冗余一份，改一次配置得 UPDATE 上万行；
2. 「空会话」无法表示 —— 会话开了但还没扫码时草稿表里没有行，旧实现只能
靠 max(scan_time) 猜哪个会话活跃，于是新开的空会话会被其他 PDA 忽略、
反而加入上一轮的旧会话，多端协同直接分裂；
3. 没有状态字段，generate-missing 跑完后旧会话仍被当成活跃。
本表把活跃会话判定变成 company_name + status='active' 的精确查询。
迁移的要点：
- 唯一部分索引 uq_stocktake_session_one_active 保证「一个公司同时只有一个
活跃会话」，从数据库层挡住多台 PDA 并发开启导致的进度分裂；
因此 /draft/start-new 必须先把原有活跃会话置为 finished 再插入新记录。
- CHECK 约束限定 mode/scope_type/status 的取值域。
- 不回填存量：旧草稿没有对应会话行，部署后显示「无进行中的盘点」，数据不丢。
执行: docker exec -i inventory_db psql -U test -d inventory_system < db_migrations/add_stocktake_session.sql
|
2026-09-11 13:28:43 +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 |
|
|
|
f8403d2fb2
|
feat(stocktake): 活跃会话接口补充已扫件数与发起人
多人协同场景下，加入者需要知道「谁开的、盘到哪了」，原接口只返回会话ID和
行数，信息不足以提示。
- /draft/active-session 新增 scanned（按 source_table+stock_id 去重，
且排除 user_id='system' 的自动漏盘记录，避免进度虚高）
与 initiator（该会话最早一条人工扫码记录的操作人姓名）
- 把 export_stocktake 内嵌的 get_user_name 提到模块级 _resolve_user_name
供两处复用，并补齐它漏掉的 user_id 格式：
盘点/流水里实际存的是 JWT 的 display_name，形如 "孙霞(sunxia)"，
而原实现只认 SysUser.username 的 "姓名/账号" 格式，导致解析不出来时
原样返回。现兼容 "姓名(账号)" / "姓名/账号" / 纯数字ID 三种。
实测: SUPER_ADMIN 无参数 → scanned=1117, initiator='韩善龙'
SALES + IRIS → 会话 company_name 为 NULL(迁移前遗留)，正确返回空
|
2026-09-11 12:42:55 +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 |
|
|
|
d69a77cec1
|
fix(export): 补上 export_excel 缺失的表头定义
GET /api/v1/inbound/base/export（物料页「导出库存统计」）在
base_service.py 里执行 ws.append(headers)，而 headers 全文件从未赋值，
每次调用必抛 NameError，导出功能 100% 不可用。
按 _write_stock_rows 实际写入的 22 列顺序补齐表头，命名对齐同仓库
inbound_summary_service 与 stock.py 的既有报表。
实测: 容器内导出成功 203282 字节，1817 行（含表头），表头与数据行
均为 22 列，未出现串列。
|
2026-09-11 11:44:35 +08:00 |
|
|
|
f4d97b6c4f
|
fix(image-search): 成品库存回填误取 batch_number，导致以图搜图必 500
POST /api/v1/common/image-search 在回填 StockProduct 业务数据时读取
r.batch_number，但 stock_product 表没有该列（只有采购件、半成品有），
AttributeError 把整个检索打成 500 —— 即便 stock_buy / stock_semi 两路
已经查好也一起丢掉。
改为与 stock.py /stocktake/all-items 的既有约定一致，用 serial_number 兜底，
保持三个模块回填的字段形状不变。
实测: StockProduct 样例 hasattr(batch_number)=False，serial_number='205'。
|
2026-09-11 11:44:31 +08:00 |
|
|
|
f7cae9d84e
|
fix(stocktake): 探测会话失败时不再静默降级为「无盘点」
checkServerDraft 原本在请求异常时把 activeSession 置空，界面于是从绿色
「加入正在进行的盘点」退回蓝色「开始新盘点」—— 网络抖动一下，库管点下去
就会新建会话，把多人协同拆开。
现把「探测失败」独立成 probeFailed 状态：失败时保持 activeSession 不变，
界面切到「无法确认是否有进行中的盘点 + 重新检测」，不提供进入按钮。
宁可挡住操作，也不能让库管误开新会话。
|
2026-09-11 11:39:35 +08:00 |
|
|
|
02e03e6fb6
|
fix(stocktake): 补上模块级 traceback 导入，修复异常分支的 NameError
stock.py 模块级从未 import traceback，却有 3 处裸调 traceback.print_exc()：
- scan_stock_by_barcode (/scan) —— 本次改动之前就存在
- get_stocktake_companies （新增）
- get_active_session （新增）
后果是真正的错误被 NameError 盖住：例如 company_name 列不存在时，
日志里只剩「name 'traceback' is not defined」，看不到根因。
其余 4 处在 except 块内写了局部 import 因而一直正常，现统一由模块级提供。
|
2026-09-11 11:34:23 +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 |
|
|
|
b8d18c71d8
|
fix(stocktake): 盘点链路按公司隔离，开启新盘点不再清空整表
修复三处跨公司数据污染：
1. /draft/start-new 原本执行 StocktakeDraft.query.all() 后逐条 delete，
任一库管点「开启新盘点」就会物理删除全公司所有人的盘点进度。
改为只签发新 session_id，历史数据原样保留；清理走 /draft/clear，
且强制要求 session_id（不传直接 400），杜绝误清整表。
2. get_stock_info() 全局按 barcode/sku 匹配三张库存表，不同公司的同码
物料互相串货。新增 company_name 参数，精确与模糊两段查询均经由 base
关系按 material_base.company_name 过滤；草稿去重键同步改为
(uuid, session_id, company_name)。
3. 盘点相关读写接口统一施加公司隔离：/draft/list、/draft/add、/draft/clear、
/variance-report、/draft/merged-list、/stocktake/all-items、
/stocktake/generate-missing、/stocktake/update-quantity、/export-stocktake、
/adjust、/scan。
顺带修复 /export-stocktake：差异与相符两张 Sheet 原本不按 session 过滤，
过去依赖 start-new 清空整表才恰好等价于当前会话，现显式按 session_id 过滤，
否则历史会话会被一并导出。
新增接口：
- GET /stocktake/companies 盘点页公司下拉（普通用户只返回本公司，
避免复用 /inbound/buy/options 时因缺 inbound_buy 权限而 403）
- GET /draft/active-session 该公司最近一次活跃会话，供多设备加入
|
2026-09-11 11:33:12 +08:00 |
|
|
|
6586d3cb75
|
feat(stocktake): 盘点草稿表增加公司隔离字段
stocktake_draft 原本没有任何公司维度，导致开启新盘点清空整表时会误删
其他公司的进度，扫码时也无法区分不同公司的同码物料。
- StocktakeDraft 增加 company_name（带索引），to_dict 同步输出
- 新增迁移 add_stocktake_draft_company_name.sql：加列 + (company_name,
session_id) 复合索引；存量行保持 NULL（超管仍可见），不做删除
执行: docker exec -i inventory_db psql -U test -d inventory_system < db_migrations/add_stocktake_draft_company_name.sql
|
2026-09-11 11:33:04 +08:00 |
|
|
|
c6694043d4
|
V3.78,9.11推送
|
2026-09-11 10:35:34 +08:00 |
|
|
|
06cb5f1cac
|
fix(reservation): 实扫来源不可识别时整单失败，避免预占永久锁死
出库与借库两条执行路径原先写作：
_scanned = [i for i in items if i.get('source_table') != 'trans_repair']
if _scanned:
verify_scanned(...); restore_then_deduct(...)
`if _scanned:` 为假时校验与释放被整体跳过，而下方仍无条件把单据置为
status=3（已完成）。此时申请阶段 reserve_for_items() 扣掉的 available_quantity
无人归还，且 status=3 之后 /close（要求 status==1）与 /withdraw（要求
status∈(0,1)）都拒绝再释放 —— 预占就此永久锁死，成为谁也领不走的幽灵库存，
且没有流水可供追溯。
改为 Fail-Closed：实扫明细的来源必须全部落在 model_map 内，否则整单失败。
事务回滚后单据保持 status=1、预占原样保留，库管可重试执行，或走驳回/撤回 ——
任一路径都能正常归还预占。
- outbound_service.create_outbound_batch：以 model_map 白名单过滤，
并要求 _scanned 非空
- trans_service.execute_dispatch：先显式校验来源合法性并列出非法值，
再要求 _scanned 非空
|
2026-09-11 10:34:55 +08:00 |
|
|
|
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 |
|
|
|
a8a3c82331
|
fix(stock): 补行级防穿仓与入库改量下限，杜绝可用数变负
available_quantity 一旦为负，预占/释放/盘点的全部算术都会失真。此前有两处
缺口，本次一并堵上，使 available_quantity >= 0 成为不变量。
1) 执行阶段逐行扣减无下限校验（inventory_reservation.restore_then_deduct）
物料级校验只保证「Σ实扫 ≤ Σ可用」这一总量关系，拦不住「总量守恒但单行
穿仓」：同物料下 A 批可用 2、B 批可用 8，工人把 5 件全压在 A 批上，总量
5 ≤ 10 通过，A 批却被扣成 -3。借库走 deduct_stock=False，连实物数校验都
跳过，是裸扣。
已实测复现：借库与出库路径均可把单行扣成 -3。
校验放在 release_reserved() 之后，故不会误拒合法的换批次（物理覆盖）：
释放后每行 available 已含本单预占，扫自己预占过的批次时 raw >= 0 保证
必然放行；改扫其它批次时，该批次实时可用量就是它自己的上限。
2) 下调入库数量可把可用数压成负（buy/product/semi 三处 update_inbound）
按 diff 同步增减 stock/available，但无任何下限检查。该批次若已有部分被
预占/出库/借出，向下调整即产生负可用数。现在下调前校验可用数是否够扣。
正常数据下 stock >= available 恒成立，故守住 available 同时守住 stock。
配套：三个 update_* 端点此前只捕获 Exception → 500，没有 ValueError 分支
（同文件的 delete_* 早就有）。补上 400 分支，使业务校验失败不再被记成
服务端故障。
验证（事务内执行并回滚，未落库）：跨批次穿仓被拦、合法换批次放行、全额执行
本单预占批次放行、下调击穿被拦（API 返回 400，三个端点一致）、上调不受影响、
真实借库单 52 行全额执行正常、全库无负可用数。
|
2026-09-11 10:34:15 +08:00 |
|
|
|
cbcedecba2
|
fix(outbound): 扫码/备选库位回加本单预占，修正可用数重复计数
出库选单提交申请时 reserve_for_items() 会立即扣减 available_quantity（预占，
防超卖），但扫码页拿到的仍是这个已被本单扣过的值，并当作「本单能扫多少」的
上限。对本单而言它自己锁掉的货当然该能扫，于是同一批货被算了两次：
· 某行被本单占满时 available=0，工人直接扫不进去，提示「库存不足或已出库」
· /alternatives 按 available_quantity > 0 过滤，被本单占满的行从列表消失
· 草稿恢复时刷新实时库存，误报「实际库存已少于你扫的数量」
改法：扫码阶段的可用量 = 实时可用量 + 本单在该行的预占量。别人单子的预占
不回加，防超卖能力不丢。该值与后端 restore_then_deduct() 释放预占后用于校验
的数字精确相等，是同一口径而非近似。
后端：
- inventory_reservation.py 新增 reserved_index()/reserved_qty() 纯读工具
- outbound.py 新增 _own_reserved_index()，改造 /scan 与 /alternatives
- outbound_service.py 的 _format_scan_result 返回归一化可用量
两道门禁：
- biz_type 区分出库/借库两张审批单（独立表、ID 空间独立，而两个端点被
出库页与借库页共用），否则借库单 ID 会命中另一张出库单
- 单据状态仅放行 status ∈ {0,1}。set_items() 只在创建时调用，执行/驳回后
items_json 里的 reserved=True 仍原样保留而库存早已归还，门禁一松就会
二次回加 → 真超卖（现有 3 张已完成单据即属此形态）
不满足门禁时静默降级为不回加（fail-closed），并回传 reservation_applied。
|
2026-09-11 10:34:00 +08:00 |
|
|
|
b8561f69f7
|
V3.77,9.11推送
|
2026-09-11 09:39:59 +08:00 |
|
|
|
f702a70fe5
|
fix(borrow): 借出只冻结可用数，不再扣减实物库存
问题
----
上一轮库存预占改造（b57c21a）把借库执行改用了 restore_then_deduct()，
而该函数是按**出库语义**设计的（物品永久离开仓库），会同时扣减
available_quantity 与 stock_quantity。借库是可逆的，于是产生两个缺陷：
1) 借出再归还后，实物库存永久少一份
初始 (stock=20, avail=20)
借出5 (stock=15, avail=15)
归还5 (stock=15, avail=20) ← 实物没回来，丢了 5
2) 借出后转报废会重复扣减
scrap_borrow 的注释明确写着「扣减总库存（该物品确认损失）；
可用库存已在借出时冻结，无需重复扣」—— 它假设借出**没动实物**。
借出已扣 stock 后，转报废再扣一次：
借出5 stock=15 → 转报废 stock=10（正确应为 15）
修复
----
restore_then_deduct 增加 deduct_stock 参数：
出库 deduct_stock=True （默认）—— 可用数、实物数同时扣
借库 deduct_stock=False —— 只冻结可用数，实物数不动
★ 这是**恢复原有设计**，不是新设计。git 历史显示从最初的
04ee938 借库逻辑实现 起，历经 7ef22a3 / 83b3db6 / b79b0f9 /
2556b77 / 1527d55 六次提交，一直是：
stock.available_quantity = float(stock.available_quantity) - qty
（只减可用，不动实物）。b57c21a 把它替换掉了。
盘点的差异计算也印证了该口径的正确性：
adjusted_stock_qty = stock_quantity - 借出未还
diff_qty = 实盘数 - adjusted_stock_qty
这段逻辑要求 stock_quantity **包含**借出未还的实物，否则会重复扣减。
最终语义
--------
stock_quantity = 账面实物总数（含借出未还）
available_quantity = 实际可取用数
出库申请(预占) — available ↓
出库执行 stock ↓ available ↓
借库申请(预占) — available ↓
借库执行 — available ↓
借库归还 — available ↑
借库转报废 stock ↓ —
实测（stock, available）
------------------------
借还循环：初始(20,20) → 借出5(20,15) → 归还5(20,20) 完全可逆
出库： 预占4(20,16) → 执行(16,16) 实物确实减
转报废： 借出3(20,17) → 转报废(17,17) 实物减一次，不重复
|
2026-09-11 09:39:20 +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 |
|
|
|
33acdc758c
|
fix(scan-draft): 撤回申请单时清理其扫码草稿
问题
----
草稿按 (user_id, biz_type, request_id) 存储，而撤回逻辑原先只做两件事：
释放预占、把状态置为 4。没有任何草稿清理 —— 撤回后草稿成为孤儿数据：
· 单据状态变为 4，不再出现在扫码页的下拉里（那里只拉 status=1），
草稿从此永远读不到；
· 若不清理会持续累积，每行是一个整单 JSON 快照。
实测（撤回前 2 份草稿）：撤回后该单草稿数归 0。
★ 清的是**所有用户**在这张单上的草稿，而非仅撤回者自己的 ——
可能有多人扫过同一张单，只清自己的会留下他人的孤儿数据。
出库 outbound_service._release_and_close
借库 borrow_service._release_and_close
两处共用底层，一并补上。
|
2026-09-11 09:06:43 +08:00 |
|
|
|
6f2f077751
|
feat(purchase): 采购页搜索区对齐出库记录版式
原顶部工具栏是裸 div + 状态单选，现改为 el-form :inline 版式，与出库记录 /
报废记录一致：
状态 全部 / 待审批 / 已通过 / 已驳回 / 已完成 / 已完结
搜索 [搜索类型下拉] + 关键词输入，500ms 防抖
采购日期 日期范围选择
按钮 查询 / 重置 / 新建采购申请
交互细节：
· 搜索类型切换、清空输入时立即查询（取消防抖等待）；
· 「重置」恢复默认的「待审批」状态（该页默认视图），而非清成"全部"——
与页面初始状态保持一致；
· 重置同时清空关键词、搜索类型、日期范围。
api/purchase.ts 的 getPurchaseList 补充新参数的类型定义。
|
2026-09-10 17:41:29 +08:00 |
|
|
|
e93107458a
|
feat(purchase): 采购列表支持关键词搜索与日期范围
背景
----
采购管理此前只有状态筛选，无法按单号/物料/申请人检索，也无法按采购
日期收窄范围。现对齐出库/报废记录的搜索语义，便于用户迁移使用习惯。
后端
----
PurchaseService.get_purchase_list 新增参数：
keyword / search_type / start_date / end_date
search_type 取值（与出库、报废一致）：
all 单号 | 物料名称 | 规格型号 | 备注 | 申请人
no 单号
name 物料名称
spec_model 规格型号
requester 申请人
实现要点
--------
· 申请人姓名存在 SysUser.username，格式「姓名/账号」（如 韩善龙/hanshanlong），
ilike 直接匹配整串即可命中；
· 该类字段只在 SysUser 上，故**按需 join** —— 单号/名称/规格分支不联表，
避免无谓开销；
· 公司隔离分支也需 join SysUser，与关键词分支可能重复 join 同一目标，
会产生笛卡尔积导致结果翻倍，故按需补 join 并用 distinct 兜底；
· 日期范围按 purchase_date 过滤（该列是 Date，无需补时分秒）。
实测：名称'充电器'→1 单，申请人'韩善龙'→21 单，日期 05-13→2 单，
关键词不存在→0 单，状态+搜索组合→14 单。
|
2026-09-10 17:41:22 +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 |
|
|
|
ec66c33b06
|
feat(scan-draft): 扫码草稿表与接口，支持暂停后继续扫码
场景
----
扫码出库/借库的作业可能很长（一张单几十项），工人常需中途暂停去处理
更紧急的单据。改造前切换单据会清空已扫内容，刷新/退出页面则全部丢失。
由于库存在申请审批通过时已**预占**，暂停期间货不会被他人抢走 ——
因此草稿只记录「扫到哪了」，**不涉及任何库存操作**。即使草稿丢失也只是
需要重扫，不会造成库存错乱。
隔离粒度
--------
按 (user_id, biz_type, request_id) 一人一单：每个人扫自己的草稿，互不影响；
同一人可同时持有多张单据的草稿（正是「暂停 A 去出 B」的场景）。
user_id 一律取自 JWT，不接受入参覆盖，故不可能读写他人草稿。
为什么整单存一个 JSON（而非每条明细一行）
------------------------------------------
1. 保存是「全量覆盖」语义，逐行存无增量更新的收益；
2. 恢复时需要物料名称/规格/库位等展示字段，逐行方案只能回查申请单的
items_json —— 而历史单据的 items_json 不含 stock_id，回查会错配。
整单快照把展示字段一并存下，恢复零依赖，对老单据同样可靠。
接口
----
GET /api/v1/scan-draft 读取草稿
POST /api/v1/scan-draft 保存（全量覆盖；空清单则删除）
DELETE /api/v1/scan-draft 清除（提交成功后调用）
GET /api/v1/scan-draft/overview 各单据进度，供下拉徽标
实现要点
--------
· items_json 列是 jsonb，模型必须用 db.JSON —— 用 db.Text 会让 psycopg2
拿到 Python list/dict 时无法适配，报 "can't adapt type 'dict'"，而异常
被接口的 except 吞掉后 POST 仍返回"成功"，问题极难发现（开发中实际踩到）；
· 概览接口做防御：残留的空草稿不参与展示。
实测：保存/读回、跨单据隔离（B 读 A 的草稿为 0 项）、全量覆盖、
提交后清除，全部符合预期。
|
2026-09-10 17:21:14 +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 |
|
|
|
29fc00a818
|
fix(my-requests): 修正 withdraw_endpoint 路径前缀导致撤回 404
现象
----
在「我的申请单」页面点撤回，前端控制台报：
POST /api/api/v1/outbound/request/351/withdraw 404
根因
----
aggregate 端点在每条记录上回传 withdraw_endpoint，但拼接时多写了 /api：
返回的: /api/v1/outbound/request/351/withdraw
axios baseURL: /api
实际请求: /api + /api/v1/... = /api/api/v1/... → 404
后端路由本身是对的（/api/v1/outbound/request/<id>/withdraw 已正确注册），
问题纯在前端拼接。其它 API 封装的正确写法是只传 baseURL 之后的部分
（如 url: '/v1/outbound/my-requests'），本处是唯一破坏该约定的地方。
修复
----
返回 /v1/... 而非 /api/v1/...，并加注释说明约定。
借库项同时从 close 改为 withdraw（配合上一提交的申请人端点）。
验证方式
--------
按**前端真实的拼接方式**验证（'/api' + endpoint），而非直接调后端路由：
[outbound] /v1/outbound/request/381/withdraw → 200
[borrow ] /v1/transactions/borrow/request/44/withdraw → 200
[scrap ] /v1/scrap/request/5/withdraw → 200
教训：上一轮用 test_client 直接调后端路由验证，绕过了 axios 的 baseURL
拼接，所以后端测试全绿、前端一跑就 404。验证「前端能否调通」必须模拟
前端的请求方式。
|
2026-09-10 15:47:02 +08:00 |
|
|
|
077fd2f2cf
|
feat(borrow,scrap): 补齐申请人撤回端点，与出库对齐
背景
----
出库已有独立的申请人撤回端点（仅 @jwt_required + 服务层归属断言），
但借库/报废没有：
· 借库撤回复用 close 端点，权限是 op_borrow_approval（管理路径），
普通员工调用返回 403；
· 报废撤回带 @permission_required('scrap_apply')，同样挡住普通申请人
（scrap_apply 只授予 INBOUND/OUTBOUND/SUPERVISOR/SUPER_ADMIN）。
结果是「我的申请单」页面里，借库/报废的撤回按钮对普通员工点了报错。
借库
----
服务层拆成与管理路径并列的两条入口（与出库同构）：
mark_completed —— 管理路径，需 op_borrow_approval，仅 status==1
withdraw_request —— 申请人路径，仅校验单据归属，status 0 或 1
两者共用 _release_and_close()，释放逻辑只有一份实现。
新增 POST /transactions/borrow/request/<id>/withdraw（仅 @jwt_required）。
报废
----
withdraw() 增加 require_owner 参数区分两条路径：
require_owner=True （默认，申请人路径）→ 断言 applicant_id == operator_id
require_owner=False（管理路径） → 由调用方权限装饰器鉴权
WITHDRAWABLE_STATUS 从 (1,) 放宽到 (0, 1)，与出库/借库对齐。
移除端点上的 @permission_required('scrap_apply')，改走归属校验。
安全实测
--------
借库 B 撤 A 的单 → 403，库存仍是 27（未被释放）
借库 A 撤自己的单 → 200，30 完全释放
报废 B 撤 A 的单 → 403
报废 A 撤自己的单 → 200
主管代撤员工的单（特权路径）→ 200
|
2026-09-10 15:46:55 +08:00 |
|
