主数据管理 P24 · 主数据与配置
主数据是供应链系统的地基。地基歪了，上面所有模块都会出问题： 计划算错、库存对不上、报表口径打架。这一页讲清楚"哪些数据是主数据、归谁管、怎么管"。
六类核心主数据、编码规则、生命周期（申请–审核–发布–变更–失效）、治理原则、常见事故。
MDM 主数据管理、物料主数据、BOM、唯一源头（Single Source of Truth）、一物一码、数据责任人、冻结与失效。
允许业务人员在业务单据里"随手新建"物料。结果是一物多码： 同一个螺丝在系统里有 6 个编码，每个都有库存，但谁也不知道总共有多少。
1. 六类核心主数据
点击查看每类主数据的关键字段与归口部门归口：研发/技术 + 数据管理岗（编码分配）。
为什么难：物料字段横跨采购、仓储、生产、财务、销售，每个部门都要加字段， 且各部门对"规格描述"的粒度要求不同。
关键设计：区分集团级字段（统一维护）与组织级字段（各公司自行维护），避免一刀切。
归口：研发/工艺。
为什么关键：BOM 错了，MRP 算出来的采购量全错（P05），这是最贵的一类数据错误。
关键设计：BOM 必须版本化 + 生效日期。工程变更（ECN）时不能覆盖旧版本， 否则历史订单的成本会被追溯篡改。
归口：Sourcing/采购 + 财务（银行信息）。
风险点：银行账号变更必须走独立审批 + 电话回拨确认，这是防诈骗的关键控制。
归口：销售运营 + 财务（信用）。
关键点：收货方与付款方可能不同（集团采购、门店收货）， 模型上必须支持"三方可选"：售达方、送达方、开票方、付款方。
归口：仓储运营。
设计要点：库位编码要可读且可排序（如 A-01-03-02 = A 区 01 排 03 列 02 层）， 直接影响上架与拣货效率。
归口：销售（售价）/ 采购（采购价）+ 财务审批。
关键点：价格必须按生效区间存储而非覆盖，且要有最低售价管控与折扣审批， 否则销售可随意放价，毛利说不清。
2. 编码规则：看起来最无聊、出错代价最高的设计
好编码的三个特征
- 唯一性：一物一码，绝不重复（这是底线）。
- 稳定性：编码一经分配永不改变，即使物料改名或停用。
- 可读性适度：能看出大类即可，不要企图把所有属性塞进编码（规格、颜色、供应商都塞进去，编码会失控）。
两种流派
有意义码：含分类信息，人能看懂，但分类调整时会失效。
无意义流水码：纯数字自增，永不失效，但人看不懂，必须靠名称与分类字段。
实务推荐：大类用有意义段（2–4 位），剩余用流水号，兼顾可读与稳定。
① 一物多码：同一物料多个编码，每个都有库存，导致重复采购、总库存虚高、呆滞无法识别。
② 一码多物：不同物料共用一个编码（常见于"临时用一下"），导致成本核算与产品质量追溯全部失效。
3. 主数据生命周期
点击播放，逐步查看唯一源头原则
每类主数据只能有一个创建入口，其他系统通过接口同步。 多系统各自维护 = 必然对不上。
数据责任人
每一类主数据必须有明确的归口部门与责任人， 而不是"谁用谁维护"——后者等于没人负责。
只冻结不删除
主数据永不物理删除，只做冻结/失效。 删除会让历史单据失去关联，追溯链条断裂。
4. 主数据治理的落地顺序
- 先盘点再治理：导出全部物料，按名称/规格做相似度聚类，摸清一物多码的规模（通常会超出预期）。
- 定标准：编码规则、必填字段、命名规范、分类树——这些要写成制度而非口头约定。
- 卡入口：在系统里关闭业务单据新建物料的权限，强制走主数据申请流程（这一步最难，但最关键）。
- 清存量：把多码合并（保留主码，其余冻结并做库存调拨合并），这一步需要业务深度参与。
- 建监控：定期跑数据质量报表（缺必填字段、重复率、长期未使用物料），持续治理。
主数据模块通常"没故事可讲"，在需求评审中最容易被砍。但它决定了系统能用三年还是三个月。 砍主数据功能的代价，会在上线一年后以十倍成本还回来。
功能演示：物料主数据维护
可真实操作：新建（查重拦截）→ 提交审核 → 发布生效 → 变更留痕物料清单 可操作
主数据的第一道闸门是查重：试着新建一个已存在的编码（比如 MM-1001），会被直接拦下来。 已发布的物料再改价格，不会直接覆盖，而是进入「变更中」并升版本——主数据变更必须留痕， 否则历史订单的价格就对不上了。