铺货系统小程序

01 / BACKGROUND

项目背景

代理商在线下进行铺货和提货时，分销商资料、二维码信息和实际扫码记录原本缺少统一管理。人员关系、提货记录和二维码之间如果没有稳定的数据关联，就容易出现分销商资料变化后历史记录无法核对、删除后关系丢失、重复扫码无法区分以及后台无法快速定位责任对象等问题。项目因此需要通过小程序建立代理商与分销商的基础关系，并将每一次扫码提货转化为独立、可查询的数据记录。同时入口统一放在各电商公司服务号菜单中，降低使用门槛，并通过登录状态有效期减少重复登录带来的操作成本。

02 / MY ROLE

我的职责

梳理代理商从服务号进入小程序、登录、首次完善资料、维护分销商、扫码提货到查看扫码记录的完整流程；明确姓名必填、公司名称选填以及登录有效期内免重复登录等基础规则；设计分销商新增、编辑、逻辑删除和排序逻辑，并规定存在扫码记录后不可继续编辑，但仍允许逻辑删除，避免历史关系被改写；定义二维码域名、URL结构和业务参数校验规则，确保无效二维码或参数异常时不写入业务记录；明确业务字符串解析方式，并允许同一二维码重复扫码，每一次扫码均独立保存；规划扫码记录每页50条、按录入时间倒序展示，以及管理端通过业务字符串反查代理商、分销商和扫码详情的能力；补充无效二维码、参数缺失、已删除分销商、重复扫码、空数据、查询异常等测试场景，并参与联调和上线验收。

03 / CORE PROBLEMS

核心问题

第一，代理商、分销商与二维码之间需要建立稳定关系，但线下提货允许同一二维码重复出现，因此业务绑定不能简单按唯一关系处理；第二，二维码不仅要判断来源是否合法，还要正确解析URL结构和业务字符串，任何关键参数异常都必须阻止无效记录写入；第三，分销商被删除后历史扫码仍需保留并可查询，因此必须采用逻辑删除而不是物理删除；第四，分销商一旦存在扫码记录，如果继续修改关键资料可能造成历史关系失真，因此需要限制编辑，但仍保留删除能力；第五，正常与已删除分销商要在同一套查询和排序规则下展示，既保证当前使用效率，也不能牺牲历史可追溯性；第六，管理端需要能够通过扫码字符串快速反查完整上下游关系，降低异常核对和历史排查成本。

04 / SOLUTION

解决方案

将业务拆分为登录与资料、分销商管理、扫码提货、扫码记录和管理端查询五个模块。用户首次进入时完善姓名和可选公司信息，之后在登录状态有效期内直接进入业务页面；分销商采用逻辑删除机制，历史数据持续保留，列表按照正常数据优先、已删除数据靠后，并在各自范围内按录入时间从新到旧展示；扫码时先校验二维码域名、URL结构和必要参数，再解析业务字符串并生成独立扫码记录，同一二维码允许重复扫码，以符合实际提货场景；一旦分销商已经产生扫码记录，限制继续编辑以避免历史关系被覆盖，但仍允许执行逻辑删除；管理端通过业务字符串关联查询代理商、分销商及扫码详情，使每一次提货行为都能够从记录反向追溯到对应人员关系。

05 / PROCESS & RULES

关键流程或业务规则

06 / RESULT & REVIEW

项目结果与复盘

形成了覆盖代理商资料、分销商维护、二维码校验、扫码提货、记录查询和后台追溯的完整小程序方案。原本分散在线下的人员关系与提货行为被转化为结构化数据，每一次扫码均可独立保存并追溯；分销商删除或资料状态变化不会影响既有历史记录。同时通过二维码合法性校验、重复扫码保留、逻辑删除、编辑限制和统一排序等规则，降低了脏数据、关系错乱和历史记录无法核对的风险，也为后续运营统计、渠道分析和异常排查提供了更稳定的数据基础。

复盘这个项目表面上是一个扫码工具，真正的难点却在扫码前后的关系管理和历史一致性。当业务同时要求“二维码允许重复出现”“删除后历史仍可查询”“产生记录后不能继续编辑”时，产品设计必须把业务对象的当前状态和历史记录分开处理。二维码是否唯一，与每一次扫码记录是否唯一，也是两个不同层次的问题：同一个业务二维码可以重复出现，但每次扫码行为都应该独立留痕。对于这类线下业务数字化场景，逻辑删除、操作权限、历史快照和反向追溯能力往往比扫码动作本身更重要。