本文Jerry将介绍八款SAP产品中的客户模型。希望您在阅读完本文之后，能对SAP客户模型设计的思路有一个最最粗浅的了解。
由于Jerry水平和精力所限，本文不会详细阐述这些产品里的客户模型设计细节，而是介绍了一种方法，如果您对这些模型设计感兴趣，可以按照该方法自行深入研究。
SAP CRM
SAP CRM Fiori
SAP Hybris Cloud for Customer
SAP S/4HANA On Premise
SAP S/4HANA On Cloud
SAP Hybris Enterprise Commerce Platform
SAP Hybris Revenue Cloud
SAP Hybris Engagement Center
除SAP S/4HANA On Cloud之外，其他七款产品在SAP成都研究院均存在对应的开发团队。如果您对这些产品有进一步的问题需要咨询，欢迎留言。
可以按照客户的类型是Corporate或Individual来搜索。在SAP的很多产品里，这两种类型的客户共用同一个技术模型，通过模型上某个类型字段进行区分。本文只着重介绍Corporate Account。
这个BuilAdress节点是SAP CRM客户模型的子节点。SAP很多产品都有所谓Business Object(下文简称BO)的概念，这些模型从技术上来说是一棵树，由若干节点组成，节点与节点之间存在父子关系或者跳转关系。每个节点由若干字段组成，这些节点组成的模型，再加上节点上定义的一系列能够执行的动作(action)就构成了一个BO，实际上是sap对某一业务流程及参与实体的高度抽象的产物。
可以看出CRM Fiori和CRM UI显示的思路类似，都是把抬头类型的信息和各个维度的明细信息分开显示。同CRM相比，稍稍不同的是CRM Fiori的客户明细页面并不像CRM那样，各个维度的数据从上到下依次全部显示在一个页面上。因为要照顾到使用平板电脑或者手机访问系统的Fiori用户，所以CRM Fiori页面上只会显示某一维度的客户数据。不同维度的数据展示通过下拉菜单来切换。
使用我公众号文章Jerry和您聊聊Chrome开发者工具提到的技巧找到客户明细页面的UI模型地址:
/BYD_COD/SalesOnDemand/Account/UI/COD_Account_TI.TI.uicomponent
在Cloud Application Studio里打开该UI模型，点击Data Model即可查看C4C客户模型的设计明细。
这几个模型有什么区别和联系？借用面向对象程序设计的思路来解释C4C里客户模型的设计：类似面向对象编程语言里的父类一样，Business Partner这个BO定义了一些最基本最通用的字段，如下图正中的虚线框所示：Generic Attribute，Addresses和Relationships。其他模型Customer，Employee和Supplier，则在这些通用字段基础上定义了一些新的字段。对于Customer模型，其区别于Business Partner模型之处就在于需要维护一些和销售相关的信息，比如销售数据，销售区域和销售线索。对于Employee，关注点则在于工作地址，工作部门，领导等信息。
借用面向对象编程语言的继承概念，C4C的Customer和Employee BO继承了Business Partner BO上定义的通用字段，同时本身又定义了新的字段，这些字段将其自身和其他BO从业务上区分开来。
这些模型在SAP全球客户多年使用过程中，暴露出一些局限性和不足，例如一个Customer/Vendor只能维护一套地址信息；没有角色的概念，一个业务伙伴没法维护成既是Customer又是Vendor；没办法维护一些和时间相关的属性。
这些不足到了S/4HANA得到了妥善解决。在S/4HANA里，所有不同类型的业务伙伴使用统一的Business Partner模型。R/3的Customer和Vendor使用各自的模型和数据库表，到了S/4HANA，这些模型统一成Business Partner，通过BP Role来区分其角色，底层的数据库表也统一使用Business Partner的数据库表。
为了确保大量源自R/3的基于Customer/Vendor旧模型的应用能够继续工作，S/4HANA引入了Customer Vendor Integration(CVI)的概念，简单地说即每次S/4HANA应用使用新的Business Partner对应的API进行写操作时，数据不仅仅存储到新的Business Partner模型的对应的数据库表里，同时仍然会存储一份到旧的数据模型表里，如下图所示：
关于CVI的更多介绍，请参考博客：
Business Partner approach: Customer Vendor Integration to Business Partners (CVI)
Business Partner – Customer-Vendor Integration S/4 HANA
SAP S/4HANA on Cloud
和S/4HANA On Premise使用的客户模型相同，例如下图ID为1010的客户明细数据，
Hybris ECP backoffice里也存在Customer和Employee模型。因为是backoffice的使用场景，所以和前文介绍的SAP CRM和SAP C4C不同，这里的客户页面还包含一些其他维度的信息维护，比如密码策略和密码重置功能。
按照同样的逻辑再从Principal往上追溯，可以得到完整的类型继承链:
Customer->User->Principal->GenericItems->LocalizableItem->ExtensibleItem->Item。
由此得知Hybris的类型系统，对于Customer和User这些业务模型的关系描述采用的是继承的思路，而ABAP Dictionary里的类型模型则采用的是组合的思路。若干业务上相关的字段被放到一个结构体里，若干结构体再组合(include)成一个规模更大的结构体，最终形成一个给外界消费的结构体。
SAP Revenue Cloud是SAP最近发布的一款云解决方案。该方案能动态地规划、创新和调整系统，从云端自动管理和配置定价，报价，计费和订购等流程，从而超越报价到收款流程，通过变革实现盈利。
点击Customer tile查看客户主数据：
这些数据请求由部署在SCP上基于Java实现的Revenue Cloud微服务负责响应并返回给UI5前台。
SAP Hybris Engagement Center是SAP新一代全渠道呼叫中心SaaS产品。在坐席和客户的交互场景里，坐席需要在最短的时间内搜索出系统里存在的客户或完成新客户的创建工作。
通过expand指令在一个请求里将客户模型的抬头信息及地址信息一并取回。观察HTTP请求的响应结构，得知Engagement Center的客户模型里，地址信息维护在子节点Addresses上。
这篇文章简要介绍了SAP几款产品中客户模型的建模情况。通过SAP不同产品里客户数据模型的比较，我们了解到这些模型的复杂程度随使用场景的不同而有所区别。您也可以按照本文介绍的使用Chrome开发者工具这一方法，自行研究您感兴趣的SAP产品里的模型设计。甚至，您可以用同样的方法看看Salesforce的客户模型是怎样设计的。
感谢阅读。