铺货系统小程序

01 / BACKGROUND

项目背景

代理商在线下开展铺货和提货时，分销商资料、二维码信息和实际扫码记录缺少统一管理，容易出现人员关系不清、历史记录难追溯、重复扫码无法核对等问题。项目需要通过小程序建立代理商与分销商的基础关系，并将每一次提货扫码转化为可查询的数据记录。同时，入口统一放在各电商公司服务号菜单中，减少用户寻找路径，并保证登录状态在有效期内持续可用。

02 / MY ROLE

我的职责

梳理代理商从服务号进入小程序、登录、首次完善资料、维护分销商、扫码提货和查看扫码记录的完整流程；明确姓名必填、公司名称选填及登录未过期免重复登录等基础规则；设计分销商新增、编辑、逻辑删除和排序逻辑，并规定存在扫码记录时不可编辑但仍可删除；定义二维码URL合法性校验、业务字符串解析、重复绑定允许及异常提示；规划扫码记录每页50条、按录入时间倒序展示和管理端按字符串反查代理商及分销商信息；补充无效二维码、参数缺失、已删除分销商、重复扫码、空数据和查询异常等测试场景，并参与验收。

03 / CORE PROBLEMS

核心问题

第一，代理商、分销商和二维码之间需要建立稳定关系，但线下扫码可能重复发生，系统不能简单按唯一绑定处理；第二，二维码不仅要校验域名，还要正确解析业务字符串，任何参数异常都必须阻止无效记录写入；第三，分销商删除后历史扫码记录仍需保留，因此不能物理删除；第四，存在扫码记录的分销商如果继续编辑，可能导致历史关系失真，需要限制编辑但允许逻辑删除；第五，正常和已删除分销商需要统一查询，同时保持清晰排序，管理端还要能通过扫码字符串快速反查完整关系。

04 / SOLUTION

解决方案

将业务拆分为登录与资料、分销商管理、扫码提货、扫码记录和管理端查询五个模块。用户首次进入时完善姓名和可选公司信息，之后在登录有效期内直接进入业务页面；分销商采用逻辑删除并保留历史数据，列表按正常优先、已删除靠后，再按录入时间从新到旧排序；扫码时先校验二维码域名和URL结构，再解析业务字符串并写入扫码记录，允许同一二维码重复绑定以符合实际提货场景；一旦分销商存在扫码记录，编辑入口受限，避免历史关系被改写；管理端则通过业务字符串联表查询代理商、分销商和扫码信息，形成完整追溯链路。

05 / PROCESS & RULES

关键流程或业务规则

06 / RESULT & REVIEW

项目结果与复盘

形成了覆盖代理商资料、分销商维护、扫码提货和后台追溯的完整小程序方案。线下铺货关系被转化为结构化、可查询的数据记录，历史扫码不会因分销商删除或资料调整而丢失。二维码校验、重复扫码、逻辑删除和编辑限制等关键规则得到统一，降低了脏数据、关系错乱和历史追溯困难的风险，也为后续运营统计和渠道分析提供了稳定的数据基础。

复盘这类项目的难点不在扫码动作本身，而在扫码前后的关系管理和历史数据一致性。当业务同时要求“允许重复绑定”“删除后仍可查询”“有记录后不能编辑”时，必须把每个状态下的可操作权限写清楚。产品设计还需要区分业务唯一性和记录唯一性：二维码可以重复出现，但每次扫码记录都应独立保存并可追溯。