2026-09-19 计划预测包材结余天量负数排查与修复（测试环境）

旭东 → OpenClaw：

现在发现一个异常，在计划预测菜单里面，部分商品的下单信息弹窗里面，下单前包材和下单后包材数量异常，都显示-24995000，查一下是什么原因？

OpenClaw 响应：

定位为数据被算坏，不是显示问题；异常值只存在于云端生产库（本地测试环境 0 行），共 31 个商品 51 行，从 -300 到 -79,982,000。

两列同值的原因：确认下单时后端把「下单前包材」「下单后包材」写成同一个值（routes/purchase.py 的 ON DUPLICATE KEY UPDATE pre_pack_qty=%s, post_pack_qty=%s 用的是同一个 post 值），弹窗两列都读 bom_packaging，所以必然相同。
数值来源：滚动公式 下单后 = 下单前 + 包材实际下单数量 − 成品实际下单数量 × 包材用量，其中「包材用量」取错了值。以 POZ-BXQXJ-0880-TM 为例，真实用量是 1，请求里带的 quantity 是 5000（= 包材实际下单数量），代入得 0 + 5000 − 5000×5000 = −24,995,000，完全吻合；POZ-XFS-3691-TM（−79,982,000）、POZ-XFS-7010-TM（−49,985,000 / −74,984,000）同样对得上。
根因：前端下单信息弹窗保存时把 quantity 写成了「实际下单数量」输入值（static/js/app.js，2026-07-31 提交 8e66faa 把 quantity: bomQty 改成 quantity: qty），后端确认下单直接拿它当用量，且错误的「下单后」会作为下一次的「下单前」，越滚越大。

旭东 → OpenClaw：

先改测试环境验证，我确认后再同步云端并修复数据

OpenClaw 响应：

已在 192.168.8.186 测试环境完成修复与验证，未动云端和 11.79 生产。

前端（static/js/app.js）：下单信息弹窗的保存、回车缓存、缓存回填三处，quantity 改回读「用量」列。
后端（routes/purchase.py）：新增 _resolve_roll_bom_qty，确认下单与订单回退的包材结余一律优先取 bom 表的权威用量，bom 表没有该物料时才回退前端传值。
验证：端到端复现——造临时商品（用量 1、下单前包材 3000、成品下单 5000、包材下单 5000/0），bom_items 故意写入污染值 quantity=5000，走真实 confirm_order 接口确认下单，结果下单后包材分别为 3000 和 −2000（正确，修复前会是 −24,992,000 级的负数）；临时数据已清理。JavaScript/Python 语法检查、gzip 缓存重新生成、服务重启后 active、HTTP 200 均通过。
修复前已顺手核对：本地测试环境唯一一条待下单记录的 bom_items.quantity 同样是被污染的 6000（真实用量 1），说明测试环境也会踩同一个坑。
Git 提交 cb1ec72（仅 static/js/app.js 与 routes/purchase.py）。等旭东确认后再同步云端并修复那 51 行历史数据。

旭东 → OpenClaw：

确认执行

OpenClaw 响应：

云端（gyl.dieya.net.cn）代码与数据都已处理完，11.79 生产未动。

代码：routes/purchase.py 整文件替换（与 8.186 一致）；static/js/app.js 用定向补丁只改这 4 处，不带入云端还没有的列说明文案；重新生成 app.js.gz；gunicorn 平滑重载，本机与公网 HTTP 200，下发资源已含修复。
数据：对云端 bom_packaging 受影响的 31 个商品 77 行逐行核查（反推被污染那次写入之前的值，再按真实用量重算），确认 12 行真被污染并修复：POZ-BXQXJ-0880-TM 三个包材 −24,995,000→0；POZ-XFS-3691-TM 三个包材 −79,982,000→10,000；POZ-XFS-7010-TM 瓶/泵 −49,985,000→10,000、彩盒 −74,984,000→11,000；POZ-MM-3332-TM-MD −15,000→3,000；JWTBS-HYT-0008-ALJK 彩盒 −2,000→−7,000、面膜袋 25,000→−25,000。其余 65 行是正常负数（包材没下单、成品有消耗），未改动。
修复前备份：数据 15 行 ~/dy-backups/bom-packaging-packfix-20260919_152221/，代码 ~/dy-backups/code-packfix-20260919_1521xx/；修复后执行 refresh_all_caches()。
两处云端基准与本地 8.186 导入值不同已列出请旭东核对：XFS-7010 彩盒（云端基准 1000，本地 15000）、JWTBS-HYT-0008 彩盒/面膜袋（云端基准 −5000，本地 2000）。
11.79 生产同样存在这批脏数据（35 行小于 −1000，含 −79,982,000、−74,984,000、−24,995,000），按规则未处理，已询问是否一并修复。