Skip to Content
avatar image
Former Member

Maintaining the MDM ID on the target systems

Hi

I understand that maintaining the MDM Id on the target helps in better traceability. But is it absolutely necessary to maintain MDM Id on target systems? this would require identifying an additional field on all the target systems.This will be quite challenging some times and would require business justification if we plan to use an existing field for a different purpose. Can you pls help me with all the conditions or reasons that you have come across that makes it an absolute necessity.

Thanks & Regards

Arvind

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Sep 11, 2008 at 04:25 AM

    Hi Arvind,

    There can be 2 MDM ID's which you can refer to.

    1. MDM- AutoiD - This is generally used when the source file soes not contain any field which has unique values. Hence, MDM uses this field of type MDM ID to generate unique numbers internally for each record.

    You might be refering to the 2nd ID.

    2) Remote Key Value- This is used for idenifying the source system and relates the incoming data with the respective source systems. There might be many source systems from which the data might be coming into MDM. Now, once the data enters MDM, there should be a capability in MDM which identifies the source systems and their corresponding records, so that later on while sending back you can send it to the correct target system.

    This Need not be sent to the target system. However, can just be used for identifcation of the correct records to the correct remote system. To systems like BI, this can be done quite easily.

    However, the transactional systems like ECC, we can avoid creating an extra field. It all depends upon the requirement. You can even use any search field which is generally not used in ECC and populate it with the merged ID.

    The mapping can be managed in the syndicator according to your needs.

    Please refer to the link below for better understanding of Remote systems and ports concept.

    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30843106-5539-2b10-75a9-da483911b0d9

    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7051c376-f939-2b10-7da1-c4f8f9eecc8c

    Hope it helps.

    Thanks and Regards

    Nitin Jain

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 11, 2008 at 04:20 AM

    Hi Arvind,

    When ever MDM is been used for consolidation and Deduplication purpose of Master Data a Global ID is assigned to the merged records to identify them as possible duplicates by the target system.But when this Global id is send to the target sytem it will have to be accomodated on the receiveing end which is not possible in most cases:

    Below are the Few Scenario where and how can the Global ID be accomodated:

    - BI-MDM: One of the major areas where Master data management is required is for BI reporting without MDM is place Bi will be reporting on inconsistent data which will result in wrong reports and thus wrong business decisions So Master data are first filtered out in MDM and then passed to BI for correct reporting in this case. If we are using BI 7 then we have a MDM-BI package that needs to be deployed on BI By doing this an Additionla Field is generated in BI which handles the Global Id send from MDm without much difficulty so this justification is sufficient as the receipient system has provision to handle it.This can also be taken care when working with BI3.5

    You can follow the below link to understand the same:

    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d06a92de-614e-2b10-4989-d913c2154a64

    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b01e4269-f744-2b10-929b-fa7b49aac540

    - R/3/ECC- MDM:This is the second Major area where MDM is used for consolidation and harmonization of master data,but in this case ERP system has no provision to take care of the global id field as that would require modifying the std tables and fields in ECc which are not desirable.In this case i would suggest that MDM be used for inding duplicates howeevr the deuplictaes rec need not be merged and send back rather just be marked as duplicates to notify that thaey ar similar rec and then the care be taken to handle them in ECC iself.

    - SRM-MDM etc:In most other scenario besides the two mentioned above MDM is used for data enrichment such as RPCM(Rich product catalog managemnet) where matching and merging is not the prime focus.

    It is important to note that although MDM is primarily used for finding duplictaes it has many other functionlaities which it can perform like ensure Data completeness,Data accuracy,Enrichment,Governance etc

    Hope It Helped,

    Thanks & Regards

    Simona Pinto

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 17, 2008 at 07:54 AM

    Hi,

    I wouldn't use the MDM-Id type AutoId as a field in the target structure, because:

    - When you continue to consolidate data in MDM with merging, the new merged record gets a new ID and cannot be matched to your target system anymore.

    - AutoId would make sense to be able to identify uniquely the records in case of importing something back from legacy system. But Import manager doesn't allow to match on AutoID. I've tried it with a workaround in creating a calculated field in MDM with AutoId as content, it works but costs a lot of performance.

    - You've mentioned it already, in some systems it is a big effort to create or assign a field with this content in the target systems

    After 3 years experience I try to keep on the remote key principle, even it is not visible

    (Does anybody know wether it is visible in 7.1, we're working in 5.5?)

    it is the most reliable and performant way to identify target system records.

    Rgds Jutta

    Add comment
    10|10000 characters needed characters exceeded