PRPS-USR06 decimal notation problem

After enhancing the datasource 0WBS_ELEMT_ATTR with the two additional user fields  USR06 (UF value 1 WBS) and USE06 (UF unit value 1 WBS) I encountered some strange behaviour.

This began when I extracted data from the ECC source system and I saw that the notation of the user value (after DSO activation) was different from the value filled in by the end user. SAP note 1646349 summarizes this problem. It states that the USR06 and USR07 fields of the PRPS table are always stored with 3 decimals places.
SAP Knowledge Base Article - 1646349 - Decimal Shift in User Currency Fields
For this problem I have developed some lines of ABAP code. The logic uses the TCURX table to calculate how many places decimal must shift for each user value known in the RESULT_PACKAGE. Use this ABAP code inside a transformation to get the same user value as maintained in ECC.

Quickly find queries which use specific InfoObjects

When it comes to deleting InfoObjects from SAP BW it is necessary that these are not used anymore by other objects in the system. The standard where-used functionality could supply sufficient insight. However the standard where-used functionality is not always accurate when a person wants to know in which SAP BW queries an InfoObject is used. For this specific case you have the ability to use one of the following two function modules.

Technical name Type

By filling in the right parameters the function module delivers a table of queries using the specified characteristic or key figure.

The power of navigational attributes

Remember the time when all additional functionality had to be programmed manually in SAP BW? With SAP Business Warehouse 7.3 (and above) many of custom ABAP code could be replaced with standard functionality. One real-life example is the retrieval of a navigational attribute from a navigational attribute.

In the good old days this could be done by using custom ABAP code. With SAP BW 7.3 you can now easily achieve the same result by using navigational attributes. By activating a navigational attribute in the source InfoProvider (like a DataStore Object) you will get the possibility to use the attribute as a source in a transformation.
Using navigational attributes instead of ABAP
With this in mind you now have the capability to use the default “read from master data”-option when modelling a transformation. This makes it possible to read a navigational attribute from a navigational attribute.

The activation of navigational attributes also enables you to use these in a DTP or start routine. This might come in handy when filtering out invalid records.
Using navigational attributes as DTP filter option

SAP Business Warehouse extractor and table analyzer

Building up a new dataflow can be very time-consuming, mainly when there is no data acquisition layer to extract data from. Setting up a proper data acquisition layer means considering which fields to extract towards the data warehouse system. Since not all fields of a table used in the source system it is advisable to first analyze which fields are useful. Extracting all fields results in empty and unused objects in the Data Warehouse system, which technically results in a bigger database.

In order to make everybody’s life easier I created the ABAP program “SAP Business Warehouse extractor and table analyzer”. This program can be used to analyze Business Content extractors (like 2LIS structures) or SAP tables.
SAP Business Warehouse extractor and table analyzer

Verify dimension sizes of InfoCubes

Maybe you are one of the lucky few who is currently working with BW on HANA and do not have to model InfoCubes anymore (from a performance perspective). But for those who still need to do this, ABAP program SAP_INFOCUBE_DESIGN could help you verify how well your InfoCubes are modelled in SAP Business Warehouse. This program collects data for every InfoCube in the BW system and counts the records available in the related dimension tables and fact table. The program then checks the ratio between the number of records in the dimension tables against the number of records in the fact table.
A ratio between 10% and 20% is considered as high cardinality and therefore indicated in red. In most cases you should avoid dimension tables larger than 10%. Of course this it all depends on how frequent the data is used in the mentioned dimension table. If possible use line item dimensions instead!
Note: The data which is used for this analysis comes from BW statistics, so be sure that if you want to analyze a specific InfoCube, statistics are created for it.