2026-05-15 工作日志
待办事项
- [ ] 更新技术价值文件 (update tech value file)
- [ ] 提醒我打印字帖 (notice me to print 字帖)
项目进度同步会
本次会议同步了各项工作的进展，重点讨论了数据治理、前端性能优化及APM监控等议题，并明确了后续的跟进事项。
小结
1. 前端性能与监控
- APM监控：已完成登录页数据分析，首页和扫码收货页面的数据分析将在今日完成。后续将按此方法对所有非核心页面进行全量盘点。
- 神策（Sensors）：全局埋点已进入开发阶段，同时自定义埋点的梳理工作也已启动。
- 前端性能：地图加载效率优化的相关结果将在会后进行同步。
2. 数据治理与问题排查
- 数据一致性：智慧门店及小智系统内的客户数据、门店数据差异问题正在按计划推进中。针对门店关系数据的大批量清洗方案，需进一步评估其对业务的影响。
- 订单差异：针对ERP订单与调账场景不匹配的问题，团队将重新与财务部沟通，以更准确地理解业务场景后再制定解决方案。
- 数据补录：已完成补数方案的排期，最高优先级为经销商的签收时间。
3. 技术优化与专项跟进
- SSC处理：为应对手动补录工作量大的问题，已采用大模型生成文档的方式进行梳理，明日将确认输出结果的准确性。
- 架构优化：已识别到一个优化点，将先在测试环境进行演练，待验证通过后再上线生产环境。
4. 业务需求与问题反馈
- 门店管理：针对连锁便利门店无导购的场景，已在店主店员管理页面增加了筛选功能。
- 数据问题：针对因门店签收时间缺失导致的数据问题，将进行整体盘点并着手处理。
待办
1. 各项工作进度同步与跟进
- 赵丹需在会后立即完成前端性能探查部分的进度同步。
- 余建新今日需完成扫码签收电路优化方案的评审。
- 刘晓娜今日需盘点因门店签收时间缺失导致的数据问题，并进行数据回补。
2. 关键事项沟通与协调
- 陈祺今日将与王龙沟通销售区5段的推进计划，并与超哥沟通TTS大于DTS的数据差异问题。
- 吴菊今日将与邢健对齐整体的对数范围。
- 刘晓娜今日需与人民确认B端传入字段的具体场景和字段列表。
3. 组织协调
- 李亚洲会后将组织相关人员开会，讨论数据治理中的TW系统ID获取及数据差异等问题。
扫码盘点即提交方案讨论
本次会议讨论了扫码盘点即提交的新方案，旨在解决盘点时间晚于售出时间的问题，并明确了前后端的改造点和后续工作。
小结
1. 新的扫码盘点方案
- 为解决因前端缓存导致的盘点数据错误问题，将采用"扫码盘点即提交"的新方案，实现从根源上控制问题。
- 营销活动中心将提供一个全新的实时同步接口，用于扫码盘点及提交。
- 新接口将增加对"已过期产品"的校验，若产品已过期则不允许盘点。
2. 前端交互与数据统计
- 为保证用户体验，前端交互将维持不变，即用户扫码后即视为提交。
- 中台将提供一个批量提交接口，前端可调用此接口将多次扫码的结果一次性提交，以实现"扫码即提交"的效果。
- 数据统计维度将调整为按门店、天、用户进行统计，不再按订单维度聚合。
3. 手动输入与拍照要求
- 在非扫码的场景下（如手动输入字符串或批次号），需要上传环境照片。
- 本次需求不包含OCR识别功能，仅保留手动输入字符串和批次号的场景。
4. 项目排期
- 本次需求计划在 6月25日 版本中上线。
- 四端将进行需求评审，时间暂定在 下周三。
待办
1. 需求与方案完善
- 陈德智需将前端现有盘点场景的校验逻辑整理成表格，并补充到PRD文档中。
- 陈志伟需根据会议结论，更新产品方案，明确以下几点：
- 移除"按天统计"的功能，仅在扫码操作页移除相关统计数字。
- 明确前端需保留的校验逻辑（如一天只能盘点一次、特定状态下禁止盘点）。
- 移除"上传环境照片"的功能，仅在手动输入场景下保留。
- 移除"统计作弊数量"的字段。
- 刘晓娜需牵头组织四端需求评审，时间定于下周三。
2. 技术实现
- 刘晓娜需提供新的盘点接口文档。
- 陈德智需提供新的"查码"接口，用于前端判断盘点是否成功。
- 陈志伟需将新的接口地址补充到产品方案中。
3. 信息同步
- 陈昊需与刘晓娜同步本次会议内容。
门店自主签收功能评审会
本次会议评审了门店自主签收、BC营销距离控制及箱提关系等功能，明确了相关规则、测试要点和待办事项。
小结
1. 门店自主签收功能
- 核心规则：明确了有/无货权、扫码范围、距离限制等多种签收场景下的规则。例如，有货权且在配置距离内可签收；若距离超出，则不允许。
- 扫码校验：新接口采用顺序校验，依次检查距离、码有效性、是否提内码、箱拆箱标识等。测试时采用控制变量法，确保每项规则都能被有效触发即可。
- 异常状态：明确了"已退货"、"已核销"、"过期"、"追溯码/自付码不存在"等状态下不允许签收。
- 历史数据：讨论了历史数据中"已退库"状态的字典值问题，确认应修改为"调拨待签收"状态。
2. BC/大宗出货与签收距离控制
- 规则逻辑：签收和出货均受B端规则控制，若门店距离超出配置范围，则不允许操作。
- 动态调整：测试时可通过修改门店经纬度或B端规则配置来动态调整距离阈值，验证其灵活性。
- 前后端交互：明确了营销活动中心的B端规则与营销助手前端的距离校验逻辑。
3. 箱提关系与拆箱标识
- 功能背景：引入"拆箱标识"字段，用于区分箱体是否为拆箱状态，以控制后续的签收、出货、盘点等操作。
- 核心逻辑：当箱体被标记为"拆箱"（标识为1）时，将禁止其进行盘点；若标识为"0"，则恢复原有逻辑。
- 兼容性：新旧域名下的扫码签收流程均需兼容，确保功能正常。
基础码表数据修复方案讨论
本次会议主要讨论了因主数据问题导致的基础码表数据修复方案，明确了修复逻辑、执行方式及后续的数据留存要求。
小结
1. 基础码表数据修复方案
- 问题背景：因历史数据迁移及主数据问题，导致MongoDB中的code_info表存在部分货权经销商名称为空的情况，影响了新年度盘点。
- 修复目标：为code_info表中的所有货权经销商编码非空但名称为空的数据，补充完整的经销商名称。
- 修复方案：韩冬冬已将相关数据导入SR系统创建临时表，后续将通过临时表中的数据，以code作为主键，批量更新MongoDB中的code_info表。
2. 新鲜度盘点表数据修复方案
- 问题背景：新鲜度盘点表存在少量数据无法通过SQL子查询进行更新的情况。
- 解决方案：针对此特殊情况，将采用Excel逐条生成Update语句的方式进行修复。
3. 数据修复执行与风险
- 执行方式：韩冬冬计划使用Java脚本进行批量更新，已在开发环境验证通过。
- 风险评估：王建朝指出，由于数据量较大（约70万条），需关注脚本在生产环境执行时对SR服务的性能影响。
4. 数据留存与追溯
- 追溯需求：为便于后续追溯和审计，需要在SR系统中建立一张明细表，记录本次修复所涉及的所有code码及其修复日期。
待办
1. 数据修复方案跟进
- 韩冬冬需将本次修复所生成的SQL脚本发送给徐东老师，以评估其对SR服务的影响。
- 韩冬冬需将本次修复所涉及的code码信息导出，并建立明细表进行留存。
2. 主数据问题根因跟进
- 邱毅需联系罗斌和小娜，跟进并解决主数据问题的根本原因，确保类似问题不再发生。
3. 修复方案执行计划
- 韩冬冬需在下周安排修复任务的执行，因数据量较大，建议在工作日进行，以规避周末无人值守的风险。