单据状态设计不能只靠“单据头状态”打天下。当业务涉及分批处理、各行结果不一致或需追踪明细生命周期时（如采购订单部分被拒、出库单部分缺货），必须引入“单据行状态”。本文通过SRM与WMS真实场景，详解单据头与行状态的分工逻辑、聚合规则、合理粒度及常见陷阱，并强调：状态不在多而在准，核心流转节点由状态表达，过程细节应由日志或关联单据承载。

在我的产品经理交流群里，经常会看到有朋友问供应链系统的单据状态设计问题。

例如，他们会说：”我设计了一个采购订单，定义了待审核、已审核、收货中、已完成这些状态，但总觉得有些细节情况表达不清楚。比如供应商只能供其中3个SKU，另外2个供不了，这时候订单状态应该是什么？部分确认？部分收货？怎么定义都觉得不够准确。”

我发现这些朋友遇到的问题，本质上是因为他们一直在单据头上想办法，希望通过增加更多的状态枚举值，把所有业务场景都考虑齐全。

但实际上，他们遇到的这些场景，只靠单据头状态是解决不了的，需要引入”单据行状态”才行。

说白了，就是很多朋友可能都没见过、没体验过”单据头状态+单据行状态”这种设计，或者压根不知道单据的明细行上也可以加状态，对这块相对陌生，没有画面感。

我最近刚好在做类似的项目，接触过一些相关的案例，也踩过一些坑。所以想把单据头状态和单据行状态这两种设计的经验总结出来，分享给那些没怎么做过、或者对这块不太熟悉的朋友。

先搞清楚概念：什么是单据头状态和单据行状态？

在展开讲之前，我先把这两个概念说清楚，因为很多产品新人容易搞混。

单据头状态，就是整张单据的状态，一张单一个状态。比如一张采购订单，它的状态可能是”待审核””已审核””收货中””已完成”，这个状态代表的是整单的流转情况。

单据行状态，就是单据里每个商品明细行的状态，一张单可能有多行，每行都有自己的状态。比如一张采购订单有5个SKU，每个SKU都是一行，每行的状态可能是”待确认””已确认””部分收货””已完成”，这个状态代表的是每个商品的处理情况。

通过这个对比应该能理解了：单据头状态是宏观的，单据行状态是微观的。绝大多数场景下，单据头状态就够了；但有些场景下，必须要有单据行状态才能把业务说清楚。

什么时候单据头状态不够用？

下面用2个真实的业务场景来说明，什么时候必须要有单据行状态。

场景1：SRM的采购订单 – 供应商分批响应

在做SRM系统时，经常会遇到类似的典型场景。你向供应商A发了一张采购订单，包含5个SKU：

1. SKU-A：1000件，单价10元
2. SKU-B：500件，单价8元
3. SKU-C：800件，单价12元
4. SKU-D：300件，单价15元
5. SKU-E：200件，单价20元

按照正常流程，供应商应该全部确认，然后按约定的交期发货。但实际业务中，经常会遇到这种情况：

供应商A在SRM系统里响应说：”SKU-A、B、C我能供，预计7天交货。但SKU-D和E我这边缺货，供不了，要么改交期，要么就只能找别的供应商。”

这时候问题来了：这张采购订单的状态应该是什么？

如果只有单据头状态，你可能会设置一个”部分确认”的状态。但这个状态太笼统了，采购员看到”部分确认”，还得点进去看明细，才知道具体是哪些SKU确认了、哪些没确认。而且后续SKU-D和E要转给供应商B，系统怎么知道这两行还需要继续处理？

如果有单据行状态，就清晰多了。

采购员一眼就能看出来：前3行已经有供应商确认了，后2行被供应商拒绝了，还需要继续找其他供应商。系统也可以根据”已拒绝”状态，自动提醒采购员及时跟进这种特殊场景。

那么单据头状态怎么设置呢？

单据头状态应该从单据行状态聚合而来。具体规则是：

• 部分行”已确认”，部分行”待确认” → 单据头状态 = “部分确认”
• 所有行都是”已确认” → 单据头状态 = “已确认”
• 开始收货后，部分行”部分收货” → 单据头状态 = “收货中”
• 所有行都是”已完成” → 单据头状态 = “已完成”

这样设计的好处是：单据头状态有明确的推导逻辑，系统可以自动更新，不需要人工维护。

为什么这个场景必须有单据行状态？

因为采购订单的业务特点就是”供应商可能分批响应、分批交付”。如果没有单据行状态，采购员根本没法跟踪每个SKU的具体情况，也没法知道哪些SKU还需要继续处理。

场景2：WMS的出库单 – 分批拣货、分批出库

仓库收到一张配货单，要给门店发10个SKU。拣货员开始拣货，理想情况下是10个SKU都能拣到，然后一起打包出库。但实际业务中，经常会出现这种情况：

