生鲜供应链的批次品控场景正经历从『单SKU供货』到『多SKU批次发货』的架构升级。本文深度拆解如何重构供货单与送货单的层级关系，通过状态驱动设计避免无效数据、提升系统性能，并优化页面交互以适应新的业务流程。

在生鲜供应链的批次品控场景中，我们遇到了一个典型的从「单SKU供货」到「多SKU批次发货」的架构升级难题：旧模式下一张供货单仅对应一个SKU，而新模式下一个批次号（送货单）会聚合多个SKU的任意件数，这直接导致了原有状态逻辑、数据结构和页面交互的全面失效。

本文将结合实际业务场景，完整拆解批次发货模式下供货单与送货单的关系重构，以及如何通过状态设计避免大量无效数据、提升系统性能。

一、业务背景：从「单SKU供货」到「多SKU批次发货」

1. 旧模式（1:1 关系）

结构：一张供货单 ↔ 一个SKU（货号）

流程：供应商按SKU分别创建供货单，每个SKU独立走品控、发货、结算

痛点：

• 多SKU订单需要创建多张供货单，操作繁琐
• 品控、对账效率低，无法按批次管理
• 数据碎片化，不利于库存和效期追溯

2. 新模式（N:M 关系）

结构：一个批次号（送货单） ↔ 多个SKU（每个SKU可包含任意件数）

流程：供应商将多个SKU合并到一个批次中发货，批次作为最小品控和管理单元

核心变化：

• 原供货单被拆分，重新聚合到同一个送货单（批次号）下
• 品控从「单SKU维度」升级为「批次内SKU维度」
• 状态逻辑需要从「单SKU」适配到「多SKU混合结果」

二、核心关系重构：供货单 vs 送货单（批次号）

1. 新的层级关系

送货单（批次号）= 供货单A（SKU1，10件）+供货单B（SKU2，20件）+供货单C（SKU3，15件）+…+ 供货单N（SKUN，M件）

送货单（批次号）：是本次发货的聚合容器，包含多个供货单

供货单：是每个SKU的履约单元，记录该SKU的发货数量、品控结果

关系：1个送货单 ↔ N个供货单，N≥1

2. 状态流转的核心原则

1. 品控发生在「批次内SKU维度」：同一个批次下，不同SKU可以有不同的品控结果（通过/驳回）
2. 供货单状态由其对应SKU的品控结果决定
3. 送货单（批次）状态由下属所有供货单的状态汇总计算
4. 不删单、不重建批次：仅用状态标记，避免大量取消单和重复造数

三、状态设计：从单SKU到多SKU的适配

1. 供货单状态（SKU维度）

2. 送货单（批次）状态（聚合维度）

四、流程优化：避免无效数据，提升系统性能

1. 原流程痛点

• 旧模式下，部分SKU被驳回时，直接删除原供货单并重建，导致大量「已取消」无效订单
• 数据库频繁执行DELETE和INSERT操作，锁表、阻塞写入，性能急剧下降
• 数据追溯困难，历史记录丢失，不利于审计和问题排查

2. 优化后流程（状态驱动）

3. 关键优化点

• 不删原单，只改状态：驳回/部分通过的供货单仅修改状态，不物理删除，保留完整历史
• 补发生成新批次：被驳回的SKU发起补发时，生成**全新送货单（批次号）**和新供货单，不沿用原批次
• 双向关联追溯：新批次与原批次、原供货单双向绑定，方便问题排查和审计
• 避免无效取消单：不再标记「已取消」状态，用「已取消」和「部分发货」精准表达业务含义

五、页面交互优化：贴合新流程的用户体验

1. 列表页状态展示

• 送货单（批次）：显示「已完成/部分完成/已取消」状态标签
• 供货单（SKU）：在批次详情页展示「已发货/部分发货/已取消」状态
• 驳回信息：仅在被驳回/部分通过的供货单下展示驳回原因和数量

2. 核心交互

• 再次发货：仅对「已取消」的供货单开放，点击后生成新批次和新供货单
• 部分通过处理：对「部分发货」的供货单，可单独对驳回部分发起补发
• 数据追溯：点击「查看补发记录」可跳转至关联的新批次，链路清晰

六、方案价值

1. 业务价值

• 支持多SKU批次发货，提升供应商和仓管操作效率
• 状态逻辑清晰，符合生鲜品控的真实业务场景
• 全链路可追溯，满足财务对账、审计要求

2. 技术价值

• 消除取消操作和取消状态的单据，避免数据库锁表和性能阻塞
• 减少无效订单数量，控制数据增长速度
• 状态驱动设计，扩展性强，可轻松支持「部分驳回」「多次补发」等复杂场景

七、总结

从「单SKU供货」到「多SKU批次发货」的升级，本质是从「细粒度履约」到「聚合管理」的架构演进。核心挑战在于如何在不破坏业务闭环的前提下，重构供货单与送货单的状态关系，同时避免数据冗余和性能问题。

我们的解决方案是：

• 明确层级：送货单（批次）是聚合容器，供货单是SKU履约单元
• 状态驱动：用「已发货/部分发货/已取消」描述供货单，用「已完成/部分完成/已取消」描述整个由供货单拼接的批次
• 性能优先：不删单、不重建批次，补发生成新批次，杜绝垃圾数据

对于B端产品经理而言，这类从业务模式升级到数据结构重构的问题，最能体现专业度——不仅要满足功能需求，更要考虑系统的长期稳定性和可维护性。