Work for YILI

Appearance

2026-06-23 工作日志 ​

每日站会 ​

本次会议同步了各项目进展，明确了后续工作安排，重点讨论了性能优化、数据治理及遗留问题的处理。

小结 ​

1. 产品优化与版本规划

  • 活动中心：列控功能及修复"先售出后出货"数据问题的两个功能将定于 6 月 25 日上线
  • 其余功能将随 7 月 2 日的灰度版本一同上线
  • 扫码盘点功能的需求评审已定于当天下午 13:30 进行

2. 各项目进展同步

智慧门店：按计划推进本周的盘点和基础方案工作。

性能优化：

  • APM 接入前端页面的启动时间需进一步明确
  • "附近门店"定位慢的问题将组织专项会议进行分析
  • SFA 将进行加锁测试，需关注极限场景下的性能表现

数据治理：

  • DMS 与 TTS 在调拨场景下的测试环境问题已恢复，可继续测试
  • 高德地图 API 因短时间内调用次数过多导致失败的问题，已调整为单码调用并等待发版修复
  • 地址解析失败问题，测试环境已解决，等待发版

3. 遗留问题与风险

  • 数据一致性：云商侧监控到新的数据一致性告警，需排查原因
  • 门店人员数据差异：将组织会议分析监控到的门店人员数据差异问题
  • 前端必传字段：因用户关注，将组织三方会议确认"以上查证"问题的技术方案及排期

待办 ​

1. APM 接入前端页面

  • 张建利需与对方确认并获取一个准确的启动时间
  • 李赵丹需与赵丹、宏伟沟通对接事宜

2. 技术方案与开发

  • 李赵丹需在今天完成 TTS 第一批上线范围的最终确定
  • 张建利需在今天完成双连接超时问题的方案评审
  • 刘晓娜需在今天将前端必传字段的 PRD 发出，并根据各端反馈给出排期

3. 性能与稳定性问题

  • 李赵丹需整理并同步 6 月 13 日版本上线后的安卓/iOS 卡顿问题的分析数据和现状
  • 李赵丹需组织关于"附近门店"定位慢问题的专项会议
  • 龚明需跟进 SFA 加锁测试的极限场景报告

4. 数据与问题跟进

  • 邢健需组织会议分析智慧门店的门店人员数据差异问题
  • 邢健需排查并处理云商侧的数据一致性告警
  • 李宝仟需组织会议，与三方确认"以上查证"问题的技术方案及排期

5. 测试工作

  • 李亚洲需组织统一的线上测试号，进行门店与小智各端的联调测试

查证即签收与盘点即签收方案讨论 ​

本次会议主要讨论了"查证即签收"和"盘点即签收"的业务逻辑、技术实现方案及相关待办事项。

小结 ​

1. 查证即签收

  • 核心逻辑：用户通过扫码等方式进行查证，系统将自动完成签收操作，生成相应的签收记录和流向信息。
  • 签收类型：新增"查证签收"和"查证异常签收"两种类型，用于区分正常和异常的签收场景。
  • 异常签收：在跨门店、跨经销商等异常情况下产生的签收，不参与后续的 BC 活动。
  • 已售商品：对于已售出的商品，系统将不再生成新的签收记录，仅作信息展示，避免数据冲突。

2. 盘点即签收

  • 核心逻辑：用户在盘点商品时，系统将自动完成签收操作，其逻辑与"查证即签收"高度相似，但前端流程整合为"扫码及提交"一步。
  • 签收类型：新增"盘点签收"和"盘点异常签收"类型。
  • 特殊场景：明确了大宗团购商品不允许进行盘点和签收。

3. 技术实现与交互

  • 数据处理：在"查证即签收"和"盘点即签收"场景下，系统会生成相应的出货、退货、签收等记录，以确保数据完整性。
  • 前端交互：查证签收过程对用户无感知；盘点签收则会给予"盘点成功"的提示。若签收因校验失败而失败，前端会给出明确的错误原因。

待办 ​

