Currently Being Moderated

It goes without saying that performance is a major concern in all parts of SAP BI.  Ever since BI was first delivered in release 1.2b, one of the biggest areas of focus has been on how to continually tune the system.  Performance tuning is a holistic concept and involves everything from query analysis down to the extraction of the original source data.

Performance tuning during extraction is a bit more difficult if only because there are fewer options and tools available in order to control the speed at which the datasources process.  This is particularly true for those datasources that don't have any enhancements...  i.e., there is no code to optimize because it all belongs to SAP.  Tuning a datasource also has the added challenge in that datasources from different functional areas have different methods of analyzing the source data.  So just because you're familiar with 0PM_OM_OPA_1 doesn't mean that you'll be as quick to trouble shoot issues with 0HR_PY_1.

In the area of Asset Accounting (FI-AA) there are two transactional datasources that tend to yield massive amounts of data due to the structure of the underlying tables.  This usually surprises people if only because they tend to have such low expectations for this module.  As an example, the records that are extracted for a single 2 line journal entry to just one asset will yield 2 entries in the 0FI_GL_4 datasource, but would generate over 40 entries in the corresponding FI-AA datasource 0FI_AA_11 (assuming a typical number of depreciation areas).  See the problem?

The other transactional datasource 0FI_AA_12 does not suffer from the same degree of data explosion that the _11 datasource does but stills pulls a significant amount of data.  Unlike the GL or the other FI subledgers, FI-AA has the added burden of having to forecast amounts (depreciation or interest) for future periods or years.  This is in addition to tracking all of the line items as well, which FI-AA does in its own line item table in addition to what is in the GL (BSEG).


The BWFIAASIM Parameter 

The 0FI_AA_12 datasource extracts the asset posted depreciation values by fiscal period and simulates the future periods' depreciation as well.  This is a great feature because it is a de facto requirement in the capital management area to report on future depreciation in addition to current or past values.  Besides, the SAP ERP reports already do this in order to support annual end-of-the-year reporting so it's important for BI to be consistent with that approach. 

For the _12 datasource, SAP has delivered a parameter that is referenced during the extraction of the data and influences the amount of the data that is sent to BI.

As an example, here is an asset record that is correctly calculating 12 periods worth of depreciation.  As you can see, periods 1-3 have already been posted to the GL but 4-12 have not.

Asset Explorer


If I run the Extract Checker at transaction [RSA3], I'll see that 12 entries have been extracted for this particular asset.  The first three records reflect the 3 values shown above; they are posted values and no simulation is required.  But the records for periods 4-10 are simulated during extraction since they have not yet been posted and therefore don't exist in the source table.


The behavior of the datasource can be changed by defining a new value for the BWFIAASIM parameter in the BWOM_SETTINGS table.  There are three values for this parameter that influence how much data is extracted and the values themselves.


BWFIAASIM Value [0] "Simplistic Simulation" -- This is the default value and does a simple mathematical division between the amount of depreciation unposted divided by the remaining fiscal periods.

BWFIAASIM Value [1] "Exact Simulation" -- The datasource will calculate the exact amount of planned/simulated depreciation as per the depreciation engine.  All appropriate configuration is referenced as part of the simulation.

BWFIAASIM Value [2] "No Simulation" -- Only posted depreciation will be extracted.


If performance is a concern than you might want to consider changing the value to 2.  This will significantly reduce the amount of data extracted since only the posted amounts will be included in the datasource.  But this comes with a cost on the functional side since it will not be possible to perform any "go forward" reporting in BW.

The differences between options 0 and 1 are minor.  Value 1 will perform the exact same calculation as determined by the depreciation engine whereas value 0 performs a simplistic calculation; it ignores the configuration of the posting cycle, rounding rules, smoothing, et al, and simply divides the remaining unposted depreciation by the remaining fiscal periods.  The reason for this is to find a balance between providing sufficient amount of data at a sufficient cost (time).

After changing the value to 2...



... the number of entries in the extract has been reduced to only extract those values that have been posted (periods 1-3) in this case.



You can find out more information on this parameter in OSS note 614804.



Filter Blog

By author:
By date:
By tag: