内核探秘：SAP CRM 产品主数据模型设计的智慧之道

本文阅读目录：

物料主数据系统设计的难点

SAP CRM 产品主数据系统的设计概述

SAP CRM 产品主数据设计的抽象层

SAP CRM 产品主数据的读写引擎

基于元数据驱动的 SAP CRM 产品主数据 UI

本文关于 SAP CRM 产品主数据设计的内容，来源于 SAP 官方帮助文档，链接如下。

物料主数据(Material Master Data)是企业业务流程中的一个关键组成部分。物料主数据是物料关键信息的集合，包含物料的编号、描述、规格、类别、单位、仓库位置、成本、以及其他相关数据，为生产计划、物料管理、库存控制和销售等核心业务功能提供支持。

物料主数据不仅贯穿于整个供应链和生产过程的各个环节，同时也广泛参与到企业内部多个部门的业务流程。

物料主数据系统(或者模块)的模型设计，犹如移动摩天大楼的地基，在任何一个 ERP 软件中都是设计和开发的重头戏。

一个健壮，完善，可用性好，可扩展性强的物料主数据系统，可以帮助企业提高运营效率、减少错误并增强供应链及相关业务流程的透明度。

物料主数据系统设计的难点

数据模型的复杂性：由于物料的类别和用途多样，物料主数据系统需要能够处理各种不同类型的信息，包括普通的成品、半成品、原材料、辅助材料等等。

每种类型的物料都可能有独特的属性和数据需求。例如，化学品需要记录其化学成分和安全处理信息，而机械零件可能需要记录其尺寸、公差和材料等具体信息。

有些 ERP 系统把服务(Service)也当成一种特殊的物料主数据进行处理，又称为 Service Product.

对于服务而言，其关键属性比如服务等级协议（Service Level Agreement）、响应时间、服务费用、服务可用时间、所需资源、成本定价、计算策略等，都与有形的传统物料大相径庭。这也进一步增加了物料模型设计的复杂度。

数据集成和接口：物料主数据系统通常需要与其他企业系统进行集成，比如采购系统、库存管理系统、生产计划系统和财务系统等。不同系统之间的数据接口设计是一个复杂的过程，需要确保数据能正确传递，并保持一致性。

此外，这些接口还需要具有足够的灵活性，以便系统升级或业务流程调整时，能够进行相应的修改。

多部门协作和权限管理：物料主数据系统涉及多个部门，如采购、生产、销售、物流和财务等。因此不同部门对数据的需求和权限也不同。设计一个健全的权限管理系统，确保合理的数据访问控制，同时避免数据孤岛现象，也是系统设计的一个重要挑战。

扩展性和灵活性：企业的业务需求可能随时间变化而不断扩大或调整，物料主数据系统需要具备足够的扩展性和灵活性，以应对这些变化。例如，企业可能引入新的产品线，或者需要满足新的合规要求等等。

SAP CRM 产品主数据系统的设计概述

笔者先后在 SAP Business By Design，SAP Business Suite CRM，SAP Cloud for Customer 和 SAP S/4HANA 开发团队都工作过。这么多年的工作经历，我能感觉到，SAP 在复杂系统设计这个领域，确实积累了很多一脉相承的设计理念和准则。

给我印象最深的有两点：

1. 按需引入抽象层来应对业务需求的高复杂度
2. 把稳定的逻辑实现成引擎，易变的需求，通过配置和增强出口去承载

在 SAP 系统里，Material 和 Product 这两个概念紧密相关却又有所区别。

Material(物料)主要应用于生产、采购、库存管理等后台(Back Office)业务，强调物理属性和存储管理，例如重量、尺寸、仓库位置等。在制造企业中，物料是生产流程的核心，是投入品和产出品的管理对象。

Product(产品)主要应用于前端销售、市场营销、客户关系管理等领域，更加关注市场和客户视角，例如产品特性、市场定位、定价策略等。在服务型企业中，产品更多是指服务包或解决方案，而不仅仅是物理商品。

SAP CRM 产品主数据设计的抽象层

SAP CRM 产品主数据抬头级别的数据库表，只有寥寥几个字段，产品 ID，GUID，产品类型，创建者，创建时间。

为了用一套模型描述现实业务中千差万别的产品特征，CRM 产品主数据背后是一系列层层相扣的抽象层：Product Hierarchy，Product Category, Settype 和 Relationship.

Product Hierarchy

这是 SAP CRM 主数据模型最高层次的抽象。

帮助文档地址：

https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/465754c601a208e7e10000000a114a6b.html

Product Hierarchy 是一个树形结构，定义了系统里 Product Category 之间的继承从属关系，每个叶节点就是一个 Product Category. 在树形结构里，叶节点代表的 Product Category，继承其父节点 Product Category 的模型属性。

