生鲜与集采系统的单据设计常陷入'一单到底'的困局，导致前端臃肿与后端混乱。本文揭示供货单与送货单分层解耦的黄金法则：前者锁定商家发货计划，后者专注物流执行路径，通过触发式生成、数据共享、状态联动的精密耦合机制，实现B端履约系统的高效运转与灵活迭代。这套架构正在重塑仓储物流领域的产品设计范式。
在生鲜、农产品、集采类履约系统里，供货单与送货单常常被混为一谈：一张单从下单走到装车，前端越做越臃肿、后端状态互相污染、业务变更寸步难行。
而实际系统设计中，我们明确把它拆成两张完全独立的单据，但又通过严谨的交叉耦合机制保持数据一致、流程闭环。
一句话结论：
供货单管“商家要发什么”，送货单管“货要送到哪”；二者强关联、不混用、可独立演进，是B端履约单据的健康架构。
定位：商家发货的唯一业务依据
核心维度：商家维度 + 日期 + SKU + 发货地 + 可发货件数
承载：订单、SKU、发货地、可发货数量、结算数据
生命周期：商家发货→ 货到平台【商家对平台履约】
操作主体：商家、买手
定位：发货后的执行载体
核心维度：在供货单基础上 + 客户收货地点
承载：批次号、状态流转、司机绑定、品检结果、打印、装车、撤销
生命周期：货到平台 → 已送达【平台对用户履约】
操作主体：品控、司机
底线：商家发货数据归供货单，执行路由归送货单。
两张单完全独立，但必须精准耦合，否则流程断裂、数据不一致。
价值：业务源头不变，执行灵活拆分。
价值：执行结果反向修正业务库存，保证账实一致。
送货单状态流水线：
商家发货 → 待品检 → 待打印 → 待装车 → 已装车 → 运送中 → 已送达
每一步状态变更，都会同步更新供货单的发货进度与履约状态。
价值：前端只展示业务状态，后端执行状态不污染业务视图。
1.流程分层：从订单到履约的完整链路
从用户下单开始，整个履约流程被清晰拆为业务计划层与物流执行层：
订单下单 → 待发货：平台按商家维度对订单进行聚合，将分散的用户订单收拢为商家视角的待发货任务，为后续供货单生成奠定基础。
待发货 → 商家发货：商家在供货单维度完成履约计划确认，只聚焦 “要发什么、发多少”，不涉及终端用户的配送细节。
商家发货 → 送货单生成：系统自动将供货单的业务数据同步，并扩展出用户收货地址等配送信息，生成面向物流执行的送货单。
从图中可以直观看到两张单据的信息边界：
最下方的「供货单 * 送货单耦合」模块，清晰展示了两张单据的交叉关联：
很多产品踩坑，就是把计划和执行塞在一张单里：
而供货单+送货单的设计，带来三大收益：
如果你正在做仓储、履约、生鲜、集采系统，遇到单据混乱、状态爆炸、权限不清，不妨先拆一层：把业务单和执行单分开，你的迭代速度、系统稳定性、用户体验，都会立刻上一个台阶。
本文由 @Totoro畅 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。