SAP for Banking Blogs
Read and write blog posts showcasing innovative banking solutions and success stories powered by SAP. Discover cutting-edge insights and practical tips.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

There are multiple places where aggregates are built in Bank analyzer. We get used to the fact of building indices and aggregates at various levels and in various layers. One of the community members asked me about the usage of Source Data Aggregation (SDA)  in a particular scenario. From my perspective SDA was building materialized aggregates and I am no firm believer in materialized aggregates, especially with AFI on HANA, I would move away from it even farther. But to clarify his doubt, I started reading about SDA.


Why is SDA?

FPO is built at the granularity of the single financial product level in BA. The architecture doesn’t allow building a FPO at a more high level or in a flexible way. And all the AFI postings are posted on the basis of FPO flows. In case of products like deposits or checking accounts where nominal accounting is applicable, they do not require analytical evaluation on a single financial transaction level or complex accounting valuations.

But as already mentioned since we cannot build a FPO at a higher granularity, an aggregation object is built based on which a FPO is created. Still we cannot afford to lose the position relevant values at a FT level due to aggregation. It should be possible to move values from BT's for a FT from one aggregation object to another.  Hence as an initial step, the position generation transaction generates positions and updates the position object in the SDL. This way, positions are still maintained on single contract level andno aggregated positions exist. Financial transactions are grouped in to subgroup on a user defined granularity. BT’s and accruals belonging to each subgroup are aggregated too. When the AFI process is run, it is runs on aggregatedobject level. This reduces the run-time and the produced data volume of the accounting scenario processes. Also less posting documents are generated by posting only aggregated business transactions.

SDA is a complex process.Especially when you read the documentation and understand that you have to execute a dozen additional transactions to achieve source data aggregation, it might be tempting to look for aggregates in other layers. After all, even in SDA,it builds additional indexes for aggregated FT, BT and accruals. Also it creates positions at a FT level in SDL. SDA is also generating a lot of additional data. Why not look for other features for aggregating the data?


Where else do we find aggregates?


Pre-aggregation:

Many business processes require aggregated results. To improve the response time, pre-aggregates are built and persisted at RDL. If a pre-aggregate is already run earlier, the final aggregate is built by reading entries from the pre-aggregate plus the delta on the underlying data.

G/L Connector:

To support the thin G/L and fat sub ledger concept, the sub ledger documents from the RDL are aggregated at auser defined level and the results are posted to G/L.


Aggregated Transactions:

It combines the accounting documents from the flow results in the RDL as part of balance processing and supplies the results to BI. It serves as a basis for period end reporting and consolidation.


Let me conclude.As you can see above, all the aggregates are built on top of RDL results and each with a specific purpose either as a basis for financial statement items or for BI reconciliation. SDA tries to build aggregates at SDL layer and thus reduces the number of postings in RDL. It still allows the positions to be created at FT level in SDL and thus allowing drill down to the granularity of the FT.

Since the main aim of SDA is to reduce data volume, key figures such as aggregation ratio and aggregation factor have to be considered. The aggregation levels have to be configured so as to get a high number of objects that can be aggregated. In the end, when there see fewer postings in RDL, it further improves the performance aspect making it easier to consume and subsequent analytics will be accelerated. 

If you are an end user checking the result data in RDL , you would probably love SDA. As a developer we might not love it as much specially in case you need to correct inconsistencies in SDA.And I absolutely love the way SDA tries to use and exploit the functionalities in BA w.r.t. storing the positions in SDL, position class concept, usage of segmentation service etc.


What are your views about SDA?