cancel
Showing results for 
Search instead for 
Did you mean: 

Adding time dependency to non-time dependent content extractors

Former Member
0 Kudos

Hello Everyone,

I have a need to report the track the "historical truth" in an ODS based on the material group attribute of material. Below is a simple example of a more complex problem (see the example below for details of the reporting requirement).

The current solution is to load into the ODS the Material Group along with the Material at the time we load the transaction data. This works fine for the users as we load the master and transaction data nightly, so the correct material group is posted into the ODS.

The problem is that the material attribute load (and the R/3 tables themselves) are not time dependent. My concern with tracking this information in the ODS only is that if we have to re-initialize the transaction data into the ODS from R/3 directly at some point in the future (for example we need a new field to be pulled from R/3), we would lose this historical view as the material group would be posted to the ODS based on the values that exist at the time of re-loading, not based on the values valid at the time of original posting.

It seems that what I need to do is track the time dependency of the relationship between Material and Material Group in BW such that if in future we need to re-load transaction data, we would be able to get the material group from the time dependent master data table using some key date.

My questions are:

1. Is this something that we should actually worry about? My thinking is that this could be a real problem down the road if we don't solve it now.

2. Is there some standard way to resolve this issue? My thinking is that I will have to make material group a time dependent attribute of material, then I will have to add several routines to the transfer rule so that during the loading I can adjust the time dependency only if the material group has changed since the last time the material was loaded.

3. If I introduce time-dependent master data, are there any concerns I should expect? Right now, my only worry is that the table size will obviously be bigger as we are tracking changes, but other than that? To avoid confusion, I would never include in an infoProvider the navigational attribute material group of material as well as the "baked" material group that is in the infoProvider directly (unless they have different names). Anything else?

<b>Reporting Requirements:</b>

Transaction Data:

Material Amount Period

A 100 01.2006

B 200 01.2006

A 300 02.2006

B 300 02.2006

Master Data:

Material Material Group Period

A 88 01.2006

B 99 01.2006

A 88 02.2006

B 88 (changed) 02.2006

Reporting Requirement

Material Group Amount01.2006 Amount 02.2006

88 100 600

99 200 0

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Kevin,

your analysis is exactly right. If you want to track the historical truth you need to switch the Material Group to time-dependent. You should set the 0DATEFROM to SY-DATUM (current date) and the 0DATETO to 31.12.9999 to get the correct data. Unfortunately you're right and you need to look for changes manually to prevent getting thousands of lines that are not changed.

You also need to add the InfoObject that you use for determining the key date in the update rules´to your ODS.

Or you decide to not add new fields to your ODS

Best regards

Dirk