销售基地回补方案技术评审会议纪要
会议时间：2026-06-03
会议摘要：本次评审了销售基地回补方案，针对活动中心与主数据系统间存在数据同步延迟导致新店/新员工签收后无法发放激励的问题，明确了差异化处理策略（店主 vs 导购）及计费回调接口的设计方向。
一、问题背景
1.1 问题描述
| 现象 | 触发条件 |
|---|---|
| 新店或新员工在签收后无法发放激励 | 活动中心与主数据系统间存在 数据同步延迟 |
1.2 问题链路
主数据系统 ──(同步延迟)──▶ 营销活动中心
│ │
▼ ▼
新店/新员工创建 签收时查不到收款方信息
│ │
└──── 无法发放激励 ◄──────┘二、技术方案
2.1 核心策略：差异化的激励发放逻辑
根据签收角色采用不同的处理方式：
| 签收角色 | 处理策略 | 数据来源 |
|---|---|---|
| 店主 | 由计费服务主动向活动中心查询并回填收款方信息 | 计费服务 → 活动中心（实时查询） |
| 导购 | 维持现状，不做调整 | 原有链路 |
设计理由：店主的收款方信息变更频率较低且影响面广，适合主动查询回填；导购场景相对稳定，暂不改动以控制风险。
2.2 流程设计
店主签收回补流程（优化后）
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 店主签收 │ ─▶│ 计费服务 │ ─▶│ 活动中心 │ ─▶│ 回填收款方 │
│ │ │ (查询) │ │ (实时) │ │ 信息 │
└─────────┘ └──────────┘ └──────────┘ └──────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 发放激励 │ │ 更新签收 │
└──────────┘ │ 记录+明细 │
└──────────┘2.3 新增回调接口
新增计费结果回调接口，用于：
- 更新签收记录 — 将计费结果写回签收主表
- 更新签收明细 — 将明细级结果写回签收明细表
- 失败告警 — 回调失败时触发告警通知，便于人工介入
计费服务 ──(callback)──▶ 营销活动中心回调接口
│
┌──────┼──────┐
▼ ▼ ▼
更新签收 更新明细 失败告警
记录三、涉及变更范围
| 变更类型 | 具体内容 | 影响模块 |
|---|---|---|
| 接口新增 | 计费结果回调接口（POST） | 活动中心 API |
| 逻辑改造 | 计费服务中店主签收的查询回填逻辑 | 计费服务 |
| 数据更新 | 签收记录、签收明细表的更新逻辑 | 数据层 |
| 告警集成 | 回调失败的告警机制 | 监控告警 |
四、风险与关注点
| 风险项 | 描述 | 影响 | 建议 |
|---|---|---|---|
| 问题范围界定不清 | 方案背景可能被误解为解决整个主数据同步链路的全部时延，而非仅限计费服务内部的数据加工时延 | 方案评审方向偏离 | 需在方案背景中明确限定范围 |
| 回调接口可靠性 | 计费回调失败将导致签收状态不一致 | 数据一致性 | 引入重试机制 + 失败告警 + 补偿对账 |
| 性能影响 | 实时查询活动中心增加网络开销 | 发放时效性 | 可考虑缓存热点数据 |
五、待办事项
| 序号 | 待办内容 | 责任人 | 状态 |
|---|---|---|---|
| 1 | 在方案背景中明确问题范围，准确描述其主要解决的是计费服务内部数据加工产生的时延问题，而非整个主数据同步链路的全部时延 | 李明非 | ⏳ 待跟进 |
六、结论
- 差异化策略通过：店主签收走实时查询回填路径，导购维持现状。
- 回调接口设计明确：更新签收记录/明细 + 失败告警。
- 问题范围需修正：李明非需重新描述背景，聚焦于计费服务内部的时延问题。