Before you start loading data into SAP Spend Performance Management (SPM) it is vital to you take a moment understand the data in terms of the uniqueness of technical ids of the dimensions and think thru the implications those ids might have when the data from multiple source systems (with perhaps similar id number ranges) is being loaded. So what does that mean exactly?
Let’s take two cases and for simplicity, in both the cases, there are two source systems (S1 and S2):
1) Same technical id to mean the same master data record: Let’s say that in both the source systems there are two buyer ids “B1001”. And they actually mean the same Buyer – Jane Doe. So when buyer data from the second source system is loaded into SPM after the buyer data from the first system has been loaded, and BW overwrites the master data record for Jane Doe, that’s just fine (as long as the same information has been maintained in both systems, and if not then the sequence of load is important).
For transaction data that has references to buyer master, like invoice line “IV100” from S1 and invoice line “IV200” from S2 both have references to “B1001” (since Jane Doe was the buyer who posted both the invoices). And it is okay if measures from both the invoices get aggregated for Jane, in fact that would be the desired result.
In this case the, this object, the buyer master is source system independent.
One other way of achieving this is to explicitly flag master data from all source systems with a central (conceptual) source system built into SPM. This source system is called “Additional Files”. In this case, the source system dependence is turned on and in the Upload Properties in SPM UI, the source system is set to “Additional Files”. So then this Buyer record will look like “B1001_XY” (wheer “XY” is an example of the central source system generated within SPM).
2) Same technical id but different master data records: Now let’s take the example where both the systems have the same id number range for Cost Center because of which two Cost Center records in both the systems have the same id “CC1”, but they actually mean two different cost centers for different locations. In this case the master data records, under no condition, should be over written. Since the latest overwrite will delete the older load. Meaning that if source system S1 data gets loaded first and then data from S2, in the end, there will be only one record CC1 from S2 when in fact what’s expected is that both the records exist and get aggregated independently.
In this case, this object, Cost Center is Source System dependent and flagging it appropriately will yeild “CC1_S1” and “CC1_S2”. Which is exactly how it should work.
The mechanism of achieving the expected results in both the cases above is by ensuring that the table OPMDM_TYPES is correctly setup for all of the upload types. Thru this table, depending on the situation, the object can be made source system independent or source system dependent. If made source system dependent, the source system id will be concatenated with the technical id to make it globally unique. The column Source system dependence column is a Boolean.
All transaction data is expected to be Source System Dependent, regardless of what this flag is set to, all transaction data will be made source system dependent (this setting is ignored for transaction data).
All standardized and enriched master data, with the upload type starting with C_*, is Source System Independent. This is because it is Globally unique in nature be it Suppliers or Categories.
Out of the box, the table OPMDM_TYPES ships with some default settings for all the upload types. This flag can be then turned on or off depending on the implementation needs.