Hierarchy on navigational attribute decreased query performance

A multiprovider, based upon 5 different infoproviders and 2 infoobjects, was causing a performance drain whenever a query was executed.
Every query, based upon this multiprovider, contained a hierarchy on a navigational attribute of an infoobject.
Eg. Infoobject A --> navigational attribute B --> Hierarchy C.
To make sure that the hierarchy was displayed correctly, also infoobject B was added to the multiprovider, eventhough this had no added value (as no "fact" data was to be displayed which "belongs" to infoobject B)
Infoobject B (IOB in the picture below) is a navigational attribute of 0MATERIAL

Infoobject B (IOB) has been added to the multiprovider and was identified (assigned) via the checkbox.
After the checkbox was "un-ticked" (as seen in the picture above; red arrow) and thus infoobject B was no longer part of the identification, the query performance increased.
Conclusion: Know what you're doing when inserting infoobjects in a multiprovider as mis-usage can drastically decrease performance!

Making an added function module (to a function group) visible in SE80

After creating an (additional) function module within a function group, it wasn't visible within SE80 after it was transported to another BW system.
When displaying the function group, via transaction SE80 --> Function Group, the newly created function module WAS NOT visible, even though the import/transport ended without errors.
The trick, to make all function modules visible within the function group, is to update the navigation index as shown in the screen-grab below:

Create or maintain currency translation types

A currency translation type is a combination of different parameters that establish how the exchange rate for the translation is determined. Currency translation types can be created or maintained via transaction RSCUR
For more info regarding currency translation types, click here

Find out if R/3 field is already transferred to BW

When executing a fit/gap analysis (are all necessary R/3 fields already extracted and transferred to BW), table RSOLTPSOURCEFIE can be used.
Within the selection screen you can enter, for example, R/3 field MATNR if you want to know in which datasources MATNR is used.

The screenshot below shows the overview of all datasources which use R/3 field MATNR:

To see, per datasource/transfer structure, to which infoobject the R/3 field is mapped, table RSTSFIELD can be viewed.
In the screengrab below you can see that R/3 field MATNR is mapped to infoobject 0MATERIAL within several transferstructures/datasources.

Prevent automatic migration of 3.x queries to version 7.0

Once you've migrated a 3.x query to version 7.0, you can't alter it anymore within a 3.x query designer, as a 7.0 query is not downward compatible.
(Even though you can still execute a migrated 7.0 query with a 3.x BEx Analyzer/Query designer, you aren't able to alter it anymore)
OSS Note 962530 (NW04s: How to restrict access to Query Designer 2004s) explains the necessary steps to take to prevent unwanted migration of queries.