拣货员拣了一圈，结果：

• 前7个SKU都拣到了，数量也对
• 第8个SKU系统里显示有50件库存，但货架上只找到30件，少了20件
• 第9、10个SKU系统里有库存，但实物完全找不到（可能是货物丢失了，或者货物放错位置了）

仓库主管看了看情况，说：”先把拣到的7个SKU发走，第8个SKU先发30件，剩下20件明天盘点完再说。第9、10个SKU今天肯定发不出去了，让业务部门重新安排吧。”

这时候如果只有单据头状态，你根本没法表达清楚这个复杂的情况。单据头状态应该是什么？”部分完成”？”进行中”？”异常”？不管设置成什么，业务部门和仓库人员都看不出来具体是什么情况。

如果有单据行状态，就清晰多了。

这样一看就清楚了：

• 前7个SKU已经正常发出去了
• 第8个SKU部分发出去了，还差20件
• 第9、10个SKU完全没发出去，需要重新处理

业务部门可以根据这个明细，决定是等补齐再发，还是先部分发货；财务部门也可以根据实际出库情况开票和对账。

为什么这个场景必须有单据行状态？

因为WMS的业务特点就是”可能分批拣货、可能部分缺货、可能实物对不上”。如果没有单据行状态，仓库人员和业务部门根本没法知道每个SKU的具体处理情况，也没法决定后续怎么处理。

小结：什么时候必须要有单据行状态？

通过这2个场景可以看到，必须要有单据行状态的情况主要有3种：

1. 业务会分批处理

• 供应商分批响应、分批发货
• 仓库分批拣货、分批出库
• 财务分批开票、分批结算

2. 每行的处理结果可能不同

• 有些行成功、有些行失败
• 有些行正常、有些行缺货
• 有些行确认了、有些行被拒绝了

3. 需要跟踪每行的生命周期

• 从待处理 → 处理中 → 已完成
• 每一步都要能看到具体是哪些行在哪个状态

如果你的业务场景满足以上任何一种情况，那就必须要有单据行状态。如果都不满足，单据头状态就够了。

单据行状态怎么设计？

讲完了”什么时候需要”，下面讲讲”怎么设计”。这部分我会把我踩过的坑和总结的经验都分享出来。

1. 单据头状态和单据行状态的关系

这是很多产品经理容易搞混的地方。到底是单据头状态决定单据行状态，还是单据行状态决定单据头状态？

我推荐的设计思路是：单据头状态由单据行状态聚合而来。

具体的聚合规则是：

所有行都是同一个状态 → 单据头状态就是这个状态

• 例如：所有行都是”待处理” → 单据头状态 = “待处理”
• 例如：所有行都是”已完成” → 单据头状态 = “已完成”

部分行是状态A，部分行是状态B → 单据头状态就是”中间状态”

• 例如：部分行”已出库”，部分行”待处理” → 单据头状态 = “部分出库”
• 例如：部分行”已确认”，部分行”待确认” → 单据头状态 = “部分确认”

这种设计的好处是：

• 单据头状态有明确的推导逻辑：不会出现单据头和单据行状态不一致的情况
• 系统可以自动更新单据头状态：不需要人工维护，减少出错概率
• 业务容易理解：单据头状态就是单据行状态的汇总，逻辑清晰

2. 单据行状态的粒度设计

这是另一个很重要的问题：单据行状态到底应该设计多少个？

我的核心原则是：根据业务需要设计，不要为了细而细。

我见过一个过度设计的案例：某个采购订单系统，产品经理把采购订单行状态设计了15个：

待提交 → 待审核 → 审核中 → 已审核 → 待确认 → 供应商确认中 → 
已确认 → 待发货 → 备货中 → 已发货 → 运输中 → 待收货 → 
收货中 → 质检中 → 已完成

这样设计的问题是：

状态太多，业务根本分不清：采购员看到这么多状态，根本不知道该关注哪个，”审核中”和”已审核”有什么区别？”待发货”和”备货中”又有什么差别？

维护成本高：每个环节都要更新状态，但很多状态的转换逻辑根本没人维护，导致数据不准确

系统复杂度高：状态机的转换规则非常复杂，后续维护很困难

实际上，采购订单行状态只需要6-7个就够了：

待确认 → 已确认 → 已拒绝
           ↓
          部分收货 → 已完成 → 已关闭

为什么这样设计就够了？

• “待审核””审核中””已审核” → 这些是单据头的审核流程状态，不需要在单据行上体现
• “待发货””备货中””已发货””运输中” → 这些由供应商的发货单来体现，不需要在采购订单行状态里反映
• “收货中””质检中” → 这些是WMS和质检系统的状态，采购订单行只需要知道”部分收货”还是”已完成”就够了

