2026-05-20 工作日志

项目进度同步会

会议同步了各项工作的进展，讨论了APM接入、扫码效率、数据治理及数据库IO故障等问题，并明确了后续的优化方向和待办事项。

小结

1. 产品与技术优化

• APM接入：已与供应商沟通，计划于6月底至第三季度完成Uni App框架的接入。
• 扫码效率：COS上传和风控接口耗时占比过高。后续将联合三方进行优化方案的确认。
• 数据治理：已按计划推进，包括主数据与智慧门店的对数工作、销售区域问题排查等。
• 报表字段取值：将对现有报表的字段取值逻辑进行全面梳理，以解决数据异常问题。

2. 数据库IO故障

• 该故障的直接原因为IO异常，初步分析与存储、容灾软件及VR平台有关，但尚未定位到根本原因。
• 已作为专题讨论，短期内将故障数据库迁移至备用主机以降低风险。

3. 需求与发布

• SFA系统：已确认无需调整，将进行线上验证。
• SFA灰度发版：计划提前至5月26日晚进行灰度发版，届时将组织专项评审。

4. 其他问题

• 健康度规则：将根据宝剑提供的物码营销项目问题文档，识别并配置相关规则。
• "安慕希"二维码落地页问题：因用户配置错误导致，将作为产品体验优化项跟进。

待办

1. 产品走查计划

• 由任铭和王琪负责，需在今日下班前输出完整的走查计划。@任铭 @李赵丹

2. 扫码效率优化

• 由王琪负责，今日需联合COS平台和风控接口方，确认进一步的优化解决方案。@王琪

3. 数据库IO故障

• 由志磊负责，需在今日内输出关于IO故障的根本原因分析结论。@李志磊

4. SFA灰度发版评审

• 由李亚洲负责，会后需尽快确定并发出评审日程。@李亚洲

5. "安慕希"二维码落地页问题

• 由吴菊负责，将此问题记录在产品体验优化项中，跟进后续的优化方案。@吴菊

6. 主数据同步接口超时

• 由王轩春负责，需持续跟进并推动供应商尽快处理此问题。@王轩春

7. 技术优化排期

• 由刘晓娜负责，需等待技术优化团队确认后，再更新"查证明细表加主键"问题的排期。@刘晓娜

---

消费身份标签改造方案评审

本次会议评审了消费身份标签的改造方案，讨论了多角色数据处理及历史数据修复，并明确了违规销售表的开发任务。

小结

1. 消费身份标签改造方案

• 背景：为满足新需求，将原有的身份标签组装逻辑改为从数据库查询用户的真实身份标签。
• 核心逻辑：系统将根据手机号查询用户拥有的所有有效身份标签（如内部人员、经销商等），并按预设的编码顺序以逗号拼接后存入数据库。若未查询到，则记录为"非系统内部人员"。
• 数据展示：在报表导出和查询时，将从数据库中的逗号分隔字段解析并还原为可读的标签名称，用"-"连接。
• 数据一致性：讨论了当前一个手机号可能存在多个身份标签的合理性。经确认，此为产品设计，暂不做数据治理，但未来可能存在数据清洗需求。

2. 历史数据修复方案

• 背景：由于此前的经销商名称数据存在错误，需要进行修复。
• 范围：本次修复主要针对5月1号之后的数据，因为在此之前的数据已基本修复完毕。
• 执行：将通过脚本对特定的经销商出货、签收等明细表进行修复。修复完成后，需将修复的交易码（trade_code）和时间记录到一张独立的备份表中，以便后续追溯。

3. 违规销售表开发

• 任务：新增"违规销售表"，用于记录违规销售的相关数据。
• 实现：在SQL中增加了5个新字段，并修改了相关的Java实体类和Service层代码，将部分查询逻辑由RPC调用改为直接赋值。

待办

1. 消费身份标签改造

• 在修复历史数据时，需为脚本增加时间筛选条件，避免全量扫描。@梁健
• 在修复历史数据后，需将修复的trade_code和时间导出至指定的备份表中。@梁健
• 在测试环境验证脚本的正确性。@梁健
• 本周内完成功能开发并上线。@梁健

2. 违规销售表开发

• 补充本次开发的技术文档，包括需求来源、SQL变更、代码修改点等。@潘玉平

---

奶酪事业部新需求技术方案讨论

