48 lines
4.5 KiB
Markdown
48 lines
4.5 KiB
Markdown
# 2026-09-19 计划预测包材结余天量负数排查与修复（测试环境）
|
||
|
||
### 1. 排查下单信息弹窗包材数量异常
|
||
|
||
**旭东 → 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`），后端确认下单直接拿它当用量，且错误的「下单后」会作为下一次的「下单前」，越滚越大。
|
||
|
||
### 2. 修复测试环境并验证
|
||
|
||
**旭东 → 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 行历史数据。
|
||
|
||
### 3. 同步云端并修复历史数据
|
||
|
||
**旭东 → 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），按规则未处理，已询问是否一并修复。
|