BW Tables are in Package $TMP ?

[Former Member]

Can anyone tell me please, why are the BW Tables in packege $TMP ?

For example I have an Infoobject 0PROFIT_CTR in a proper Package but

the Masterdata tables of this Infoobject /BI0/SPROFIT_CTR, /BI0/PPROFIT_CTR are in Package $TMP ?

Is there anything about this issue in SAP online help ?

Cheers.

[former_member184494 · Accepted solution]

the reason is that when you transport your infoobjects - the master data tables get created in the system and they are not transported...

One of the reasons for this is to make sure that master data is consistent across...

for example :

If you have changed an infoobject length in dev ( where you have deleted master data and you are able to change the same ) and you want to transport the same - you will have to transport only the definitions since it makes sure that the backend tables are checked and changed in the target system instead of them being transported over.

This is because IOBJ gets activated on transport ( check your transport logs ) this would mean that the objects get created / changed in the target system and not transported.

Transport has two components ( DDIC changes and activation ...) but then the /BIC and /BI0 tables are SAp defined in a namespace protected by SAP against changes by developers ( you cannot change these tables directly through SE11 ) - any reason you want to change them locally...?

[Former Member · Accepted solution]

Hi Arun,

the reason is,

Customer is going to merge their 4 companies.

Let say, Comp.Code 21, 22, 23, 24 -> Comp.Code 20

And profit centers are defined like this below

Comp.code-Object number

For example 0022-55555 -> it should be after merge 0020-5555.

They donu2019t want to see old profit center numbers in selection menu of reports.

And reasonably they want to keep historical data in Infocubes and DSOs.

What kind of solution would you suggest here ?

We thougt that we should change the masterdata table of Profit Center with this Logic

Profit Centers beginning with 0021, 22, 23, 24 -> should be changed with beginning 0020

We can not simply delete some Profit centers as long as they are in Infocubes or DSOs.

We thought for transaction data, we should change the dimension tables (which includes com_code)for Infocubes and DSO tables for the active data.

I just want to hear your suggestionsu2026

Thanks.

[former_member184494 · Accepted solution]

interesting situation...

What you could do is :

1. Restamp historical data

But then it might become too laborious and time consuming to restamp , validate et alll

If you are interested in the selection screen alone ... then you could have a customer exit variable with i_step=1 which filters the values displayed only to the new values and then have another customer exit without being ready for input that would translate the values to the required ones ...

for example if your variable for user entry is var1 then var2 would be another customer exit that reads the values in var1 and then ADDS the older profit centers to the list ( depending on the period chosen ) or if you want to display only the new company code information - then just have a simple customer exit variable with ready for input and filter the values using the i_step=1 option.

But then this is usually done for lesser number of values - I have not see usage of i_step=1 for a large set of values ( 300 plus ) but then definitely worth a try...

one more question was : how is this related to the $TMP question you had ...?

[Former Member · Accepted solution]

Hi Arun,

thanks for your quick reply.

Yes over customer exit it should be possible but they also want to analyze thei historical data with new Profit center numbers and comp.codes.

So we should change the existing transaction data.

Why i asked the $TMP question:

I noticed during my analysis that the SIDs are different from one system to another system.

So if i want to change the dimension table of a cube or SID tables of masterdata, i shold apply different rules for each system .

Prf.Center 0022-5555 has SID 204 in Developmetn system and 708 in production system.

And in Dimension tables there are only Dimensiom Key and SIDs. There is no Profirt Center at all.

Cheers.

[former_member184494 · Accepted solution]

if you are restating your historical data with the new codes then once this process is done - you should not have any transaction data for the older profit center codes .

Once the restatement is done - go to RSRV and delete unused entries in the dimension tables and you should not be able to see the older profit centers in the search help....

As for the SIDs - the SIDs are assigned from a common pool in SNRO while activation happens - the SIDs will not be the same in different systems...

Also the Dimension tables will have only SIDs and will not have the actual values - this is a property of the extended star schema...

Edited by: Arun Varadarajan on May 19, 2010 9:58 PM

[Former Member · Accepted solution]

can you please tell me how can you restate your historical data in an Infocube with new Company codes and Profit Centers

existing data in Infocube

Per: 001.2009 Company: 0022 Prctr: 0022-55555 Sales: 10.000$

What they want to see after merge of the companies

Per: 001.2009 Company: 0020 Prctr: 0020-55555 Sales: 10.000$

Infocube have Fact table and dimension tables which are connected to masterdata tables.

I thougt

1. Possible solution is changing the data in Dimension tables (so i need to know SID numbers of Profitcenters)

2. possible solution, i will create a new cube (exactly with a same structure). Then i can load the data 1:1 from CUBEold to CUBEnew.

Then i will load the data from CUBEnew to CUBEold with some logic.I will write some coding in single routines in update rules.

Then i will delete the old requests from cube...

Or can you suggest any better or easier solution ?

Thanks.

[former_member184494 · Accepted solution]

I am not sure if there is any easier solution that reloading the data with the new codes.... this way the data will be consistent since the changes are done through a reload as opposed to changing tables directly....

Also if you change the SIDs in the Dim Tables using routines - then you risk corrupting the indices and hence the data...

The cleanest way ( but still time consuming ) to do this si to reload the data and then delete the master data entries for the older entries.... and also make sure you drop the unused dimension entries in the cube to make sure that all old entries are removed...

[Former Member · Accepted solution]

Arun, thanks for your comments and engagement...

[Former Member]

Hi,

These tables are editable and transportable, hence have $TMP.

-Vikram

[former_member186445]

why is this an issue?

[Former Member]

I mean, why those BW tables are in Package $TMP ?

[former_member186445]

why? i suppose SAP would say : works as designed...

anyway, as far as i understand...when you transport your object to eg qualtiy all these tables are generated in the system it self at activation of the object...hence they don't need to be transported...the same is true for F/E table, changelog table and so on...all these tables are generated in the system when the object they belong to is activated at import...

so, don't let this keep you awake at night...make sure you have the necessary objects in your transport and all the necessary structures will generated.

M.