# 2026-09-22 钉盘库存与日出库更新到 8.186 和云端

### 1. 读取钉盘最新库存与日出库并同步两端

**旭东 → OpenClaw：**

> 钉盘里面最新库存数据和日出库数据已上传，你去读取并更新到8.186系统和云端系统中，并及时刷新缓存，另外查缺补漏一下是否有遗漏，如果有则进行补录

**OpenClaw 响应：**

已完成同步与查缺补漏，两端数据一致、缓存与服务验证通过。**未操作 11.79 生产环境。**

**一、钉盘全分页扫描**

- 日出库目录：17 页，830 个 CSV；库存目录：32 页，1,587 个 CSV（首次扫描库存第 3 页遇 MCP 网络错误被截断，加5次重试后完整重扫）
- 出库来源实际取值 9 个：`dymuto,dyqsimelr,jdbz,jdgj,jdjwt,jdmrt,jdsmj,tmgj,wdt`（未按白名单过滤）
- 出库日期范围 2026-05-12 ~ 2026-09-21；库存 2026-05-27 ~ 2026-09-22
- **钉盘无 2026-09-20 库存文件**（来源未上传，不制造数据）

**二、缺口定位（两端完全一致）**

- 出库缺 10 组合：09-19 tmgj、09-20 八个店铺来源（dymuto/dyqsimelr/jdbz/jdgj/jdjwt/jdmrt/jdsmj/tmgj）、09-21 wdt
- 库存缺 21 组合：09-22 全部 21 个仓库
- 两端各有 12 个 5~6 月历史遗留组合（库中有、盘上无），不属本次缺口，未动

**三、备份**

- 两端目标切片分别备份（8.186 → `/tmp/scan_20260922/backup_local_local.json`，云端 → `/tmp/dy-slices/backup_cloud_cloud.json`），均确认为 0 行（新组合），回读校验通过

**四、导入结果（两端逐组合一致）**

- 出库：10 文件 4,044 条；库存：21 文件 21,448 条
- ⚠️ 过程中发现并修正一个归一化陷阱：比对时为归一化去了仓库前导零，导致 `01/02/04/05/06/07/09` 七个仓漏在第一次工作清单外（14 仓导入成功），已补导入这 7 个仓，最终 09-22 齐 21 仓
- 31 个源文件两端 md5 逐文件比对**全部一致**
- 09-22 库存：可用 45,795,993、生产在途 1,721,299、采购在途 12,515,335

**五、缓存与服务**

- 两端各刷新 11 个缓存模块
- 8.186 用户级单元重启后 active，本机与局域网 HTTP 200；云端 `kill -HUP` 平滑重载后 active，本机与公网 HTTPS 200，端口单组进程，日志无新错误

**六、查缺补漏结果**

- 云端：组合缺口 0 ✅
- 8.186：组合缺口 1 个（2026-06-23 jdgj）+ 行级差异 74 个组合（2026-09-02 ~ 09-19，累计少 384 行）
- 行级差异呈**按来源固定常数**：dyqsimelr 17、jdbz 4~6、jdsmj 3、tmgj 2、jdjwt 1、wdt 1~2
- **根因**：`auto_clean.py`「货品名称 = 空」删除规则。非旺店通导入器在货品编码查不到产品主数据时把货品名称写成空字符串，这些真实出库行在导入后次日 08:00 被清洗删掉（今日 08:00 自动化即删除 56 条）。云端未跑该规则故完整保留。
- 库存侧近 7 天各「日期+仓库」两端行数完全一致 ✅；本次新导入的 09-20、09-21 数据两端一致，未受影响
- 按「不擅自改清洗规则」原则，**未修改规则、未擅自批量回填**，已带证据报告并请旭东决定是否修复规则后一并回填（否则回填次日又会被删）