Criteria for choosing repository

[Former Member]

Hi All,

I need an information:

Criteria to choose Customer or Business Partner repository?

Regrads,

Pramod

[Former Member]

Hi Pramod,

Actually in SRM business partner means supplier and .customer means enduser. business partner means those who supply the raw material to the cusomer.i.e.buyer.

Thus the decision of selecting a repository will depend on the nature of your use .

If you want to maintain a customer master purely which is required for transactions in Sales & Distribution then you can go for the customer repository or else for the customer buyer relationship maintenace you should go for Business partner.

Speaking of Customer Business content , it stores typically the customer master information residing in

KNA1 General Data-Client Level

KNB1 General Data - Company Code Level

KNB5 Dunning Info

KNBK Bank Details

KNVI Tax Indicators etc.

where as the Business partner empasises on the Relationship between client and supplier.

Hope this will help you to decide..

Regards

Deepankar

[Former Member]

Hi Pramod

Customer Repository is more suited when you have ECC as the source or target system as data model is similar as ECC customer with standard interfaces and IDocs as provided by SAP.

BP is more relevant when we want to store the relationship as well between BP types like enterprise/person and Group.This will be more applicable when the downstream systems are CRM/SRM where data model is more like BP.

hope this helped.

Regards

Ravi

[Former Member]

Hi Pramod,

SAP has provided the business content for many business objects such as Customers, Products, Vendor, Article etc.

For your requirement, you can have a lokk at the link below which gives you a detailed information on the:

MDM 5.5 SP06 - Business Content: Customer (ZIP File)

https://websmp102.sap-ag.de/~sapidb/011000358700001119652007E

MDM 5.5 SP06 - Business Content: Business Partner (ZIP File):

https://websmp102.sap-ag.de/~sapidb/011000358700001119622007E

Both these links contain a Zip file which gives you a detailed info the Fields Mappings and the check tables, Pdfs on XI Content etc.

Thwill give you a good idea on how to design your repository and you can improvise it according to your own requirement by customizing it.

For other info on all business objects, here is the link below:

https://websmp102.sap-ag.de/installmdm

Hope it helps.

Thanks and Regards

Nitin Jain

[Former Member]

Hi Pramod,

SAP has provided with standard repository archieves for Customer and Business partner based on ERP system.

So if you are integrating MDM with ERP system like ECC for extracting and consoildating Customer master or Business partner master then all you have to do is

- Place those archieves file .a2a in the archieve forlder under the mdm server path.

- Then unarchieve it on your MDM server.

- These files come along with the MDM package.

Hope It Helped,

Thanks & Regards

Simona Pinto

[Former Member]

Hi Simona,

Thanks for your quick reply.

I know that SAP has provided standard archives for customer & business partner.

I need to know how do you come to a conclusion to choose the specific repository?

Are there any specific advantages in using BP repository?

Regards,

Pramod

[Former Member]

Hi Pramod,

Please refer to my Post above.

Now, you can study the excel sheet given by SAP and check how far it matches with your requirement. using Business content is always advantageous when you are having an SAP landscape and also becuase they have thought of as many relevant fields and put together for our help.

However, if your landscape and the requirement differs, you can always either modify the business content or create a new repository by referring the business content.

Hope it helps.

Thanks and Regards

Nitin jain

[Former Member]

Hi Pramod,

The standard business contents provided by SAP for MDM are basically taking into account the ERP systems in the landscape and have come out with a standard rep.

So if you are using MDM for consolidation and harmonization of ERP systems data like ECC then you can well go ahead and use the std content rep.

However if are having other system also in yoour landscape which have a slightly differnt structure which can be adjusted within the std rep by adding od deleting some fields then you can continue with the sap delivered solution or else you can customize it your own.

Note that mostly your global data which are to be visible across the landscape are the ones maintained in MDM under the main tabel products and if teh local enrichment of teh master is continued to be taken care of in the local system then they need not be maintained in MDM.

Hope It Helped,

Thanks & Regards

Simona Pinto

[Former Member]

Hi Nitin,

Thanks for the documents.

If I look at the customer & BP repository i see some extra fields in BP repository.

One thing as you suggested based on the fieldas coming into MDM we need to decide upon the repository. I want to know are there any other criteria's (Business need) for chossing the repository.

Regards,

Pramod

[Former Member]

Hi Pramod,

Choosing a repository is the most important part of an MDM implementation. Hence, generally it takes a lot of time in understanding the Source systems, their fields, their corresponding purpose and the business flow. Also, you can also study the role of various departments involved in the process such as Finance, Engineering etc ( if any ) and create specific roles for them.

Based on this, we have to decide whether that field should become a part of the MDM repository.

Then we can compare the source fields and the fields which are already there in the Business content repository. If you feel that your business does not require that field to be present, and instead requires some other fields to be added, you can do so. Its all specific to the requirement.

Hope it helps.

Thanks and Regards

Nitin jain

[Former Member]

Hi Pramod,

Select the repository which involves less customization effort i.e. in which less number of fileds are to be created or modified.

Regards,

Jitesh Talreja