Skip to Content
I will introduce customer model design in eight SAP products. Hope you can get a most basic understanding about how customer model is designed in these different SAP products.

SAP CRM

Customer data could be searched by type as Corporate or Individual. In many SAP products, an unique model is used for both type. In this blog I will only focus on Corporate Account.
Here below is the header area of Corporate Account detail page in SAP CRM.
There are lots of Assignment Block which could be expanded by clicking the small triangle icon:
How to inspect technical information of SAP CRM Customer model? Press F2 to display technical information: the customer overview page is BP_HEAD/BPHEADOverview.
Detail technical information for a given assignment block could be displayed in BSP workbench:
Suppose I would like to dig into the technical detail of an Assignment block named Address, first of all I find its technical name BP_ADDR/CorpAccountAddresses. Open it in work bench and know the address data comes from model node BuilAddress.
BuilAdress node is a sub node of CRM Customer model. The concept Business Object is used in many SAP Product, being a tree consists of several nodes from technical perspective. Parent-child and navigation relationship are modeled in BO. The nodes themselves, those relationship among nodes, and executable action modeled in the nodes, all of those stuff constitute a Business Object.
CRM Customer model underlying table: BUT000. The field for Corporate / Individual Account differentiation: TYPE.
Via BO test shell in CRM, it is clearly found that customer address data is maintained in node BuilAddress. Below is the screenshot in CRM BO test shell: in the top-left area the node collection is listed, the selected BuilAddress is marked in bottom-left area. All fields content are displayed in the right area.

SAP CRM Fiori

A screenshot of customer list in SAP CRM Fiori application named “My Account”.
CRM Fiori has the same design idea as in SAP CRM UI: customer header data and detail data in various dimension are maintained and displayed seperately in UI. A slight difference: SAP CRM displays detail data of a customer in a waterfall style, from top to bottom. However for SAP CRM Fiori, in order to support customer data display in a limited size of screen( for example mobile access), at a given time only a single dimension of detail data is displayed in CRM Fiori. Different dimension are switched via drop down list.
For example, choose Marketing Attributes from drop down list, and then you can observe an HTTP request in Chrome development tool. There is a fragment CRM_BUPA_ODATA included in request url, which is the technical name of OData service.
In SAP gateway(frontend) server search by key word = CRM_BUPA_ODATA, and a list of backend system which contains the implementation of this OData service is returned.
Let’s review the architecture below mentioned in my Wechat article SAP Fiori应用的三种部署方式 . The gateway server mentioned above is highlighted with red below, while the backend server with blue where OData service implementation is done:

SAP Hybris Cloud for Customer

Work center view Accounts and Individual Customers are counterpart for Corporate Account and Individual Account in SAP CRM.
Although slightly different regarding UI style compared with SAP CRM but idea is the same: customer header data is displayed in the left part now, while other dimension data is displayed in the right part. Each dimension is displayed in a dedicated tab, something like the tab-strip control in ABAP Web Dynpro.
Use the tips introduced in my Wechat article Jerry和您聊聊Chrome开发者工具 to find the technical information of customer detail page model in C4C:
/BYD_COD/SalesOnDemand/Account/UI/COD_Account_TI.TI.uicomponent
Open this page model in Cloud Application Studio, click tab “Data Model” to see technical detail of Customer model in C4C:
Here we know that in C4C the Customer model is still a Business Object, located in namespace http://sap.com/xi/AP/FO/BusinessPartner/Global.
There are some other BO in this namespace such as Customer and Employee.
Any relatioship among these models? Here we can borrow the concept of Object-oriented programming concept to explain: just as the “super” class in OO programming language, most basic and commonly used fields are modeled in Business Partner BO, as marked with Generic Attribute, Addresses and Relationships below. For other model Customer, Employee and Supplier, some dedicated fields are required, from business pespective Customer model focuses on sales related data like sales area and sales lead, while Employee model should care more about work address, work department and management information. Those specific fields are modeled in each model seperately.
In a word, the Customer BO and Employee BO inherites commen fields from Business Partner BO while a series of new fields are modeled in themselves.
As a cloud solution, it is possible for you to expose Customer model via OData service or web service for third-party integration via very simple steps.
For example, you can expose C4C customer data to third party for read access, or enable third party to directly update C4C customer data.

SAP S/4HANA On Premise

In SAP ERP different types of business partners are created with different transaction codes:

Limitations of those models are reflected during being used by SAP global customers for many years:

  • only one set of address data could be maintained for Customer/Vendor
  • no role concept exists: it is not possible to maintain a business partner as both customer and vendor
  • no time-dependent attributes
