先说个场景。很多中小规模的连锁门店、餐饮企业、以及做区域配送的贸易公司内部采购配送基本是靠Excel和微信群在跑的。采购员凭经验下单库管员收到货再补录司机沿着熟悉的路送到店签收单拍张照片发群里就算完事。表面看每个环节都有记录真到月底对账时仓库说账面不准门店说少送了财务说价格不对谁也拿不出完整证据链。我参与过的几个类似项目几乎都是从这个痛点开始的。蚂蚁采购配送系统这个名字最初听上去像个小工具但实际把它当成一个完整的软件设计问题来做时涉及的东西远比想象得多。这套系统的核心价值是把采购申请、审批、下单、收货、库存、配送、签收这一串动作从线下搬到线上并且让每一步都有据可查。它适合的对象很清晰还没有上大型ERP的中小企业或者ERP覆盖不到门店配送这一层的多门店运营团队。整篇文章我会从系统定位、主流程、数据模型、配送调度、权限设计和落地踩坑几个角度展开一套可以照着落地的设计方案。如果你正准备规划一个类似的采购配送系统这篇内容应该能帮你少走不少弯路。1. 为什么叫蚂蚁系统定位与设计主线1.1 把大系统拆成小任务蚂蚁这个名字其实反映了系统设计的核心理念不追求一个包打天下的庞大系统而是把采购配送这个大流程拆成一个个边界清晰的小任务——提交需求、审批、合并采购、供应商确认、生成配送单、司机配送、门店签收。每个任务足够简单任务之间通过明确的状态和事件衔接整体协作就能灵活起来。这个理念和很多团队一上来就设计大而全的思路正好相反。前几年我做过一个内部系统一开始就想着把采购、仓储、财务、CRM全部打通结果光需求梳理就做了三个月最后真正用起来的模块只有订单和审批。反而是后来重新按蚂蚁式拆法把每个闭环先独立跑起来再串联系统很快就稳定了。这个教训让我在后续做设计时第一件事永远是划边界而不是画大图。1.2 目标用户与典型业务场景从实际的落地场景看这套系统的目标用户主要有三类第一类是多门店的连锁零售或连锁餐饮每个门店要定期上报补货需求第二类是区域配送型贸易商从供应商拿货再分发到下游客户第三类是集团内部的多仓库调拨本质上也是采购配送的变体。以某连锁便利店客户为例它的典型流程是这样的每个门店每周一上午提交补货需求采购员在下午把同品类、同供应商的需求合并成采购单发给供应商供应商第二天确认交期系统自动生成配送计划司机按区域顺序送货门店收到货后清点签收系统根据签收结果更新库存和应付数据。这样一个完整周期只需要两到三天而不是原来的一周。1.3 设计边界哪些功能一定要做哪些先不做我建议这套系统V1版本把精力集中在五件事采购需求单、审批流、采购订单、配送任务、签收确认。库存可以做基础的进出库记录但先不做批次、保质期、序列号管理财务只保留单据流水不做应收应付总账数据分析先出几张固定报表不做自定义BI。边界划分的逻辑是每多做一块没有足够人力维护的功能主流程的稳定性就被稀释一分。尤其是配送调度这种看起来很有技术含量、实际依赖基础数据的模块如果数据不准算法再精致也没有用。因此宁可先把主链路做扎实再逐步向两侧扩展。2. 主流程与状态机从采购需求到配送签收的完整闭环2.1 采购需求单全流程的起点整套系统的起点是采购需求单PR。需求来源可以是门店的补货计划也可以是仓库的安全库存报警甚至可以由后台计划员手工创建。一张需求单至少应该包含需求方门店或仓库、期望到货日期、明细行商品、数量、单位、备注、优先级。优先级字段很重要决定了后续合并和配送的顺序我建议用普通、紧急、加急三档就够不要搞太多否则需求方不会认真选。需求单提交后进入审批环节。审批的粒度建议只到单级不拆到行否则审批人界面会非常碎。审批人可以设置多级但每一级是或签还是会签需要明确一般企业场景下或签就够了一人通过即可进入下一环节。2.2 采购订单需求汇总与供应商确认需求单审批通过后系统需要把它们按供应商和收货地址进行合并生成采购订单PO。合并的目的是减少供应商的交货次数也减少收货方的工作量。合并规则建议这样相同供应商、相同收货仓库或门店、期望到货日期落在同一个时间窗默认两天内的需求单可以合并超过车辆装载上限或不同紧急度的则拆单。供应商确认是很多项目容易忽略的环节。实质上采购订单在没有供应商确认之前都只是意向单只有供应商回复了数量、单价、交期订单才算真正生效。这里的关键是降低供应商的操作门槛不要要求对方登录后台简单生成一条带token的确认链接发过去打开后显示订单列表、可改数量和交期、点确认即可。2.3 状态机的定义与变更纪律状态机是这类系统最容易失控的地方。我见过很多项目把采购单和配送单的状态混在同一个字段里导致查询和统计非常混乱。建议把它拆成两段采购订单状态和配送任务状态。采购订单状态至少有草稿、待供应商确认、已确认、部分到货、已完成、已取消配送任务状态至少有待分配、待配送、配送中、已完成、异常。所有状态变更必须遵守一个纪律每次变更写一行状态流转记录记录操作人、操作时间、变更前后状态、原因备注。这样出了问题往回倒每一步都有据可查。状态流转记录表独立于业务表避免业务表膨胀。状态触发条件后续动作pending_review需求单提交通知审批人approved审批通过进入采购汇总合并order_sent采购单发送给供应商生成确认链接并通知供应商supplier_confirmed供应商确认可供货生成配送建议计划delivering司机确认开始配送通知门店预计到达时间completed门店确认签收扣减库存、生成应付草稿cancelled审核或业务取消记录取消原因不做业务联动2.4 签收确认与单据闭环最后一个关键动作是签收。司机把货送到门店后门店人员清点数量在系统里对每个明细行确认收货数量。允许部分签收但不允许超量签收超出的部分需要走退货或者补单流程。签收后配送任务关闭同时触发库存变动。如果供应商在订单里填了采购单价还可以同时生成一笔应付草稿供财务后续审核。签收环节最怕的是纸面签收系统里没录。如果司机和门店习惯了线下操作系统数据就会失真。我的做法是强制把司机确认送达和门店确认签收拆成两个动作司机不点送达任务就不允许关闭门店不在系统里签收库存就永远不会增加。这个强制闭环前期会让人不适应但坚持一个月后数据质量会明显提升。3. 数据模型设计商品、供应商、订单、库存四条主线3.1 核心实体与关系这套系统的数据模型可以归纳成四条主线商品线、供应线、单据线、库存线。商品线包括商品主数据SKU、商品分类、计量单位供应线包括供应商、供应商报价、采购员和供应商的对应关系单据线包括采购需求单、采购订单、配送任务、签收记录库存线包括仓库、库存流水、实时库存快照。关键关系上需求单和订单是聚合关系一张订单聚合多张需求单订单与配送任务是一对多一个配送任务可以包含多张订单配送任务与签收记录是一对一但签收记录内部包含多个明细行。如果后续要引入批号管理只需要在SKU和库存流水之间增加一个批次维度不会改动主干结构。3.2 单据表结构设计要点单据表的通用设计是主表 明细表 流转记录表。主表存单据头字段例如单据编号、类型、状态、需求方、供应商、期望日期、金额合计、备注明细表存每一行商品的编码、名称、数量、单价、已收数量、备注流转记录表存状态变更历史。单据编号生成规则建议用单据类型前缀 日期 当日流水号例如PR-20250617-001、PO-20250617-008。不要用数据库自增ID直接展示给用户自增ID只适合内部关联展示时的编号必须可读、可辨识否则客服和业务方沟通成本会很高。3.3 库存模型可用、占用、在途三态设计库存设计方面我强烈建议采用三态模型实物库存、占用库存、在途库存。可用库存 实物库存 - 占用库存 在途库存在途可以按供应商发货方向计算。占用发生在采购订单确认后把将要到货的商品数量预占在途发生在配送任务发出后商品离开总仓但还没到达门店实物库存每次出入库时更新。ALTER TABLE sku_stock ADD COLUMN on_hand_qty INT COMMENT 实物库存, ADD COLUMN occupied_qty INT COMMENT 占用库存, ADD COLUMN transit_qty INT COMMENT 在途库存, ADD COLUMN version INT COMMENT 乐观锁版本号;这套模型不复杂但能解决采购配送系统里最典型的两类问题一个仓库会不会超卖一个订单能不能承诺给客户。具体实现时库存流水表每次变更记录变动类型入库、出库、占用、释放、调整、签收实时库存表只保留每个SKU在每个仓库的三态数值更新时用事务保证一致。3.4 并发与幂等设计签收动作涉及多张表的同时更新配送任务状态、订单明细已收数量、库存流水、库存快照。务必要放在同一个数据库事务里执行并且加上乐观锁例如在库存快照上设置版本号更新时带上版本号条件更新行数为0则说明发生并发冲突提示重试。防重复提交同样重要。网络不好时用户可能点了两次确认签收第二次操作如果直接更新库存就会造成数据错误。做法是生成一个业务幂等键每次签到尝试把幂等键写入去重表重复键直接返回成功不再执行业务逻辑。这个细节很小实际线上救过我好几次。4. 配送调度设计任务分组、路线排序与人工干预4.1 配送任务从哪里来配送任务生成的时机有两个供应商确认采购订单后自动生成或者调度员手动从已确认订单中选择生成。自动生成的优点是省人力缺点是在订单量波动大的时候容易生成大量零散任务。所以我在多个项目里采用自动建议、人工确认的折中方案系统生成建议的配送分组调度员可以调整合并后再确认确认后任务才正式生效。生成配送任务的输入很简单一批已确认且待配送的采购订单、车队车辆列表、每辆车最大订单数或最大装载体积、收货方所在区域。输出是一组配送任务每个任务绑定一辆车、一个司机、多条订单以及按顺序排好的停靠点。4.2 分组与排序先用简单规则再考虑优化很多团队一听到配送调度马上想上车辆路径规划VRP算法。但实际落地中大部分中小企业的订单量一天不超过几十单区域也就三五个这时候复杂的路径优化算法带来的收益远小于维护成本。我的建议是先实现两段式规则先按收货方区域编码分组再在组内按期望送达时间窗口排序。def build_delivery_plans(orders, fleet): # 按区域分组 groups {} for order in orders: zone order.receiver_zone groups.setdefault(zone, []).append(order) plans [] for zone, zone_orders in groups.items(): # 组内按时间窗口排序早的在前 zone_orders.sort(keylambda o: o.time_window_start) # 每辆车按容量切分 for i in range(0, len(zone_orders), fleet.vehicle_capacity): vehicle_orders zone_orders[i:i fleet.vehicle_capacity] plans.append(DeliveryPlan(zonezone, ordersvehicle_orders)) return plans这个逻辑的好处是稳定、可解释、易排错。司机的配送顺序由系统给出但实际路线仍然允许司机结合路况微调。等到订单量真的上来了再引入距离矩阵和路径优化也不迟此时数据结构已经支持不需要推翻重来。4.3 异常场景改单、退单、延迟、拒收配送环节的异常处理远比正常流程重要。实际运行中常见的异常至少有四类订单改期、订单部分取消、配送延迟、门店拒收。订单改期和部分取消我会在配送任务处于待配送状态时允许操作一旦司机点了开始配送订单内容就不允许再改只能走退货流程避免司机按旧清单送完才发现不对。配送延迟需要司机在系统里提交原因和预计新到达时间系统按新时间调整后续停靠点顺序并通知受影响门店。拒收则要记录拒收数量和原因被拒收的商品回到总仓或就近仓库生成一条拒收回库库存流水。4.4 保留人工调整入口无论自动调度规则多完善都要给调度员留一个人工调整入口。原因是线下运力存在太多系统不知道的信息比如某位司机对某个片区特别熟、某辆车实际装载有限制、某个客户和司机之间有约定俗成的送货时间。我的建议是系统提供自定义配送任务功能调度员可以把任意已确认的订单移进或移出一个配送任务也可以调整停靠顺序所有人工调整都会在任务里留下调整记录。这样既能享受自动化的效率也不会被自动化绑架。5. 权限模型与审批流设计多角色协作的安全底线5.1 角色划分与数据隔离采购配送系统涉及的角色通常有六类系统管理员、采购员、采购经理、门店店长、仓库管理员、司机。如果是跨公司协作还要加上供应商外部角色。权限设计的第一原则是数据隔离。门店店长只能看到自己门店的需求单、订单和签收记录不能看到其他门店司机只能看到自己当前配送任务关联的订单供应商外部账号只能看到发给自己的采购订单并且没有修改商品主数据的权限。这个隔离在做权限判断时必须在每个接口里显式校验不能只靠前端隐藏菜单。角色可访问数据范围关键操作权限系统管理员全部数据用户管理、参数配置、日志查询采购员全部采购单据创建需求单、合并订单、发送供应商采购经理全部采购单据审批、驳回、价格调整门店店长仅本门店数据提交补货需求、签收确认、查询本店单据仓库管理员仓库及配送数据收货入库、库存调整、盘点司机仅本人配送任务开始配送、送达确认、异常上报供应商仅发给本公司的订单确认订单、修改交期和报价5.2 审批流固定流程还是可配置流程审批流程有两种设计路线固定流程和可配置流程。固定流程简单可靠改流程要发版可配置流程灵活但实现成本高容易把配置界面做得很复杂。对V1版本我建议做成固定 少量配置项审批节点数量固定为1到2级每个节点可以配置审批人角色审批动作只有通过和驳回两种。不要一开始就支持会签、加签、转签、条件分支这些花哨功能。真实场景里90%的审批都是单人看一眼就通过剩下10%的驳回也只需要一句备注。与其把精力花在审批引擎上不如把审批记录做得完整一些让每一次通过和驳回都有据可查。5.3 审计日志与数据安全业务系统的审计日志和互联网应用的操作日志不一样它更关注谁在什么时间对哪张单据做了什么事情。我通常会把关键操作日志单独建表记录操作人ID、操作人角色、操作类型、单据编号、变更详情JSON、IP、操作时间。对价格修改、审批通过、签收数量修改这些敏感操作必查必录。数据安全方面供应商密码不能明文存储外部链接需要带短期有效的token内部接口统一走权限校验中间件。虽然蚂蚁采购配送系统不是金融级系统但权限校验和审计留痕这两件事做得越早后续扩展越省力。6. 落地中的坑与取舍从设计文档到可运行系统6.1 最大的坑是基础数据不准做这类系统最容易翻车的不是代码而是基础数据。很多企业连一份准确的商品档案都没有同一个商品在Excel里叫农夫水在纸质单上叫矿泉水550ml系统一上线就会因为主数据不统一导致大量对不上的单子。解决办法是在项目一开始就做一次商品主数据清洗统一编码、统一名称、统一单位盘点一次现状库存作为期初数据。这个过程虽然枯燥但它直接决定了系统上线后的数据可信度。我在项目启动会上一般会用一句话强调系统只是把线下流程结构化它不会自动修正错误的输入。6.2 供应商协同的推进方式供应商愿意配合系统是这套系统跑起来的前提。但很多供应商连账号都不想要更别说安装App。比较顺利的做法是只给供应商一个移动端网页链接收到订单短信后点开链接看到订单明细输入可供货数量、单价、交期点确认整个过程一分钟搞定。这样供应商的负担最小配合率最高问题是订单变更时沟通要及时否则供应商按旧信息发货。6.3 技术选型与开发顺序建议技术栈不写死但有几个建议领域模型和状态机用后端强控制不要在多个前端页面里各写一套状态判断数据库至少选支持事务的关系型数据库如果团队人数少优先用单体应用加定时任务不要上来就拆微服务。开发顺序上我的建议是先做需求单、审批、采购订单这条采购闭环接着做配送任务和签收闭环库存最后接。第一版可以允许库存数据不实时但单据流必须完整。等到线上跑通一个月数据质量稳定了再开库存预警、周转分析这些增强功能。这样做的好处是每次发版都有用户可感知的完整成果团队和业务方都更有信心。6.4 从设计文档到原型的几点提醒最后补充几个设计评审时容易忽略的点。单据关联关系在界面上要能互相穿透从需求单能跳到它生成的订单从订单能跳到配送任务从配送任务能跳到签收记录这种穿透查询在排查问题时价值极高。所有金额字段在单据未完成前都允许修正但修正必须留痕。通知渠道优先级建议是短信加站内信邮件在中小企业里经常被忽略不要作为主要通知渠道。如果让我说做这套系统最深的体会我会说软件设计里最值钱的往往不是某个高深的算法而是对业务边界的判断和对异常流程的预设。蚂蚁式设计的精髓就在于每个任务都足够小每个状态都足够清晰每个动作都留有痕迹。你不需要一开始就做一个完美的系统先把采购配送这条主链路跑稳再一步步加厚它。这条路径我在好几个项目里验证过走得很踏实。