1. 技术方案与逻辑确认

  • 刘晓娜 需确认"查证签收"和"盘点签收"是否需要校验距离，以及如何与其他签收逻辑（如"扫码签收"）进行优先级判断。
  • 刘晓娜 需明确"无货权"商品在查证场景下的处理逻辑。
  • 刘晓娜 需确认"已售"商品在查证时的具体交互表现。
  • 刘晓娜 需明确"大宗团购"商品在"扫码查证"时是否允许签收及其对活动的影响。
  • 刘晓娜 需明确"调拨"状态下的商品是否允许进行盘点和签收。

2. 数据与报表

  • 刘晓娜 需确认"查证即签收"和"盘点即签收"场景下，是否需要在前端报表中新增"查证出货"、"盘点出货"等类型。
  • 刘晓娜 需梳理并统一"扫码时间"、"提交时间"等相关时间字段在各类报表中的定义和展示逻辑。

3. 业务评审与沟通

  • 刘晓娜 需在业务评审会上，与业务方沟通并确认上述所有待办事项的最终方案。

数据修复与接口异常修复方案评审会 ​

发言人：潘玉平、邱毅、王建朝、孙世文、张建利等 10 人

本次会议评审了门店签收数据修复的合规性，决定移除接口正则校验以兼容主数据格式，并确定了分页参数容错方案，同时规范了技术文档模板。

小结 ​

1. 门店签收数据修复方案评审

针对门店数据推送延迟导致的签收机率未中奖问题，会议重点评估了数据修复的合规性与风险控制。

  • 修复执行确认：孙世文已完成对端午前几十笔至一百多笔异常订单的数据修复，目前数据已恢复正常。
  • 方案评审必要性：鉴于修复操作已执行完毕，且涉及数据量较小，王建朝建议不再进行方案评审，由团队内部把控即可。
  • 备份缺失风险：贾继伟指出本次修复未按规范建立临时表备份异常数据，导致无法进行数据回滚或追溯。
  • 流程规范要求：明确后续类似修复操作必须提前沟通，并建立包含码（Code）信息的临时表进行数据备份，以便异常时回滚。

2. 查询经销商关联门店接口异常修复

针对 APM 告警中发现的接口 404 错误，会议深入分析了根因并制定了修复策略。

  • 特殊字符兼容问题：接口因正则表达式限制，无法识别包含下划线的 source_id，导致传入特定参数时直接报错。
  • 校验逻辑争议：潘玉平提出在正则中增加下划线支持；邱毅质疑校验必要性，认为主数据来源可靠，无需额外校验。
  • 最终决策：鉴于 source_id 格式多样且来源于主数据，决定移除正则校验逻辑，直接透传参数，避免因格式变化导致后续维护成本。
  • 数据库关联关系核查：经现场查询数据库，确认 source_id 对应 shop_address 表的地址层信息，而非门店主表 ID，验证了查询逻辑的合理性。

3. 盘点分页接口参数异常修复

针对智慧门店传参分页值为负数导致服务异常的告警，会议制定了容错与联动方案。

  • 参数容错处理：采纳方案一，在接口层增加参数修正逻辑。若分页数小于 0 则修正为 0，分页大小小于 0 则修正为 10，避免服务崩溃。
  • 异常阻断方案：否定了方案二（抛出异常），认为直接修正参数对前端无感知，改动范围小且风险可控。
  • 调用方排查：确认异常参数来源于智慧门店前端，需通知前端团队确认修正后的默认值是否影响其业务逻辑。
  • 文档更新要求：要求更新技术文档，明确接口参数的默认值修正逻辑，并同步给各调用端进行确认。

4. 技术规范与后续安排

  • 技术文档规范：要求后续技术方案文档必须包含背景、原因及详细方案，统一按照潘玉平的文档格式或谢明飞的模板进行编写。
  • 遗留事项处理：韩冬冬关于智慧门店数据延迟补发基地的方案尚未完成，待完善后另行安排评审。

待办 ​

  • 孙世文 需将本次数据修复涉及的码（Code）清单发送给贾继伟进行备份。
  • 潘玉平 需更新盘点分页接口的技术文档，标注参数默认值修正逻辑，并同步给各调用端确认。
  • 潘玉平 需与张琪确认盘点接口分页参数的最大值限制。
  • 孙世文 需按照统一模板（含背景、原因）重新编写技术方案文档。