2026-05-11 工作日志
扫码签收接口调整讨论
本次会议主要讨论了扫码签收接口的调整方案，并跟进处理了经销商数据查询的bug。
小结
1. 扫码签收接口调整
- 新接口将支持门店扫码签收和自主签收两种模式，通过sign_code作为唯一标识。
- 接口参数进行了优化，如将"收货码"改为"扫码工具"并增加"小智"、"智慧门店"等固定值；将"操作人名称"、"门店名称"等字段设为必传。
- 查询接口将支持按时间范围查询，暂无性能限制，后续将根据需求评估是否增加限制。
- 新增接口将兼容新旧两种签收方式，未来可通过统一的sign_code进行查询。
2. 接口调用与数据展示
- 查询接口将返回分页数据，每页最多1000条。
- 自主签收的订单将不再返回order_id，但会返回sign_code，可用于查询明细。
- 查询商品明细将使用081接口，可通过sign_code查询到完整的订单及商品信息。
3. 经销商数据查询Bug修复
- 修复了因未查询"业务失效"状态的经销商而导致报表中无法展示其名称的问题。
- 经与业务方确认，该修改仅限于报表类场景，不影响其他业务流程。
待办
1. 扫码签收接口开发与跟进
- 完成自主签收相关接口的开发，并提供新接口的调用示例。张喜
- 组织对新接口的性能压测。张喜
2. 经销商数据查询Bug修复
- 完成bug修复并进行测试。粱健
- 整理数据修复方案，准备后续的数据修复工作。粱健
营销活动中心早会
本次会议同步了各项目进展，讨论了数据治理、技术专项及遗留问题，并明确了后续工作方向与优化点。
小结
1. 体验优化与提示优化
- SIV文案将在下午6点进行最终评审。
- 报表优化计划于5月15日上线，部分涉及前端改动的功能将延至5月28日版本上线。
- 扫码效率提升项目将在本周内完成域名更换及数据监控，以确定最终上线时间。
2. 数据治理
- 销售区域5段治理：已确认TWW系统具备所需字段，将跟进可行性研究及排期。
- 主数据一致性：已完成智慧门店相关数据比对，识别出三大类问题，并制定了解决方案和排期。后续将通过中台系统实现自动化比对。
- 小智系统：已完成数据比对，发现了部分基础数据差异，将在5月20日前完成问题分析和解决方案制定。
3. 技术专项
- 出货链路梳理：已完成流向码查询接口的梳理，将基于此完成整体出货链路的梳理。
- 图片上云：计划于6月30日切换，当前开发进度正常。
- 林雀融平台：已完成零军云平台的容灾备份梳理，并搭建了Reduce环境用于问题验证。
4. 遗留问题与昨日问题跟进
- 导购人员武断：已于5月11日完成测试并上线。
- 签收基地数据：通过手动刷数更新，长期方案将尽快组织会议讨论。
- 订单明细差异：主要原因是ERP订单备注及多次签收问题，正在跟进排查。
- 扫码B填字段：已修复因数据延迟导致的人员姓名缺失问题，历史数据将在5月12日修复。
5. 项目管理与流程优化
- 会议讨论了当前项目看板存在的问题，如信息过载、缺乏状态标识等，并提出了优化建议。
- 后续将聚焦于每日已完成的工作、今日的具体任务及需要协同的事项，以提高会议效率。
待办
1. 体验优化与数据治理
- 李赵丹需在下午6点组织SIV文案的评审会。
- 余建新需与陈祺经理确认沟通时间，推进报表及冗余字段的最终方案。
- 余建新需完成经销商电子围栏取值优化的内部PRD梳理和需求确认。
- 陈祺需跟进销售区域5段治理的可行性研究及排期。
- 邢健需完成主数据与小智系统的数据库数据源权限申请。
- 李志磊需准备图片上云的压测数据。
2. 技术专项
- 张建利需与超哥对齐5月1号的系统切换安排。
- 李亚洲需将凌讯平台的监控进展同步至日巡检清单中。
3. 遗留问题与需求跟进
- 陈祺需跟进ERP订单量差异及多次签收问题的排查进展。
- 余建新需在本周内组织会议，讨论签收基地数据的长期解决方案。
- 李亚洲需在本周内梳理高频解释性问题，并在周三给出产品体验优化的结论。
4. 项目管理流程优化
- 李亚洲需线下与各负责人沟通，调整会议模板，聚焦每日目标、任务及风险。
智慧门店报表优化与测试用例评审
发言人：余建新、吕杰、郑然然、刘莉、陈德智等10人
会议摘要：本次会议重点评审了智慧门店报表的多角色取值逻辑优化及字段变更需求，明确了字段取值逻辑需与前端传参对齐，并决定将分散的需求合并至统一版本管理。同时，针对消费者中奖明细表的身份标签逻辑进行了详细测试用例评审，补充了失效状态及多表组合的覆盖场景。
一、智慧门店报表优化需求评审
针对报表门店多角色取值逻辑及字段变更问题，会议从以下 3 个维度进行了评估与决策：
1. 多角色取值逻辑优化
- 数据源切换确认：明确将查询逻辑从旧的“店主店员表”切换至新的“电阻电源电量表”，涉及查证明细表、B端出货明细表及盘点明细表。
- 取值逻辑修正：针对“扫码人职位”字段，经技术确认该信息已由前端直接传递，无需后端进行二次匹配，仅需处理“扫码人姓名”的取值逻辑。
- 需求文档修正：要求产品经理（陈德智）根据技术反馈修正 PRD 文档，重点梳理前端传参与后端落库的逻辑差异，并补充缺失的字段定义。
2. 字段变更与需求合并
- 字段名称与新增规范：B端出货明细表需将“出货时间”更名为“出货时间（扫码）”，同时新增“出货时间扫码”字段，需明确其取值逻辑。
- 需求整合决策：为避免需求碎片化，决定将 5.12（出货时间变更）和 5.14（作弊明细表新增字段）的需求合并至吴南林维护的 V4 版本 PRD 中，统一进行评审与开发。
- 上线优先级划分：本周优先上线“字段名称修改”类需求（如产品编号改编码），新增字段的需求延后至下一版本。
3. 人员信息落库逻辑对齐
- 前端传参与后端落库冲突：针对“人员类型”和“姓名”字段，需确认前端传参与后端落库（查新表还是老表）的逻辑一致性。
- 版本依赖排查：经确认，姓名字段将在 5.28 版本由前端提供，当前需求需根据 5.28 版本的传参情况进行调整，避免逻辑冲突。
二、消费者中奖明细表测试用例评审
针对消费者身份标签的显示逻辑，会议对测试用例的覆盖范围进行了补充与修正：
1. 身份标签拼接逻辑验证
- 多表查询逻辑：确认标签显示逻辑为依次查询内部人员、经销商人员、督导购、门店人员四张表，若存在则通过横杠拼接显示（如“内部人员-经销商人员”）。
- 互斥逻辑确认：明确“非系统内部人员”标签与上述四类标签互斥，只要在任意一张表中匹配到有效数据，即不显示“非系统内部人员”。
2. 失效状态与异常场景覆盖
- 失效状态处理：补充了人员状态失效的测试场景。若人员在主数据中状态为“失效”，即使存在于表中，也应视为“非系统内部人员”，不显示相应标签。
- 多表组合覆盖：要求补充测试用例，覆盖“四张表均存在但部分失效”的混合场景，以及“多张表同时存在”的拼接显示逻辑。
三、待办事项
- 修正 PRD 文档，梳理前端传参与后端落库的逻辑，并补充缺失字段定义。 @陈德智
- 将 5.12 和 5.14 的需求合并至 V4 版本 PRD 中，并补充完整的字段变更清单。 @吴南林
- 根据最新的 Excel 表（修改名称类），编写并提交测试用例。 @刘莉
- 补充消费者中奖明细表中关于“人员失效”及“多表组合”的测试用例。 @吕杰
- 协调产品、开发、测试三方，梳理近期上线版本的排期及技术方案评审。 @马奇 @刘莉
技术走查
营销活动中心APM配置的前端监控不显示用户，已推进爱创前端技术人员进行代码分析。
问题描述：前端APM监控中用户显示为"匿名"，未设置当前系统用户。
解决方案：参考文档设置用户信息 https://apm-dcin.digitalyili.com/doc/ty-doc/docs/RUM/sdk_deploy/Web/ap/setuser/
用户ID设置：通过 localStorage 接口方式设置用户ID
报表多角色取值逻辑讨论
本次会议主要讨论了报表中门店多角色取值逻辑的优化，重点探讨了历史数据与新数据的处理方式，并明确了人员姓名缺失的解决方案。
小结
1. 报表多角色取值逻辑优化
- 查询"查证明细"表时，需根据前端筛选的"扫码人员类型"区分查询新、旧人员信息表。
- 当选择"门店店主"等旧数据时，需从旧的人员信息表中获取；选择"店长"、"店员"等新数据时，则从新的人员信息表中获取。
- 经讨论，现有报表的查询逻辑主要依赖StarRocks结果表，而人员类型等字段已在其中冗余，因此无需复杂的前后端联动改造。
2. 人员姓名缺失问题及解决方案
- 讨论了在"查证明细"等场景下，因前端未传递"人员姓名"字段，导致后端在插入StarRocks数据时该字段为空的问题。
- 由于"5.28"版本中，智慧门店、支付门店等工具因前端开发排期问题暂无法支持"人员姓名"的上传，此问题短期内无法通过前端解决。
- 最终倾向于采用后端兜底方案：在数据插入StarRocks时，通过Java程序关联MySQL，查询并补充人员姓名字段。
待办
1. 报表数据源梳理
- 由邱毅牵头，组织产品，开发、测试等相关人员，全面梳理报表各字段的数据来源、转换逻辑及依赖关系，确保各方信息对齐。
2. 人员姓名缺失问题跟进
- 宋洋与陈德智会后需与建新及小娜同步此问题的解决方案，明确后续处理策略。
3. 技术方案对齐
- 邱毅要求其团队内部（产品、技术）需尽快完成对相关技术方案的对齐，明确数据处理逻辑。
研盾项目开发
- 优化代码评审详情界面用户体验，提升错误问题信息的相关性显示。
- 解决cookie设置时的问题，问题原型通配符mapping导致controller mapping冲突。
- 优化评审结果问题统计逻辑，解决数据不准确的问题。
项目计划不可控
会议主题：经销商电子围栏取值逻辑优化（仅取电子围栏）PRD内部评审
会议改期记录：
| 时间 | 计划时段 | 变化 |
|---|---|---|
| 13:57 | 16:00 - 17:00 | 原定 |
| 14:13 | 17:30 - 18:30 | 延后1.5小时 |
| 17:05 | 17:50 - 18:50 | 再延后20分钟 |
问题分析：
- 会议在3小时内被改期2次，总计延后近2小时
- 最后一次改期距离会议开始仅45分钟
- 参与人数19人，协调成本高
风险点：
- PRD文档准备不充分
- 前置依赖未就绪
- 关键决策人时间冲突
- 会议挤占下班时间，影响团队状态
经销商电子围栏系统逻辑优化评审
- 会议主题：经销商电子围栏系统逻辑优化评审
- 发言人：余建新、吴南林、邱毅、宋洋、陈祺等10人
- 会议摘要：本次会议明确了经销商电子围栏的取值逻辑，决定统一采用电子围栏解析后的结构化数据替代手动维护的经营范围，并制定了基于经纬度直接调用云端接口的串货判定新标准。
一、核心业务逻辑与数据取值规范
针对当前系统存在“手动维护经营范围”与“电子围栏”两套逻辑并存且取值不一致的问题，会议明确了以下统一标准：
1. 数据展示与取值逻辑
- 统一采用电子围栏解析数据：在经销商档案、查证明细表、流向异常明细表等所有涉及经销商经营范围的场景中，不再使用手动维护的“经营范围”字段，而是强制使用电子围栏系统解析后的结构化数据（省市区县乡镇）。
- 数据来源澄清：主数据接口已提供三种数据（经纬度集合、解析后的行政区划、手动维护的经营范围），本次优化要求仅使用前两种，即电子围栏相关的数据，废弃手动维护的兜底逻辑。
- 术语统一：在业务侧展示时，统一使用“经营范围”或“经营围栏”作为前端文案，避免出现“电子围栏”等技术术语，但在后台逻辑中严格区分数据来源。
2. 地图展示与集成方案
- 地图展示降级：鉴于电子围栏系统已提供专业的几何图形绘制能力，决定不再在现有系统中重复开发地图绘制功能。若业务有查看地图的需求，后续将通过页面嵌入的方式直接集成电子围栏系统的页面。
- 前端展示优化：在经销商管理页面，上方展示电子围栏解析出的结构化行政区划列表，下方不再强制展示地图，仅保留查看链接或集成入口。
二、串货判定与风控规则调整
会议对流向查证、盘点等场景下的判定逻辑进行了重构，确立了“强推电子围栏”的风控原则：
1. 判定逻辑重构
- 直接调用云端接口：废除原有的“先转行政区划再比对”的逻辑，改为直接调用云端电子围栏接口，通过经纬度坐标直接判断是否在围栏范围内。
- 兜底策略调整：取消“无电子围栏则取手动维护经营范围”的兜底逻辑。若经销商未划定电子围栏，系统将直接判定为“无法判定”或“串货”，以此倒逼业务侧完善电子围栏数据。
2. 影响范围确认
- 全场景覆盖：该逻辑调整将覆盖流向查证、盘点明细表、B端出货明细表、消费中奖记录明细表等所有涉及经销商经营范围判定的业务场景。
- 接口依赖变更：原有基于行政区划转换的销售5段接口将逐步废弃，系统将全面依赖电子围栏接口返回的数据。
三、遗留问题与后续规划
1. 主数据协同
- 主数据清理：针对主数据中冗余的“手动维护经营范围”字段，确认在本次逻辑统一后，若确认不再使用，将由主数据团队进行清理。
- 人员对齐：鉴于涉及主数据字段改动，需拉通主数据团队（刘洛冰）进行标准对齐。
2. 排期与上线
- 评审结论：PRD 逻辑已通过评审，待会后补充细节后即可进入排期阶段。
- 后续安排：由马奇负责整体需求的排期协调，并安排时间与余建新进行最终确认。
四、待办事项
- 更新 PRD 文档，修正“解析”等术语，明确直接取用结构化数据及调用云端接口的逻辑。 @吴南林
- 拉通主数据团队（刘洛冰）进行字段标准对齐，并确认废弃字段的清理工作。 @陈祺 @余建新
- 安排整体需求的开发排期，并协调时间与余建新进行确认。 @马奇