关键是要分清楚：哪些状态是这张单据必须承载的，哪些状态应该由其他单据或日志来承载。

如果你确实需要追踪更细的过程，比如”什么时候发货的””谁质检的”，我的建议是：用操作日志或关联单据来记录，而不是增加单据行状态。

比如：

• 供应商发货时，创建一张发货单，关联采购订单，这样就能看到发货时间、物流单号等信息
• 质检完成时，记录一条质检记录，关联采购订单行，这样就能看到质检人、质检时间、质检结果

这样既能追踪到详细的操作过程，又不会让单据行状态过多。单据行状态只关注核心流转节点，其他细节由操作日志和关联单据来补充。

3. 单据行状态变更的触发时机

什么时候应该更新单据行状态？常见的触发时机有3种：

1. 下游系统回传结果时 – WMS回传出库结果、供应商在SRM系统里响应、物流系统回传签收信息等。这样数据最准确，时效性也最好。

2. 人工操作时 – 采购员手动确认、仓库主管手动取消、财务手动开票等。人工操作要留痕，记录操作人、操作时间、操作原因。

3. 定时任务扫描 – 超时未处理自动取消、批次到期自动冻结、承诺交期已到自动提醒等。定时任务要设置合理的时间间隔。

最重要的一点：单据行状态的每次变更都要记录到状态流转表或操作日志表，这样可以追溯状态变更历史，出问题时能查到是谁、什么时候、为什么改的。

4. 另一种设计思路：单据头多状态字段

讲完单据行状态，再补充一种常见的设计思路：在单据头上设计多个状态字段。这种设计思路，也可以很高效率地接近日常的业务问题，但是如果要三言两语把这一块拆解清楚也需要不少的篇幅，我决定在后续新开一篇文章再对它做一个拆解。

传统设计可能只有一个”单据状态”字段，但有时候会把它拆分成多个状态字段。比如采购订单，可以拆成：审核状态、确认状态、入库状态、对账状态、开票状态。这样设计的好处是每个维度独立表达，采购员关注确认状态，财务关注对账状态和开票状态，各看各的，查询也方便。

什么时候用单据头多状态字段？什么时候用单据行状态？

简单来说：

• 单据头多状态字段 → 适合整单维度的多个流程环节（如审核、对账、开票）
• 单据行状态 → 适合每个明细行的处理情况不同（如供应商分批确认、仓库分批拣货）

两者不是非此即彼的关系，可以结合使用。一个典型的设计是：单据头用多状态字段（审核状态、对账状态、开票状态），单据行也有行状态（待确认、已确认、已拒绝、部分收货、已完成）。

常见的坑和注意事项

设计单据行状态时，有一些坑很容易踩。我把最常见的3个坑总结出来：

坑1：单据行状态过多，维护成本高

我见过一个系统，采购订单行状态设计了20个，从”待确认”到”已入库”每个小环节都有状态。结果业务部门根本分不清这些状态的区别，开发团队维护起来也非常痛苦，状态转换规则极其复杂，经常出bug。

建议： 核心状态控制在5-8个以内，如果需要更细的追踪，用操作日志或状态流转表来记录，而不是增加状态数量。

坑2：单据头状态和单据行状态不一致

某系统的销售订单，单据头状态是”已完成”，但点进去看明细，发现有些行还是”处理中”。业务部门不知道该信哪个，对账时也搞不清楚到底有没有完成。

建议： 建立明确的聚合规则，单据头状态要能从单据行状态推导出来。在更新单据头状态时，要校验单据行状态是否匹配。

坑3：历史数据没有单据行状态，补录很痛苦

某公司一开始只设计了单据头状态，系统上线1年后，业务部门提出需要单据行状态。产品经理加了字段，但历史数据全是空的。这时候就很尴尬：不补录历史数据，业务部门没法查询统计；要补录历史数据，但根本没有记录当时每行的状态。

建议： 即使暂时不用单据行状态，也要预留字段。在单据创建时就给单据行状态设置一个默认值（如”待处理”），单据完成后自动更新为”已完成”。这样将来如果要启用单据行状态功能，历史数据至少有个初始状态。

写在最后

状态设计没有标准答案，需要结合具体的业务场景来判断。但掌握了基本思路和原则，相信你能设计出既实用又稳健的状态管理方案。

单据行状态虽然用得不多，但一旦需要就是刚需，回避不了。如果你之前的工作中没怎么接触这一块的内容，也没想到过有这种设计思路和方法，那么这篇文章你可以仔细研究一下，把一些疑问和拓展知识丢给AI，让它跟你进行更深入的交流和沟通。最后再把相关的内容沉淀、总结到自己的知识库中，后续工作中遇到需要采用这种设计方案的时候，就可以直接掏出来用了。