Does MDM really reflect ECC?

[Former Member]

I've come to understand that MDM is intended as the master data repository for a variety of R/3 (ooops, I guess it's called ECC these days data types (or I suppose we can say business objects), such as vendors, customers, materials and so on. However, in trying to figure out why business partners related to a customer were not deleted in the related R/3 system after having been removed from the customer master in MDM, I got the reply from SAP that "we do not send deletions from MDM to R/3. The reason is that MDM simply does not know how the data is used in R/3 - meaning if it is already part in any processes (like billing, and so on) or not. If this is the case, a deletion would completely invalidate and falsify R/3 processes. From an MDM perspective, we cannot do this."

Does this not invalidate the principle of MDM? Or is MDM more like BW; just an accumulation or snapshot of the underlying business data (from various R/3 systems), with more of a one-way communication?

I'm slightly confused here... but a newbie in the MDM world...

[Former Member]

This is a good question you bring up, it's sort of interesting how it acts that way isn't it? The main reason is that MDM can simply delete records, where as in ECC you can't delete a record by which a transaction has been posted on. What you can do is "flag" the record for deletion. So one way to accomplish this goal is to have MDM send an IDoc with the flag for deletion field filled out so that it will trigger the record in ECC to be flagged for deletion. This further prevents transactions to posting on that record.

[Former Member]

You're hinting at the solution I'm just implementing for our own MDM team. Problem is that the existing (standard) function modules for handling inbound idocs from MDM never delete anything, since MDM (at least the way we set it up) never sends deletion process codes for these idocs. I re-wrote these functions, basically forcing a deletion where required.

In any way, the idocs are posted using standard input procedures (transaction calls), so I suppose the standard SAP logic in these transactions will prevent deletions of records that should be retained for historic purposes (or, indeed, flag them instead of physically removing them). To be verified!

But, my main issue is the apparent lack of synchronization from MDM to ECC...

[michael_theis]

The question is if you want to implement business logic into a master data management system, or not.

From my point of view, the main task of MDM should be the handling & maintenance of master data. It should allow storing the data; it should focus on matching, merging, deduplication, and so on to ensure a high master data quality; it should be able to 'know' where the master data is used - in other words it should contain key mapping information, and so on.

Regarding your scenario: imagine you've got a web shop. Someone logs in to your shop, registers himself. This data is stored in your MDM system. Now your new customer buys something. The customer record is now needed in your ECC to create the order and billing process, thus MDM distributes the data to ECC. Your customer receives his orders, he's happy and pays the bill. Then he decides not to use shop your shop any longer and 'deletes' his customer record. What do you do?

If your MDM system is used a data storage without any business logic behind, you could delete the customer record. But what about your ECC system? Don't you have to store the customer data fore some time due to legal laws? What if the product breaks and you need the customer record for warranty issues?

Anyways, as a matter of fact, you can delete records in MDM and you can distribute those deletion to an ECC system. This is possible, but you should exactly know, what you're doing. That's why this is not delivered as part of the ready to use standard content!

Cheers

Michael

[Former Member]

Thanks for your thoughts. There's actually a very simple and elegant solution to your scenario. Being a developer, I'll sketch out exactly what I'd want to happen:

When that customer deletes his/her account from the web shop, I'd want MDM to flag the record as expired, without physically deleting it, then pass that information on to any related ECC (or other relevant) system. Thus, MDM and everybody else would know that this customer was no longer active, at the same time as retaining the info for subsequent activities like reporting, accounting or possibly CRM-related tasks.

What happens in my original, limited scenario was that these business partners were not flagged for deletion, simply retained in SAP without even any "end-of-date" flag or any such indication that they were no longer needed. For example: whenever anyone makes a change to an existing business partner in MDM, R/3 would simply "accumulate" the new segments, ending up with numerous BP's where MDM stores only one... this is both wrong and confusing.

My personal guess is that this simply is due to a flaw in the R/3 system itself, whereby you cannot mark these segments as "invalid" or "expired". To conclude, a business object (in this case, the customer) lacks the attributes neccessary to maintain the desired data quality, both from an MDM point of view and seen from R/3. Maybe it's an issue of new world meets old, or maybe I'm just nit-picking...

[Former Member]

Hi Trond,

Its a controversy but form my point of view as of now you are right because on R3 side we dont have any standard mechanism or say fields/attributes to indicate that this customer record not required anymore or say customer deleted his/her record.

Yet one alternative is to use custom things, say any table/Idoc having indicator field for deletion or to deactivate the record on R3 side and once a customer do that R3 system should trigger the record to MDM to update the actual record, hence removing the confusion.

And having the indicator set to 'customer data deleted' , the record on R3 side still can be used for reporting, accounting and CRM related tasks.

But it may lead confusion when we dont have all the things custom.

Correct me if i am wrong.

BR,

Alok Sharma