2026-05-12 工作日志
项目进度同步会
本次会议同步了各项目组的进度，讨论了体验优化、数据治理、技术专项等问题，并明确了后续的跟进事项。
小结
1. 体验优化 Top3
- 前端提词优化：将在今天下午4点进行最终评审。
- 人名相关优化：项目已进入Mock测试阶段，按原计划推进。
2. 数据治理
- 报表字段：业务侧仍在确认冗余字段，需尽快完成。
- 主数据与智慧门店：已完成解决方案确认，正在进行数据比对和自动化监控配置。
- 主数据与小智：已修复客户数据重复问题，正在监控系统运行情况。
3. 技术专项
- Redis性能问题：已定位根因并完成修复，问题得到彻底解决。
- 前端性能探查：将提前至11号版本进行，需尽快完成相关页面的监控配置。
4. 新增待定位问题
- ERP订单调账差异：将由任经理牵头，在本周四召开共识会，与各方沟通并制定处理方案。
- 云商传输多次签收：此问题为预期现象，暂不做处理。
待办
1. 项目进度跟进
- 前端提词优化：李赵丹需在今天下午4点前完成评审。
- 报表字段确认：余建新需在今天下午跟进并推动业务侧完成确认。
- 销售区域费用：陈祺需在今天再次确认供应商提供的费用。
- 主数据与智慧门店差异：任明和杜婷需跟进后续的人工验证工作。
2. 技术与方案推进
- 前端性能探查：李赵丹需将相关页面的性能监控梳理并加入待办。
- SFA提词优化：李赵丹需在今天同步SFA提词优化的模板。
- ERP订单差异处理：陈祺需在本周四牵头召开共识会。
- 主数据与小智数据一致性：邢健需跟进第二轮数据比对发现的新问题。
3. 人员与文档
- 出货端模板：张建利需在今天同步模板。
- 各端人员角色：陈祺需在5月11号前，协调各方提供相关人员的角色流程文档。
日常开单与自主签收数据回补方案讨论
本次会议主要讨论了日常开单与自主签收的历史数据回补方案，以及鲜度盘点表中经销商信息缺失的修复方案，并明确了后续的执行细节。
小结
1. 日常开单与自主签收数据回补
- 背景：新增逻辑要求日常开单需有签收数据，自主签收需有出货数据，因此需回补历史数据。
- 方案：采用SQL脚本进行全量数据回填，将出货信息补充到签收记录，或将签收信息补充到出货记录。
- 数据量：预估数据量较大，约有200万至400万条。
- 问题：存在部分字段（如手机号、经纬度）因加密/解密规则不同，无法通过SQL直接回补。
- 结论：初步方案可行，但需先确认回补的具体时间范围（如仅限2025年至今），并需与产品侧沟通确认无法修复字段的方案。
2. 鲜度盘点表经销商信息缺失问题修复
- 背景：因基础码表在数据迁移时缺失经销商名称，导致"鲜度盘点"表中的货权经销商"5段"及"经营围栏"信息缺失。
- 方案：通过定时任务结合SQL脚本进行数据回补，获取完整的经销商信息。
- 问题：问题根源在于旧数据迁移时，基础信息表仅有编码而无名称。会议指出需在方案中明确区分不同缺失情况（如仅编码为空、仅名称为空），并追溯问题根源。
待办
1. 数据回补范围确认
- 需与产品侧确认日常开单和自主签收数据回补的具体时间范围，建议先回补2025年至今的数据。梁健
2. 无法修复字段方案沟通
- 针对因加密规则不同导致无法通过SQL回补的手机号字段，需与产品侧沟通确认后续修复方案。梁健
3. 错误问题定位与方案修正
- 需重新审视并修正"鲜度盘点"问题的技术方案文档，明确问题根源（如数据迁移导致），并区分不同缺失情况下的数据。韩冬冬、张喜
4. PT环境验证
- 已在昨日完成，需将验证结果按计划维护。梁健
流向接口批次字段及项目排期讨论
本次会议主要讨论了流向接口是否新增批次字段、项目排期及合同签署事宜，并明确了后续的交付节点。
小结
1. 流向接口批次字段问题
- 营销活动中心需要在流向环节获取批次信息，但经讨论，决定不在流向接口中新增批次字段。
- 若需使用批次信息，将通过查询生产信息表中的批次字段来获取。
2. 项目排期与交付
- 项目整体计划在 6月12日 左右完成联调，开发周期约两周，测试一周。
- 接口定义将在本周内确认，并计划在 6月8日 提供新地址。
3. 合同签署事宜
- 项目合同的签署方（由生产侧的孙博或市场侧的唐璐负责）尚未最终确认，此为项目潜在风险点。
待办
1. 接口定义与样例提供
- 李超需在本周内确认接口字段定义，并在 6月8日前 提供接口定义及样例。
2. 合同签署事宜跟进
- 马佳需推动事业部尽快敲定合同签署事宜，以避免影响项目排期。
3. TTS计划同步
- 李超需将TTS侧的开发计划补充到项目排期表格中。
4. 联调测试计划同步
- 马佳需将TTS侧的个性化开发工作补充到项目排期表格中。
报表列控优化及出货扫码加锁方案讨论
本次会议主要讨论了报表列控优化、出货扫码加锁方案、签收链路优化及门店日常开单控制等问题，并明确了相关方案。
小结
1. 报表列控优化
- 筛选条件优化：讨论了筛选条件的交互方式，倾向于将筛选项平铺展示，并支持勾选。同时，需要梳理并统一各端（如营销活动中心、云商端）的筛选条件，确保逻辑和交付方式一致。
- 列控交互优化：计划对列控功能进行交互优化，将字段分组展示，并支持默认勾选，以减少冗余字段的下载量。
- 冗余字段处理：会议指出当前报表存在冗余字段，如"事业部品牌"与"产品品牌"、"出货人"与"出货经销商"等。会议决定优先处理这些冗余字段，但需谨慎对待"是否重码"、"TTS回补"等字段，因其可能涉及历史数据和业务逻辑。
2. 出货扫码加锁方案
- 核心目标：解决"一码多出"的问题，确保每个商品码在同一时间只能被处理一次。
- 加锁逻辑：采用单据级加锁，锁定时间从最后一个扫码动作开始计算，并滚动加锁30分钟后自动解锁。加锁状态会通过UI提示，用户也可手动解除。
- 解锁机制：用户可通过删除单条扫码记录、清除APP缓存或超时等方式手动解除加锁。
- 上线策略：讨论了新旧版本共存时的历史缓存单据处理问题，倾向于在新功能上线时，将存量未提交单据进行清理。
3. 签收链路优化
- 自主签收：讨论了允许二次签收的方案。核心逻辑为：允许同一商品码在不同门店被签收，但首次签收者获得激励；若货权与签收门店不一致，则视为异常签收并记录，但不影响后续流程。
- 退货逻辑：明确了在允许二次签收的场景下，系统将自动触发退货流程，以确保货权归属清晰。
4. 门店日常开单控制
- 目标：控制"日常开单"功能，仅允许特定渠道（如现代渠道、CS/CSV小店）的门店使用。
- 实现方案：讨论了两种实现方式，一是调整前端筛选逻辑，先选门店再选出货类型；二是采用经销商白名单方式进行控制。两种方案均需进一步确认可行性。
待办
1. 报表列控优化
- 需梳理并统一各端的筛选条件逻辑，确保交付方式一致。
- 需尽快确认并输出一份报表字段的最终列表，明确哪些字段可以删除、修改或保留。
- 需为"事业部品牌"等关键字段增加清晰的注释，以便业务人员理解其含义。
2. 出货扫码加锁方案
- 需设计并提供扫码记录页面的UI文案，用于提示用户"本地已暂存有尚未完成的出货信息"。
- 需确认扫码单据的全局解锁时间配置方式，倾向于通过后台配置项修改，而非新增页面。
- 需在新功能上线时，制定并执行清理历史未提交单据的方案。
3. 签收链路优化
- 需进一步讨论并明确"横条"（横向调拨）场景下的数据记录方式，例如是作为退货记录还是新建一种"横条"状态。
- 需确认"经销商签收时间"字段的取值逻辑，倾向于采用TDS数据上传时间作为参考。
4. 门店日常开单控制
- 需确认"日常开单"功能中，按门店类型进行筛选的可行性。
- 需将"我司人员门店拜访环节增加查看门店签收记录"的需求记录并跟进。