3. 主数据发布生命周期

主数据不是“建完就完”的静态档案。一条物料主数据从需求提出到最终失效，会经历多个状态迁移，每一次迁移都意味着数据内容、可用范围或下游系统行为的改变。如果只把发布理解为“点一下发布按钮”，就会出现下游系统拿到半成品数据、变更未同步、失效数据仍被采购引用等问题。本节把主数据发布拆成一条可追踪的状态机，并明确每个发布节点的责任归属。

一、状态机：五个核心状态与迁移条件

以物料主数据为例，其生命周期可抽象为五个稳定状态：草稿（Draft）、待审核（Pending Approval）、已生效（Active）、变更中（Under Change）、已失效（Obsolete）。状态之间不是任意跳转，而是由明确的业务事件触发。

• 草稿 → 待审核：创建人完成必填字段（物料编码、名称、基本计量单位、物料组、采购类型）后提交。系统校验编码唯一性、计量单位是否在允许值域内，校验通过才允许提交。
• 待审核 → 已生效：审核人确认数据完整、分类正确、与现有物料不重复后批准。此时系统生成正式版本号（如 V1.0），并触发首次发布。
• 待审核 → 草稿：审核驳回，附驳回原因（如“物料组与采购类型不匹配”），创建人修改后重新提交。
• 已生效 → 变更中：任何对关键字段（计量单位、物料组、采购类型、税分类）的修改，都必须先进入变更中状态，不能直接覆盖生效版本。
• 变更中 → 已生效：变更审核通过后生成新版本（如 V1.1），旧版本归档但保留可追溯。
• 已生效 → 已失效：物料停用、被替代或合并时，由数据管理员发起失效，系统检查是否存在未清采购订单、未清库存或未关闭工单，确认无业务占用后才允许失效。

这里有一个关键设计原则：生效版本对外可见，变更中版本仅对维护和审核角色可见。下游系统读取的永远是“已生效”版本，避免半成品数据污染采购、生产和财务。

二、三个发布节点：不是一次，而是三次

很多团队把“发布”等同于“首次生效”，这是不完整的。完整生命周期中至少有三个发布节点，每个节点的下游影响不同。

节点一：生效发布。物料首次审核通过后，系统向 ERP、MES、WMS、SRM 等下游系统推送完整主数据记录。推送内容包含物料编码、名称、计量单位、物料组、采购类型、税分类等。下游系统收到后建立本地映射，此时物料才真正可被采购申请、生产订单和库存事务引用。

节点二：变更发布。当计量单位、物料组等关键字段发生变更时，不能只改主数据系统。例如某物料基本计量单位从“个”改为“箱”，若下游采购订单仍按“个”计价，会造成数量与金额错位。变更发布必须携带变更前后对比、生效时间戳和影响范围说明，下游系统按增量方式更新。

节点三：失效发布。物料停用后，主数据系统向所有下游系统发送失效通知。下游系统收到后应将该物料标记为不可用于新单据，但历史单据仍可查询。失效发布的关键是先检查业务占用，再发布，否则会出现采购订单引用已失效物料的情况。

三、责任矩阵：谁在哪个状态做什么

状态机只有配上责任矩阵才能落地。下表以物料主数据为例，明确每个状态下的责任角色和关键动作。角色名称可根据企业实际调整，但职责分离原则不变：创建人不能审核自己创建的数据，审核人不能修改数据内容。

状态	责任角色	关键动作	输出/判断依据
草稿	数据创建人（业务部门）	填写必填字段、上传附件、提交审核	编码唯一性校验通过、必填字段完整
待审核	数据审核人（主数据专员）	核对分类、计量单位、采购类型；批准或驳回	与现有物料不重复、分类符合规范
已生效	数据管理员	触发首次发布、监控下游同步回执	下游系统返回成功回执
变更中	数据创建人 + 审核人	提交变更申请、审核变更影响、批准新版本	变更前后对比清晰、影响范围已评估
已失效	数据管理员 + 业务负责人	检查未清业务、发起失效、发布失效通知	无未清采购订单、无未清库存、无未关闭工单

四、实操示例：一次计量单位变更的完整处理

假设物料 MAT-10023 当前为已生效状态，基本计量单位是“个”。业务部门发现供应商实际按“箱”供货，每箱 12 个，需要将基本计量单位改为“箱”，同时保留“个”作为采购辅助单位。处理过程如下：

1. 创建人在主数据系统发起变更申请：
   物料编码：MAT-10023
   变更字段：基本计量单位 个 → 箱
   换算关系：1 箱 = 12 个
   生效日期：2025-07-01
   变更原因：供应商包装规格调整

2. 系统将物料状态从“已生效”置为“变更中”，
   旧版本 V1.0 仍对外可见，新版本 V1.1 处于草稿。

3. 审核人核对：
   - 换算关系是否与采购合同一致
   - 是否存在未清采购订单仍按“个”计价
   - 库存数量是否需要按新单位重算

4. 审核通过后，V1.1 生效，触发变更发布：
   下游系统收到增量消息，更新计量单位和换算关系。

5. 数据管理员检查下游回执：
   ERP：成功
   MES：成功
   WMS：成功
   若任一失败，进入重推队列并告警。

这个示例中，关键判断点是第 3 步：如果存在未清采购订单仍按“个”计价，变更就不能立即生效，需要先与采购部门确认处理方式，或者将生效日期推迟到订单清空之后。这就是状态机中“变更中”状态存在的意义——它给业务一个缓冲和检查窗口，而不是直接覆盖生效版本。

五、状态迁移的校验规则

为了让状态机可执行，需要在系统中配置迁移校验规则。以下规则可直接作为配置参考：

• 草稿 → 待审核：必填字段完整率 100%，物料编码在全局唯一，计量单位在允许值域内。
• 待审核 → 已生效：审核人已签署意见，且审核人 ≠ 创建人。
• 已生效 → 变更中：变更字段属于关键字段集合（计量单位、物料组、采购类型、税分类），非关键字段可直接修改并记录日志。
• 变更中 → 已生效：变更审核通过，且变更影响评估已完成。
• 已生效 → 已失效：无未清采购订单、无未清库存、无未关闭工单，且失效审批已通过。

这些规则的本质是把业务判断固化为系统校验，减少人为遗漏。规则不是越多越好，而是覆盖关键风险点即可。对于非关键字段（如物料描述的文字润色），可以允许直接修改并记录变更日志，不必走完整变更流程，否则会拖慢日常维护效率。

总结来说，主数据发布生命周期管理的核心是：状态清晰、节点明确、责任到人、校验可执行。状态机解决“什么时候能改”，发布节点解决“什么时候推给下游”，责任矩阵解决“谁来改、谁来审、谁来发”。三者配合，才能让主数据在跨系统同步中保持可信和可控。