Initial Data Load and On-going Update Process

[former_member496675]

Hi,

We are doing a typical R3-MDM-R3 integration. We are going to extract the data from R/3, populate MDM (first the lookup tables using maps 1-99 and then the main table using map 00). We will consolidate and scrub the data here in MDM. After that's done. We will start populating our new target R/3 system. Here's where I am a little weak as to how to do that.

Let's take Vendor example. For loading the data from MDM into R/3 are we going to first syndicate all lookup tables (Countries, Account Groups, Bank Details etc.) and then the main records? Does that mean that we will be using 30+ maps to syndicate all these? If that is the case then why these syndication maps were not supplied with the repositories? If this is NOT the case then please enlighten me how do we go about sending lookup tables data and main table data to R/3?

Now the second question is about the continuous update of MDM and R/3. Suppose that we loaded all the data in R/3 and the R/3 system is up and running. Now users make some changes in R/3 check tables (e.g. they add account groups, or regions etc.). How these changes will be reflected back to MDM? Will we be always extracting the check tables and updating MDM using import server (Can we even do that?)? Similarly, will we be always sending all the check tables and main tables back to R/3?

I'd really appreciate if someone could explain this process with pros and cons to me. I have a feeling that we are trapping ourselves in a complex non-ending import/syndicate cycles.

Regards,

TS

[michael_theis · Accepted solution]

Hi TS,

Again my first tipp for you is to have a look at the SP5 Patch 1 content as there are some changes (and improvements) for the load of reference data are introduced with this version for the Customer / Vendor / Material repository.

It is not the task of MDM to consolidate or harmonize reference (look up) data between SAP systems. This task is already solved by SAP's Sollution Manager, thus there is no need to invent a working sollution twice. This is the first reason why there are no syndication maps for look ups. The second reason is that there's no import functionality available in R/3 for those look ups. There's no ALE to fill the country table. The way to go is the transport mechanism that each R/3 has built in.

Anyways the import of reference data into MDM is required because the Master Data records later will contain only codes in the IDoc message (If you send an American Vendor from R/3 to MDM, the IDoc will contain country code US but not the speaking name). Extracting the reference data (codes and names) ensures that you see the country's speaking name AND that you can use the country code for message exchange. This is the sense of reference data in MDM.

If you update reference data in your running R/3, you have to update the reference data in your running MDM accordingly. Unfortunately there is no standard "delta handling" available yet. This means if you change or update reference data in R/3, you have to manually re-run the reference data load for MDM in your R/3 system. There's not yet a automatic process available. Nevertheless you can use the Import Manager and / or Import Server for importing the data into MDM.

The interesting question is: is it really the case that reference data is changed this often? I thought that customizing data is more or less "stable" and not changed on a daily basis?!

BR Michael

[former_member496675 · Accepted solution]

Thanks Michael.

So let me see if I got this right.

1. We don't export reference tables from MDM to R/3 as the functionality to import these reference tables in R/3 is not available. Correct?

2. We transport these reference tables directly from old R/3 systems to upgraded R/3 system. Correct?

3. If we make changes in reference tables in R/3 we will need to extract these table and import them in MDM manually (but it's not frequent). Correct?

4. If we add something in MDM in reference table, we will need to make this change manually in R/3 system. Correct?

Looking at the point 2 mentioned above about transporting reference data directly from old R/3 systems to new one, the question that comes to my mind is that how do we handle data consolidation for reference tables? For example if I am importing bank detail data from two or more R/3 systems and if they have duplicate records then where am I doing the consolidation of the data?

Secondly, I also have to bring data into MDM from other ERP systems like JD Edwards. What would be the strategy to send this data to SAP R/3 system? I am assuming that there is probably no transport available to transport JD Edwards data to R/3 system directly. So how do we deal with this situation especially for reference table data?

Regards,

TS

[michael_theis · Accepted solution]

Hi TS,

1. This is correct.

2. This is correct. Regarding your question about hte uniqueness of the reference data, this is handled by Solution Manager and latest by the target R/3 system because this does not allow you to create duplicates. Following your example of bank data, each bank a a unique key. You can not insert the same bank key twice into R/3!

3. This is correct. Youu have to start the extraction in R/3 manually. The import / update in MDM can be done with Import Server.

4. This is correct.

Regarding JD Edwards, do you expect new reference data that does not yet exist in R/3? If yes, I think that you have to add this reference data to R/3 manually, too. If not, this is not an issue. You can import the reference data into MDM, then import your JD Edwards Master Data. If you now sen d the Master Data to R/3, MDM will use the corresponding R/3 reference data, thus you'll have a "translation" from JD Edwards reference data to R/3 reference data.

BR Michael

[former_member496675 · Accepted solution]

Once again Michael thank you very much for your response.

Regards,

TS