fix: MKH-BOM 待发货订单合并两张渠道表，修复天猫/淘宝订单漏报 #17
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "codex/mkh-pending-order-merge"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
问题
MKHDNZ0409260700059、MKHDNZ0409260601228这两个成品明明有待发货订单，MKH-BOM 补货预警却显示「待发货订单 0」、判为不预警 —— 业务核对聚水潭后台后反馈到系统。
根因
业务库的订单按渠道拆成互不重叠的两张表，而
loadPendingOrderIndex()只读了rpt.jst_Orders：rpt.jst_Ordersrpt.jst_qmcust_orderlist→ 天猫、淘宝、1688 渠道的待发货需求全部被漏掉。
实测证据（2026-09-19）
jst_Orders398 店 vs qmcust 78 店），so_id交集 5 条，o_id交集 0 条 —— 合并无重复计件风险jst_Orders里shop_name LIKE '%天猫%'= 0 行。注意不是命名差异：同一品牌在不同平台是不同店铺名（如「欧意朗」在jst_Orders是拼多多/得物/唯品会，天猫/淘宝在另一张表），按品牌名反查会误判「表里有」MKHDNZ0409260700059→o_id=9428441，天猫-欧意朗旗舰店，09-18 19:50，Question未发货MKHDNZ0409260601228→o_id=9438051，天猫-HX旗舰店101，09-19 06:36，Question未发货影响面（MKH 成品待发货）
jst_Orders（修复前）补回的 4 个编码：
MKHDNZ0409260700059、MKHDNZ0409260601228、MKHDNZ0409260601530、MKHDNZ0409260700498。实时单量：
jst_Orders未发货含 MKH 52 单 + qmcust 10 单。性能实测 qmcust 该查询约 0.17s，可忽略。已排除的原因（别再重复查）
不是解析问题（
parseOrderSkus正常）、不是状态过滤（全状态/全发货历史仍是 0 单）、不是组合装承载（所属组合装本身也是 0 单）、不是缓存降级（
pendingOrderDegraded=false）。系统口径本身正确 —— 正向抽验 4 个真有待发货的编码，接口全部如实显示。
修复
PENDING_ORDER_TABLE→PENDING_ORDER_TABLES（两张表，新增 qmcust 源）Promise.allSettled并行读取，按o_id去重后合并（去重为防御性逻辑）degraded=true，用短 TTL 尽快重试 ——不再像原先那样单源失败就整表降级为空索引（那会静默漏报全部需求）
测试
o_id只计一次 + 组合装不计入；② 单源失败时degraded=true且成功源数据保留resilientSecretStore断言0o600，Windows 实际0o666），与本改动无关loadPendingOrderIndex()→degraded=false、40 编码 / 56 件 / 52 单，4 个漏报编码全部命中风险与回滚
改动集中在单一函数 + 常量，无 SQL 结构变更、无前端改动。
回滚 = revert 本提交即可恢复单表行为。
备注
本次仅修「订单���漏读」。另有一个独立的口径盲区已定位未修（等业务定调）：
日销完全依赖上游
pm_stockMonitor.fifteenAvgSale（日更快照），存在漏算 ——快照口径下 178 个近 15 天有发货的 MKH 编码里，24 个该列仍为 0
（含
MKHDNZ0409260601548天猫 09-09 发货 1 件）；叠加「日销 0 且无待发货订单 → 判无销量、不参与预警」，形成
**「有出库 + 零库存 + 永不预警」**的盲区，全量共 13 个编码。
问题 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 文件通过。