邮件标题：20260914-技术评审-营销活动中心-B端出货明细表系统出货数据修复
邮件正文：
晓娜、建新：
已完成针对【B端出货明细表系统出货数据修复】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称： 营销活动中心
评审时间： 2026/09/14
参与评审人： 马奇、粱健、王建朝、贾继伟、张建利、宋洋、潘玉平
评审结果：通过
一、技术方案背景
- 业务场景：将历史存量中"只签收未出货"的数据回补为系统出货。覆盖 4 种签署类型：查证签收（FLOW_CHECK_SIGN）、查证异常签收（FLOW_CHECK_EXCEPTION_SIGN）、盘点签收（FRESHNESS_SIGN）、盘点异常签收（FRESHNESS_EXCEPTION_SIGN）。修复范围 create_time 为 2026-08-06 至 2026-09-11，涉及数据量 5,862,853 条（约 586 万），修复字段 shipment_scene、update_time。同时盘点明细表需在"签收门店名称"后新增"签收类型"展示字段（取最后一次签收记录的类型），历史数据不回补。
二、技术方案要点
- 整体流程：历史数据通过一次性 SQL 批量更新，将满足条件的记录 shipment_scene 由
C_END_CODE_MARKETING_OUTBOUND（BC 营销出货）改为SYSTEM_OUTBOUND；WHERE 条件除 4 种 sign_type 外，还需当前 shipment_scene 为 BC 营销出货、且shipment_time = sign_time、shipment_order_form_id = sign_order_form_id（确保是"出货单=签收单"的纯签收记录，避免误改真实出货单）。盘点明细表新增"签收类型"字段——后端查询逻辑新增类型参数、前端页面与导出同步加列，C 环境测试中。
三、决议事项
- 586 万修复 SQL 执行前，与中台确认对 SR 写入压力及中台抽数（超 2000 万抽不动）的影响，由粱健负责。
- 修复 SQL 于低峰期（9/16 22:00 后）分批执行、控制速率（每批 < 100 万），避免一次性全量冲击 SR，由粱健负责。
四、风险提示
- 对 SR 写入压力与延迟风险：方案已明确标注"对 SR 有一定影响，需在低峰执行"，虽仅更新单列仍需评估。
- 中台抽数限制（超 2000 万抽不动），需确认修复后不影响中台抽取。