本次会议主要围绕"奶酪"事业部的新需求展开，明确了扫码查证、盘点及C端红包营销三大业务场景的技术方案，并讨论了资源申请和排期等问题。

小结

1. 扫码查证

• 业务流程：用户通过SFA端扫码，系统将调用防作弊接口进行识别，若无作弊则进一步执行流向查证。
• 流向判断：判断逻辑包含两个维度：一是扫码位置是否在经销商的经营范围；二是扫码的门店/仓库与货权经销商是否存在关联关系。
• 结果分类：正常、疑似正常、无法判定、流向异常四种结果将分别记录至不同的明细表中。

2. 新路盘点

• 业务流程：SFA端执行盘点时，系统会进行防作弊校验、产品状态校验（如未售出）、重复盘点校验等。
• 数据处理：校验通过后，盘点数据将被记录至盘点明细表，并同步进行流向判断。若流向异常，则记录至流向异常明细表；若作弊，则记录至作弊明细表。

3. C端红包营销活动

• 业务流程：消费者通过小程序扫码内码，系统将调用活动规则引擎进行范围、策略、风控等多维度校验，最终由计费系统发放红包。
• 活动范围：活动范围主要依据配置的经销商和产品范围，而非用户的实时地理位置。

4. 技术方案与排期

• 部署模式："奶酪"业务将采用独立部署的方式，部分功能模块将进行多事业部升级。
• 报表："奶酪"的报表将复用现有方案，但需注意字段命名（如"营销总部"统一为"大区"）和数据口径的差异。
• 开发排期：整体开发周期预计为6月到7月初，预留一个月测试时间，计划于7月30日左右上线。

待办

1. 技术方案与资源申请

• 吴南林需尽快输出技术方案的概要设计。@吴南林
• 宋洋在技术方案完成后，负责跟进资源申请事宜。@宋洋

2. 方案细节确认

• 吴南林需与SFA侧确认，营销助手在执行查证时，其可选门店的范围是否受500米半径和所属经销商的双重限制。@吴南林
• 孔玮需与产品经理确认"奶酪"业务的数据量级，以便评估接口性能并决定是否需要申请独立的压测环境。@孔玮

3. 活动模块逻辑对齐

• 孔玮需与产品经理（陆哥）确认"奶酪"活动模块的具体配置方式和业务逻辑，确保与现有活动模块的兼容性。@孔玮

---

智慧门店人员信息补充PRD讨论

本次会议讨论了智慧门店人员信息补充的PRD，旨在解决因数据延迟导致的人员信息缺失问题，并明确了后续的开发排期与技术方案。

小结

1. 智慧门店人员信息补充PRD

• 背景：营销活动中心在处理新注册门店的记账时，因门店人员数据与主数据存在约2分钟的同步延迟，导致无法获取收款方信息，影响了签收激励的发放。
• 目标：由计费系统在营销活动中心发起记账时，主动补充获取门店人员信息，特别是收款方编码，并将结果回调给营销活动中心。
• 实现方案：
  • 计费系统将根据门店编码和角色类型（如店主）查询本地主数据视图。
  • 若本地无数据，则调用主数据的实时查询接口进行查询。
  • 查询到数据后，补充完整的收款方信息并回调给营销活动中心；若查询失败（如无数据或多人匹配），则将异常信息回调并标记记账失败。

2. 技术方案与关键问题讨论

• 接口设计：计费系统需提供一个回调接口，向营销活动中心返回补全结果（成功/失败/多条）、收款方信息及补全时间等。
• 数据有效性：讨论了人员数据的有效性判断标准，需综合考虑主表状态、关联关系子表状态以及账号类型等多个字段，确保获取到的是有效的门店人员。
• 异常处理：针对查询到的历史较早但仍在有效期内的人员数据，会议倾向于不做特殊处理，直接作为有效数据使用，并通过监控和预警机制来发现主数据同步异常。

待办

1. 接口文档与开发排期

• 营销活动中心需尽快提供接口文档，并同步详细的开发排期计划，以便计费侧进行版本规划。@李明非
• 计费侧需评估与营销活动中心对接所需的时间。@马奇

2. 技术方案细化

• 在技术方案设计阶段，需与组织侧确认并最终确定人员数据的有效性判断标准（如主表状态、子表状态、账号类型等）。@陈德智
• 需明确新、旧活动对人员信息补充接口参数的差异，并确保技术实现的一致性。@李明非