邮件标题：20260910-技术评审-营销活动中心-B端出货明细表签收距离（store_distance）缺失修复
邮件正文：
晓娜、建新：
已完成针对【B端出货明细表签收距离（store_distance）缺失修复】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称： 营销活动中心
评审时间： 2026/09/10
参与评审人： 李明非、粱健、王建朝、刘晓娜、余建新、孙传熙、贾继伟、张喜、马奇、潘玉平
评审结果： 不通过（数据范围判定口径不成立，需重新确定时间窗口后重评）
一、技术方案背景
- 业务场景：806 版本上线期间（约 2026-08-06 ~ 08-14）data 服务与数据库崩溃，出货/签收数据写入
shipment_report_details_v2时部分字段未落库，其中签收距离store_distance缺失；缺陷已随 806 版本修复、新数据不再产生，本次仅修复该窗口内 243 单历史存量，以签收单编码反查 Mongosign_order_info.signDistance后 SQL 回填。
二、技术方案要点
- 整体流程：明细表按「
store_distance IS NULL+sign_order_form_id非空 + 排除查证/盘点类签收」取待修复签收码（预期 243 个）→ Mongo 按signingCode反查signDistance（同码多条取最新一条）→ 生成逐单 UPDATE（条件带store_distance IS NULL保证幂等）→ 执行前建备份表 → StarRocks 执行 → 复检剩余空行数与单量。
三、决议事项
- 重新确定签收距离字段的上线时间（该字段何时开始写入），据此重新推导修复时间窗口，由潘玉平负责。
- 所有涉及该表的 SQL 必须带分区键
create_time，由潘玉平负责。 - 备份表与修复 SQL 的 WHERE 条件（分区键与时间窗口）必须逐字一致，确保可回滚，由潘玉平负责。
- 方案修改完成后先由爱创李明非复核，再组织伊利侧评审。
四、风险提示
- 无