简介：这份PPT聚焦中国免税品集团总公司中免集团的零售管理流程，面向零售运营、门店管理与信息化建设相关从业者，帮助梳理免税零售业态差异、特殊业务流程与系统需求。内容覆盖市内店、口岸店、供船店三类业态的客源、商品、销售与提货方式对比，并详细拆解市内店顾客卡办理、六联销售单据流转、机场提货与海关核销，以及供船店预订单、登船推销、报关出库与代理转账等特殊流程。同时延伸至门店商品计划、采购、收发货退货、运营与财务处理，并给出消费者行为分析流程改进要点及POS系统核心需求，如客户信息快速录入、VIP与团队客户管理、应收控制账户等。资源包为1个pptx文件，约557KB，结构紧凑，适合作为零售业务流程梳理与系统需求分析的参考材料。目前已有60人学习。

1. 零售业务流程与系统需求：从一张 PPT 到可落地的需求清单

很多零售项目翻车，不是因为技术选型错了，而是因为一开始就没人把「业务流程」和「系统需求」这两件事对齐。我见过太多团队拿着几十页 PPT 讲门店补货、会员积分、促销引擎，讲得头头是道，结果开发做完第一版，业务方一句「这不是我要的」直接打回重做。问题出在哪？出在 PPT 里的流程是给人看的，系统需求是给机器执行的，中间缺了一层翻译。零售这个场景尤其明显：门店、仓储、电商、客服、财务五条线交叉，任何一个环节的流程断点都会变成系统里的脏数据。所以这篇笔记要聊的，就是怎么把一份零售业务流程 PPT，拆成开发能直接照着建表、写接口、配规则的系统需求。适合正在做零售中台、ERP 对接、门店数字化改造的工程师和产品经理，尤其是那种「业务方只给了一份 PPT，让你两周出方案」的情况。

2. 先拆业务流程：零售 PPT 里哪些图能直接用，哪些是坑

2.1 零售业务流程的三条主线与常见画法

零售业务不管规模大小，流程基本绕不开三条主线：商品从采购到上架的供应链主线、顾客从进店到复购的交易主线、钱从流水到对账的财务主线。PPT 里常见的画法是泳道图，横轴是角色（采购员、仓管、店长、收银、财务），纵轴是步骤。这种图看着清楚，但直接拿来做系统需求会踩坑，因为它把「人工审批」和「系统动作」画在了同一个框里。

我一般会先把泳道图里的每个节点标上三种颜色：绿色是纯系统自动完成，黄色是系统辅助人工决策，红色是纯人工线下操作。绿色节点直接对应接口或定时任务，黄色节点对应工作流引擎里的待办和规则，红色节点要么砍掉，要么做成系统里的备注字段。这一步做完，你会发现 PPT 里至少三分之一的流程节点根本不需要进系统。

2.2 从泳道图到状态机的转换方法

零售系统里最核心的抽象是状态机。以采购单为例，PPT 上可能只画了「创建→审批→发货→收货→入库」五个框，但系统里必须定义清楚每个状态之间的迁移条件、触发角色和超时策略。下面这段 Python 伪代码展示的是我常用的状态机定义方式，用字典描述迁移规则，方便后续直接生成数据库配置表。

# 采购单状态机定义：状态 -> {触发事件: (目标状态, 允许角色, 超时小时)} purchase_fsm = { "draft": { "submit": ("pending_approval", ["buyer"], None), "cancel": ("cancelled", ["buyer"], None), }, "pending_approval": { "approve": ("approved", ["manager"], 24), # 24小时未审批自动提醒 "reject": ("draft", ["manager"], None), }, "approved": { "ship": ("shipped", ["supplier"], 48), # 48小时未发货触发预警 "close": ("closed", ["buyer"], None), }, "shipped": { "receive": ("received", ["warehouse"], None), "return": ("returning", ["warehouse"], None), }, "received": { "stock_in": ("completed", ["warehouse"], None), }, }

这段代码的逻辑是：每个状态只暴露有限的合法事件，事件触发时校验角色权限，超时字段用于生成定时任务。参数上，超时小时为None表示不设超时，设为数字则会在对应时间后往消息队列推一条提醒。实际落地时，我会把这张字典直接存进配置表，运营可以在后台改超时时间，不用发版。

提示：状态机里不要出现「其他」「待定」这类模糊状态，每个状态必须有明确的进入条件和退出条件，否则后期报表统计一定对不上账。

3. 系统需求怎么落：从流程节点到接口和表的映射

3.1 需求条目的四要素写法

PPT 里的流程描述是「采购员提交采购申请，经理审批后发给供应商」，这句话直接给开发，开发只能猜。我要求团队里的需求条目必须写成四要素：触发条件、输入数据、处理规则、输出结果。上面那句话翻译过来就是：触发条件是采购员点击提交；输入数据是商品编码、数量、期望到货日；处理规则是校验商品编码存在且数量大于零，然后生成待审批任务；输出结果是采购单号和一个待办消息。

这四要素写清楚之后，接口的入参出参基本就定了。我习惯用一张 Markdown 表格来管理需求条目，字段包括需求编号、关联流程节点、四要素描述、优先级、验收标准。这张表就是后续测试用例的源头，验收标准写不清楚的需求，一律打回重写。

3.2 用 SQL 建表验证需求完整性

