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成都研究院均存在对应的开发团队。如果您对这些产品有进一步的问题需要咨询，欢迎留言。

SAP CRM

可以按照客户的类型是Corporate或Individual来搜索。在SAP的很多产品里，这两种类型的客户共用同一个技术模型，通过模型上某个类型字段进行区分。本文只着重介绍Corporate Account。

下图是SAP CRM里某个Corporate Account明细页面的抬头区域。

客户明细页面的抬头区域下部由若干可以通过点击小三角符号来展开的区域组成。SAP的技术文档里称这些区域为Assignment Block。

如何查看SAP CRM的客户模型呢？在上图客户页面按F2，会显示如下弹出窗口，显示该页面实现的BSP应用视图名称为BP_HEAD/BPHEADOverview。

在BSP开发工具里打开该视图，能看到每一个Assignment Block的技术明细。

假设我想深究下图名为Address的Assignment block实现明细，在上图中得知其BSP实现为BP_ADDR/CorpAccountAddresses。在开发工具里打开此视图，找到地址数据是来自模型节点BuilAddress。

这个BuilAdress节点是SAP CRM客户模型的子节点。SAP很多产品都有所谓Business Object(下文简称BO)的概念，这些模型从技术上来说是一棵树，由若干节点组成，节点与节点之间存在父子关系或者跳转关系。每个节点由若干字段组成，这些节点组成的模型，再加上节点上定义的一系列能够执行的动作(action)就构成了一个BO，实际上是sap对某一业务流程及参与实体的高度抽象的产物。

CRM客户模型的底层数据库表：BUT000。用于区分Corporate还是Individual Account的字段名称: TYPE。

通过模型单元测试工具，能够清楚地看到客户的地址信息是维护在节点BuilAddress里的。下图是CRM Business Object测试工具截图，左上显示了该模型的节点集合，左下显示了当前选中节点为BuilAddress，右边区域显示了这个节点所有字段的内容。

SAP CRM Fiori

前一章节介绍里使用CRM Web Client UI打开了一个Corporate客户。这里用SAP CRM Fiori再次打开它。

SAP CRM Fiori

前一章节介绍里使用CRM Web Client UI打开了一个Corporate客户。这里用SAP CRM Fiori再次打开它。

例如选中Marketing Attributes维度后，在Chrome开发者工具里能观察到一个HTTP请求，观察其路径发现CRM_BUPA_ODATA，这其实是OData服务的技术名称。

SAP Hybris Cloud for Customer

工作中心视图Accounts和Individual Customers分别对应了SAP CRM里的Corporate Account和Individual Account。

/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从业务上区分开来。

作为一款云解决方案，您可以通过一些非常简易的步骤，在短短几分钟之内通过OData Service或者Web Service，实现您的第三方应用和C4C客户模型的各种交互。例如您可以将C4C的客户数据暴露出来供第三方应用读取，或者通过第三方应用对C4C客户数据进行写操作。

这些模型在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模型的对应的数据库表里，同时仍然会存储一份到旧的数据模型表里，如下图所示：

SAP S/4HANA on Cloud

和S/4HANA On Premise使用的客户模型相同，例如下图ID为1010的客户明细数据，