yanhui
f156b90dbb
fix: MKH-BOM 待发货订单合并两张渠道表，修复天猫/淘宝订单漏报
问题
MKHDNZ0409260700059、MKHDNZ0409260601228 等成品明明有待发货订单，
补货预警却显示 0 单、判为「不预警」，业务反馈到系统。
根因
业务库的订单按渠道拆成**互不重叠的两张表**，而 loadPendingOrderIndex()
只读了 rpt.jst_Orders（京东/京喜/拼多多/抖音/得物/唯品会），
天猫 / 淘宝 / 1688 / 阿里巴巴渠道的待发货需求**全部被漏掉**。
实测（2026-09-19，近 30 天窗口）
- 两表店铺名交集 0（jst_Orders 398 店 vs qmcust 78 店），so_id 交集 5 条，
o_id 交集 **0 条** —— 合并无重复计件风险；
- jst_Orders 里 `shop_name LIKE '%天猫%'` = **0 行**
（不是命名差异：同一品牌在不同平台是不同店铺名，按品牌名反查会误判）；
- MKH 成品待发货：仅 jst_Orders = 36 编码 / 50 件 →
合并后 = **40 编码 / 56 件**，补回 4 个编码：
MKHDNZ0409260700059 / MKHDNZ0409260601228 /
MKHDNZ0409260601530 / MKHDNZ0409260700498。
修复
- PENDING_ORDER_TABLE → PENDING_ORDER_TABLES（两张表，新增 qmcust 源）；
- Promise.allSettled 并行读取，按 o_id 去重后合并（去重为防御性逻辑）；
- 部分源失败时**保留成功源的数据**并透出 degraded=true，用短 TTL 尽快重试，
不再像原先那样单源失败就整表降级为空索引（那会静默漏报全部需求）；
- 口径范围：**渠道全并**（2026-09-19 业务确认），含 1688 / 阿里巴巴 /
分销导单专用店铺。
测试
- 新增 2 个回归测试：两张表都读到 + 跨表同 o_id 只计一次 + 组合装不计入；
单源失败时 degraded=true 且成功源数据保留。
- 后端 337 项：336 通过，1 项失败为 Windows 平台固有差异
（resilientSecretStore 断言 0o600，Windows 实际 0o666），与本改动无关。
- 语法检查 151 文件通过。
2026-09-19 12:25:43 +08:00
..
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-09-15 16:53:12 +08:00
2026-09-15 16:53:12 +08:00
2026-09-19 12:25:43 +08:00
2026-09-19 12:25:43 +08:00
2026-09-12 16:53:18 +08:00
2026-09-12 17:13:59 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 16:53:18 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 21:34:07 +08:00
2026-09-15 16:53:12 +08:00
2026-09-12 11:51:44 +08:00