需求写完不能只靠人眼检查，我一般会先建核心表，用建表语句反向验证需求有没有遗漏。下面这段 SQL 是零售采购模块的简化版建表，重点看字段和约束是否覆盖了前面状态机里的所有状态。

CREATE TABLE purchase_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '采购单号', status VARCHAR(20) NOT NULL DEFAULT 'draft' COMMENT '状态，对应状态机', buyer_id BIGINT NOT NULL COMMENT '采购员ID', supplier_id BIGINT NOT NULL COMMENT '供应商ID', expected_date DATE COMMENT '期望到货日', total_amount DECIMAL(12,2) DEFAULT 0.00 COMMENT '总金额', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_status_created (status, created_at), INDEX idx_supplier (supplier_id) ) COMMENT='采购单主表'; CREATE TABLE purchase_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, sku_code VARCHAR(64) NOT NULL COMMENT '商品编码', quantity INT NOT NULL DEFAULT 0, unit_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, received_qty INT NOT NULL DEFAULT 0 COMMENT '实收数量', INDEX idx_order (order_id), INDEX idx_sku (sku_code) ) COMMENT='采购单明细表';

建表时我会重点检查三件事：状态字段的枚举值是否和状态机完全一致、明细表的received_qty是否支持部分收货、索引是否覆盖了最频繁的查询条件（按状态和时间筛选、按供应商筛选）。如果 PPT 里提到「支持部分收货」，但明细表只有一个总数量字段，那就是需求没落到位。

3.3 接口清单与流程节点的对齐检查

表建好之后，把状态机里的每个事件映射成一个接口，列成清单。比如submit对应POST /purchase/submit，approve对应POST /purchase/approve。清单里要标注每个接口的调用方（前端页面、定时任务、外部系统）和幂等要求。零售场景里收货接口经常被仓库的 PDA 重复调用，幂等必须做在服务端，用order_no + sku_code做唯一键去重。

这一步做完，拿着接口清单和状态机图再对一遍 PPT，如果发现某个流程节点找不到对应的接口或表字段，要么是 PPT 画了不需要系统做的事，要么是需求漏了。我一般会在这个环节揪出三到五个遗漏点，比如退货流程里的「质检结果」字段、促销流程里的「分摊金额」字段。

4. 避坑与排查：零售需求落地时最容易翻车的五个地方

4.1 现象：库存对不上，系统显示有货实际没货

原因：采购入库和销售出库用了两套库存表，或者入库时没扣减在途库存。零售 PPT 里经常只画「入库」一个框，但实际系统里在途、在库、锁定三种库存状态必须分开。 解决：建一张库存流水表，所有库存变动只通过流水记录，当前库存由流水汇总得出。入库时增加在库、减少在途，销售时增加锁定、减少在库。

4.2 现象：促销规则上线后，订单金额算错

原因：PPT 里的促销描述是「满100减20」，但没定义叠加规则和优先级。多个促销同时命中时，系统按什么顺序计算，是折上折还是取最优，需求里没写。 解决：在需求阶段就定义促销引擎的规则模型，每条促销带优先级和互斥组，计算时按优先级排序，互斥组内只取最优。测试用例必须覆盖两两叠加的场景。

4.3 现象：审批流卡住，单据一直挂在待审批

原因：状态机里定义了审批节点，但没定义审批人离职或请假时的代理规则。零售企业人员流动大，审批人一换，单据就死在那里。 解决：审批节点配置里增加代理人和超时自动升级规则，超时未审批自动转给上级。定时任务每小时扫一次超时待办。

4.4 现象：门店和电商订单号重复，对账对不上

原因：不同渠道各自生成单号，没有全局唯一约束。零售 PPT 里渠道是分开画的，但财务对账需要统一视角。 解决：单号生成规则里加渠道前缀，或者用全局发号器。数据库层面order_no加唯一索引，插入冲突时直接报错而不是静默覆盖。

4.5 现象：需求评审通过，开发说做不了

原因：需求条目里写了「根据历史销售数据智能推荐补货量」，但没定义数据来源、计算频率和兜底策略。这种模糊描述在零售 PPT 里特别常见。 解决：把智能推荐拆成可执行的规则，比如「取过去四周同星期几的平均销量，乘以安全系数1.2，向上取整」。数据来源、计算时机、异常兜底全部写进需求条目。

5. 用一份检查清单把 PPT 锁死成可开发的需求

最后一章说一个我用了三年的习惯：每次拿到零售业务流程 PPT，先花半小时填一份检查清单，填不完就不进开发。清单不长，但能挡住八成返工。

填完清单，我会挑三个最复杂的流程节点，手动画一遍数据流转：从用户点击到数据库落库，中间经过哪些服务、哪些表、哪些消息。画的过程中如果发现某个字段在两个服务里含义不一致，比如「数量」在采购服务里是含税数量、在库存服务里是不含税数量，那就必须在需求里统一口径，否则上线后一定出脏数据。

这个习惯帮我省过很多后悔药。有一次促销模块上线前，我在检查清单里发现「优惠分摊」字段在订单表和结算表里精度不一样，一个是两位小数一个是四位小数，差一分钱。就这一分钱，财务对账时差了十几万。后来统一用四位小数存储，展示时再截断。

需求文档不是写完就完了，它得能直接翻译成建表语句和接口定义。如果一份零售业务流程 PPT 经过这套流程处理之后，开发拿着需求条目就能写代码，测试拿着验收标准就能写用例，那才算真正落地。希望帮到你。

本文还有配套的精品资源，点击获取