SAP CRM 支持从头新建 Product Hierarchy, 也支持使用中间件，从 SAP ERP 下载 Product Hierarchy 到 CRM 使用。

Product Category

Product Category 即业务流程中描述产品类别的概念，是 Product Hierarchy 树形结构模型中的一个个节点。注意 Product Category 并不直接描述产品属性，它只是产品属性的一个容器。

帮助文档：https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/4657246601a208e7e10000000a114a6b.html

上图最顶层的 Stationery 代表文具这类产品的 Hierarchy. Hole punches，Pens 和 Paper 就是一个个 Product Category.

Product SetType

Product SetType 是真正用来描述产品信息的属性组。每一个维度的产品信息，都对应一个 SetType 模型。一个 Product Category 可以分配多个 SetType 模型。

例如某些产品在生产和销售时采取不同的计量单位，比如针剂生产时单位为“支”，销售时为“盒”。那么使用一个 Unit 转换的 SetType 进行维护，在 SAP CRM 里通过 SetType COMM_PR_UNIT 实现如下：

再比如一个全球化医药公司，在不同国家销售药品时，必须按照当地法规用当地语言提供药品的成分、用法、注意事项等详细描述。这些描述的多语言版本信息，通过 SetType COMM_PR_SHTEXT 实现。

Product Hierarchy，Product Category，Product SetType 和其容纳的属性，用下面这张图说明。

下图出自 SAP 官网：

https://help.sap.com/docs/SAP_CUSTOMER_RELATIONSHIP_MANAGEMENT/b90203d3616f482ebd9776775ac722d8/4657672501a208e7e10000000a114a6b.html

SetType 里的每个属性，根据实际业务，又具有是否允许多个产品主数据重用(Multiple use)，以及是否和组织单元相关(Organizational Dependency)的元属性。

Product Relationships

有些产品主数据的属性，彼此之间具有关联关系，或者同其他类型的主数据，比如 Business Partner 主数据具有关联关系。这种主数据记录，是一个二元组数据结构：(Source, Target).

这种二元组数据结构，通过 Product Relationships 维护。

常见的例子有 Accessories 配件，Services 服务，Service Parts 维修零件，Qualification Requirements 资质要求，Warranties 保修等等。

SAP CRM 产品主数据的读写引擎

一个产品主数据，通过其所属的 Product Category，最后承载了二三十个 SetTypes 和 Relationships, 在笔者经历的 SAP CRM 国内项目的实施中，这种场景毫不为奇。

那么面对如此复杂属性的产品主数据，其数据读写逻辑应该如何完成？

如果查看 CRM 产品主数据的数据修改门面(Facade 设计模式)的入口函数，会发现输入参数如此简单，最主要参数的就两个：待修改的产品编号，以及被分配的 Product Category 集合。

这是因为，SAP CRM 产品主数据每一个 SetType，都有自己的元数据集合，如下图所示。

这些元数据集合，包含了 SetType 数据的持久化数据库表，数据读写和持久化函数等等。

当 SAP CRM 产品主数据的读写引擎接收到数据读写请求时，只需要从输入的 Product Category 参数值，解析出这些 Category 指派的 SetType，然后将读写请求，转交到对应的 SetType 元数据里维护的数据读写逻辑即可。

这就体现了笔者之前提到的设计理念：「将稳定不变的逻辑，实现到引擎层面」。

将和业务有强依赖，紧耦合的逻辑，做成可配置的模块（Configurable Module），比如上图展示的每个 SetType 可配置的持久化数据库表和读写逻辑，从而将变化与具体实现解除耦合关系。

采取这种设计之后，如果因为业务调整，需要给某类型的产品主数据增添新的属性，典型的流程就是，新建一个 SetType，为其维护持久化数据库表和数据读写逻辑。

将这个新的 SetType 分配到某个 Product Category，或者新建 Product Category 即可。整个过程中，无需修改本身已经非常稳定的产品主数据读写引擎。

基于元数据驱动的 SAP CRM 产品主数据 UI

SAP CRM 产品主数据的 UI 也是具备高度 Composability，其内容渲染，完全基于 SetType 和 Relationship 的元数据驱动。

下图是 SAP CRM 产品主数据的明细页面。图中红色矩形框区域为产品抬头级别的通用字段集合。任何不同类型的产品主数据，都会显示这些字段。该区域为静态页面。

该区域之外的其他所有页面，都是应用运行时根据当前显示的产品主数据分配的 SetType 和 Relationship，在系统后台动态生成的。这是一种服务器端渲染机制。

SetType 和 Relationship 允许客户自定义创建。这些客户定制出的模型，在产品主数据 UI 上享有和 SAP 原装模型一样的待遇，通过同样的渲染逻辑进行显示。

本文结合笔者工作经验和 SAP 官方帮助文档上的内容，对 SAP CRM 产品主数据模型的设计做了基本的介绍。欢迎各位同行阅读和指教。