As many of you know SAP is pitching MDM as the tool for three particular scenarios: consolidation, harmonization, and central data management. The term central data management has led a lot of people to false ideas about the scenario. Based on that phrasing it would seem as though the idea is to incorporate your entire attribute set in one environment, this being MDM of course. The goal would be to have one view of master data across your entire system landscape, whether it is a SAP system or not. However, many of us that have worked with MDM on a central data management project know that this is not exactly the case. The real idea is to identify a subset of attributes that you consider to be enterprise level and manage those centrally. This allows you to easily provide oversight, governance, and data standards to enforce data integrity on the attributes that are the most important to your particular business.
The concept of partner functions being enterprise level can be debated endlessly, and to make a long story short, it’s not really clear whether or not partner functions should (from a functional perspective) be managed in MDM. The reasons to include it are clear. Many businesses that develop a workflow process around the creation of vendors or customers want to have a separate flow depending on the function associated. However, there are some severe technical restraints to building partner functions into your MDM data model which should definitely be considered before you embark down that road.
Let’s use customer data as an example. In R/3 the partner functions are nested inside the sales data of a customer record. If you relate this to an IDoc you can visualize the structure of tables where KNVM represents the sales data segment, and KNVP is the partner function segment which is nested under KNVM. Consequently, when you extend a customer to a new sales area, new partner functions are generated. This is done because you may want to maintain different partner functions based on the sales area of the customer. For all intents and purposes, to model this in MDM you would use a qualified lookup table. Unfortunately, MDM doesn’t support qualified lookup tables being nested within other qualified lookup tables. In other words, if you were to model sales area in MDM you would need to use a qualified lookup table. Then to correctly model partner functions, you would need to build another qualified lookup table which serves as a qualifier to your sales area qualified lookup table. This may sound tricky, but it’s pretty straightforward, unfortunately it’s not supported by the current version of MDM. I’ve heard rumors that this will be supported in future versions, but for the meantime we have to assume that it won’t be and look at what we have to work with in the current version.
Because we are faced with this limitation it forces us to look at alternative options to modeling partner functions in MDM. Let’s say, for example, you decided to use a qualified lookup table to represent your partner functions, and linked it to the main table. You would need to have a non-qualifier which links to the sales organization. Similarly, your sales area would also need a non-qualifier which links to the sales organizations. This is the only way that you can maintain a link between the sales area and the associated partner functions. It may look something like this:
The first problem (and most obvious) that you will encounter is during syndication. In most cases you will have multiple partner functions for each sales area, which may look like this:
When you attempt to syndicate the records out, if you are using the standard IDoc formats provided by SAP (in this case DEBMDM), you will be mapping the sales area to E1KNVVM, and partner functions to E1KNVPM.
What will ultimately happen in this case is the partner functions will all get syndicated regardless of what sales org it’s associated with. So your XML file will end up incorrectly having multiple instances of the same function for each sales area:
To solve this problem you first need to map the sales org to a field within the partner function segment. Like this:
Next you need to employ some logic in XI which can strip out the extra partner functions that aren’t associated with a particular sales area. In other words, lets say you have a customer which is extended to sales org 5, and for that sales org you have 4 partner functions: a, b, c, and d. You also extend to sales org 10, and for that sales org you have 4 partner functions: e, f, g, and h. You syndication file will have 5(a,b,c,d,e,f,g,h), 10(a,b,c,d,e,f,g,h). What you want is 5(a,b,c,d), 10(e,f,g,h). XI can perform this logic for you such as the following:
Basically, you are saying “don’t create the partner function unless it’s associated with the same sales org as the sales area”. It’s not the prettiest solution, but at least it works.
Unfortunately, there are more complex issues at hand. It’s standard configuration in ECC to allow partner functions to be automatically generated whenever you extend a customer to a new sales area. Replicating this functionality is incredibly difficult in MDM. Assignments can’t be used to create new records; similarly they can’t be used to create qualified links. For this reason, it’s impossible to create the default partner functions with standard functionality of the data manager. I’ve explored as all options using workflows, assignments, and any other thing I could think of. This means you basically have to employ a custom solution of some sort. One way to do this would be via the Java API, but I’ve never attempted to do this. The reason you must make sure to generate the partner functions automatically is because if you don’t the IDoc will fail when it is sent to ECC. The inbound function module will attempt to process the sales area extension and when it gets to the partner functions it will blow up if the default partner functions aren’t there. This is a problem because most users won’t remember to enter the partner functions when they are creating a new record in MDM. You can enforce this with a validation, but it will be a nightmare for the user because there is no real intelligent way to relay this information to him.
A further complication exists in the fact that ECC will allow you to change the partner number, but it will validate that the partner number exists in the system before allowing you to commit the changes. In MDM there isn’t a standard way to do this. So for example, if I have a customer record extended to sales org ‘5’, and out of the four default partner functions, I want to change partner function ‘a’ such that the number is customer 000500, we can’t validate that 000500 exists in the system. This will also cause a failure when the IDoc is processed by ECC, ultimately weakening the data integrity.
In short, I think for the time being it’s safe to say that partner functions are pretty much impossible to implement perfectly in MDM. It’ll be interesting to see what developments come in future releases, but for now I don’t think the support is there without developing extensively using an API.
