Dear,
A common issue in Bank Analyzer implementations is determining the scope of the data that we must include in the Accounting or Credit Risk Calculations.
The Primary Objects of the Source Data Layer contain the Real World Data (Transactional Data, Master Data and Market Data), like Disbursements, Business Partners Data or Interest Rate Curves.
Primary Objects are processed in the Processes and Methods Layer and the result of these calculations is stored in the Results Data Layer.
In addition to regulatory results data, customers require other non-regulatory data for internal analysis, which is related to the Credit Risk or Accounting results, but it’s available in different granularity, or it’s generated by internal models which don’t belong to the Accounting Principles.
We could be tempted to modify the standard RDL structures for storing that data, and this is not the best approach.
Some of you, with long experience in Accounting, are familiar with the concept of Special Ledgers; in those Ledgers we store accounting related data that don’t belong to the Principal Ledger.
In the Bank Analyzer RDL, we also have the possibility of creating “Special Ledgers” by using alternative Result Areas and Result Types. They have a different name but they basically follow the same principle.
Let me show you this with a practical example.
Bank Analyzer has the Profit Analyzer module for managing Process Costs (and other internal costs).
Process costs are the cost related to maintain a Financial Contract; but those costs are distributed amongst many areas of the bank; like software and hardware amortization costs, call-center costs, etc.
In SAP we have the Controlling functionality, including Cost Center Accounting, Internal Orders, Activity Based Costing, etc for managing internal costs.
But Internal Costs are available in granularities very different to the Financial Instruments Ledgers. For that reason, Profit Analyzer manages those internal costs as standard costs, with a Rate that should estimate the portion of the actual costs which belong to a specific financial contract.
Consequently we need to build controlling models and reporting capabilities for reconciling standard and actual process costs.
A good alternative is transferring the actual costs results to Special Ledgers (alternative Result Areas and Result Types) in Bank Analyzer, making them available for determining accurate Process Costs Rates that will be used in Profit Analyzer.
Building “Special Ledgers” in Bank Analyzer has many advantages:
- They’re built on top of the Financial Database assuring consistency with regulatory data and facilitating reconciliation.
- Results are fully visible by using CVPM processes that will make their data available for other Bank Analyzer processes and reporting processes.
- They increase the flexibility of the system without changing the standard delivery or contaminating standard Result Areas or Result Types with intermediate or internal reporting data which don’t belong to the regulatory Ledgers.
I’ve heard too many times that Bank Analyzer is not flexible enough, or even worse, I’ve seen modifications of the standard system breaking the consistency of the sub-ledger or damaging the business content, for fulfilling requirements that could be easily fulfilled in a more robust way by using the right approach.
There’re many ways of fulfilling a requirement, but there’s only one best way of doing it.
Looking forward to read your opinions.
K. Regards,
Ferran.
A common issue in Bank Analyzer implementations is determining the scope of the data that we must include in the Accounting or Credit Risk Calculations.
The Primary Objects of the Source Data Layer contain the Real World Data (Transactional Data, Master Data and Market Data), like Disbursements, Business Partners Data or Interest Rate Curves.
Primary Objects are processed in the Processes and Methods Layer and the result of these calculations is stored in the Results Data Layer.
In addition to regulatory results data, customers require other non-regulatory data for internal analysis, which is related to the Credit Risk or Accounting results, but it’s available in different granularity, or it’s generated by internal models which don’t belong to the Accounting Principles.
We could be tempted to modify the standard RDL structures for storing that data, and this is not the best approach.
Some of you, with long experience in Accounting, are familiar with the concept of Special Ledgers; in those Ledgers we store accounting related data that don’t belong to the Principal Ledger.
In the Bank Analyzer RDL, we also have the possibility of creating “Special Ledgers” by using alternative Result Areas and Result Types. They have a different name but they basically follow the same principle.
Let me show you this with a practical example.
Bank Analyzer has the Profit Analyzer module for managing Process Costs (and other internal costs).
Process costs are the cost related to maintain a Financial Contract; but those costs are distributed amongst many areas of the bank; like software and hardware amortization costs, call-center costs, etc.
In SAP we have the Controlling functionality, including Cost Center Accounting, Internal Orders, Activity Based Costing, etc for managing internal costs.
But Internal Costs are available in granularities very different to the Financial Instruments Ledgers. For that reason, Profit Analyzer manages those internal costs as standard costs, with a Rate that should estimate the portion of the actual costs which belong to a specific financial contract.
Consequently we need to build controlling models and reporting capabilities for reconciling standard and actual process costs.
A good alternative is transferring the actual costs results to Special Ledgers (alternative Result Areas and Result Types) in Bank Analyzer, making them available for determining accurate Process Costs Rates that will be used in Profit Analyzer.
Building “Special Ledgers” in Bank Analyzer has many advantages:
- They’re built on top of the Financial Database assuring consistency with regulatory data and facilitating reconciliation.
- Results are fully visible by using CVPM processes that will make their data available for other Bank Analyzer processes and reporting processes.
- They increase the flexibility of the system without changing the standard delivery or contaminating standard Result Areas or Result Types with intermediate or internal reporting data which don’t belong to the regulatory Ledgers.
I’ve heard too many times that Bank Analyzer is not flexible enough, or even worse, I’ve seen modifications of the standard system breaking the consistency of the sub-ledger or damaging the business content, for fulfilling requirements that could be easily fulfilled in a more robust way by using the right approach.
There’re many ways of fulfilling a requirement, but there’s only one best way of doing it.
Looking forward to read your opinions.
K. Regards,
Ferran.
No comments:
Post a Comment