Such disadvantages are well resolved in S/4HANA. A consolidated data model for Business Partner is used for all types of partners. When Customer and Vendor model in ERP move to S/4HANA, they become Business Partner model with different BP role.
Customer data creation is now centrally done by tcode BP. All other creation tcodes from ERP are marked as obsolete now. Once executed, they will be redirected to tcode BP as well.
In order to ensure lots of old application based on old Customer/Vendor model can continue to work in S/4HANA, a mechanism called Customer Vendor Integration(CVI) is introduce. Simply speaking, every time new API on top of consolidated Business Partner model is called, the data is not only stored in talbe BUT000 for new model, but also converted and replicated into table of old model as well:
For more CVI introduction, please refer to SAP community blogs:

SAP S/4HANA on Cloud

Same Customer model is used as in S/4HANA On Premise:
Customer data is read from ABAP server via OData service MD_CUSTOMER_MASTER:
When you switch to different tab, the corresponding data is retrieved via a dedicated HTTP request:
Detail data of each tab is bound to a sub node in Customer model. Although we could not log on to backend in S/4HANA on cloud, the fields of Customer model in S/4HANA cloud could still be observed in Chrome development tool:

SAP Hybris Enterprise Commerce Platform

There are also Customer and Employee model in Hybris ECP backoffice. Due to the backoffice scenario, unlike Customer model in C4C, there are some other functions available on top of these models, for example password policy maintenance and password reset.
The Hybris model is defined in xml file. The definition of core data type is maintained in core-items.xml:
In this xml we can find out that Customer model in Hybris is extension of User model. The new fields extended by Customer model: customerID.
Once command “ant build” is executed, there will be a file CustomerMode.java generated automatically, located in folder:
\bin\platform\bootstrap\gensrc\de\hybris\platform\core\model:
Look into source code of CustomerModel.java: the Customer code declared in xml file 1757 line appears in line 40 in CustomerModel.java; new field customerID in 1763 line in xml file appears in line 43 in CustomerModel.java.
The implementation for User and Customer model, UserModel.java and CustomeModel.java, are located within the same folder. Open UserModel.java, and find it is extended from PrincipalModel.
This inheritance is defined in core-items.xml as well.
In the same way, User model extends Principal mode with new attributes listed below under attributes tag in xml file:
Looking upside in the same way repeatedly, we can get the whole inheritance chain:
Customer->User->Principal->GenericItems->LocalizableItem
->ExtensibleItem->Item
Based on the finding above, we can draw a conclusion that in Hybris type system, the relationship between Customer model and User model is maintained via inheritance idea. We can think about the composition idea in ABAP Dictionary: fields belonging to a given business scenario are put to a structure, several structures are composited by a bigger structure to build out a complex structure in the end. See one example below:

SAP Hybris Revenue Cloud

A cloud solution released recently, which could simplify and synchronize your CPQ, ordering and billing processes with an automated approach from the cloud.
Click Customers tile to check customer master data:
Customer master data is displayed in a typical Master Detail style.
Check from Chrome development tool: a request to read customer detail data with page size 40 is issued. The customer header data is fetched and displayed in master list: customer ID, customer type and customer name.
Select a given customer in master list, another HTTP request will be sent to backend for left part of customer detail data: customer address, customer contact and customer marketing attribute. Those three types of data are modeled via three sub nodes of Customer model in Revenue Cloud, fetched via a single HTTP request by expand option.
The node detail fields could be found in Chrome development tool:
Those data are served by micro-service deployed on SAP Cloud Platform developed by Java.

SAP Hybris Engagement Center

SAP Hybris Engagement Center, an omnichannel cloud-based customer engagement solution that allows organizations to seamlessly blend unassisted and assisted service with digital commerce before, during, and after the buying process. In call center scenario, agent should finish the customer identification or new customer creatiom in the shortest time:
The Corporate account UI in SAP Engagement Center:
Before customer detail page is displayed, needed data is fetched via HTTP request:
The customer header data with other part of detail data like address are retrieved from backend system within a single request using expand option. Inspect the structure of HTTP response: the address data is maintained in node Addresses of Customer model in SAP Engagement Center.
From response structure we can also know that multiple adddress and role are supported for a single customer:
This blog gives you a brief introduction regarding Customer model design in eight SAP products. We now realize that customer model complexity varies according to the concrete use scenario. You can also use Chrome development tool to inspect customer model fields of other SAP product not mentioned in this blog.
You might even have a look at Customer model in Salesforce.
Thanks for reading.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply