SAP BPC EMBEDDED 10.1: Data Flow with in the embedded system and its influence from Characteristic relationship
Understand the basic character of the data behavior when drawn on to the report, when transferred between cubes and when inserted using Input schedules.
In BPC 10.1 Embedded the data is stored in the BI info-providers and is directly fed into the BPC reports with the help of Bex Queries, unlike in the other versions of BPC where the data is stored in a separate name space provided for BPC. Accordingly BPC Embedded 10.1 opens up the scope to use Business explorer along with the characteristic derivation. The new concept of characteristic derivation combined with Bex and BPC reporting has its own behavior and this document has attempted to understand the impact on data flows.
We use characteristic relationships to link characteristics that have similar content. You can use characteristic relationships to define rules to check permitted combinations of characteristic values for real-time InfoCubes. You can also define rules for the system to use to derive values from one characteristic for another characteristic. This is useful, for example, if you want the derivable characteristics to be available for further analysis. To illustrate I have taken scenarios from real life project implementation to understand the how the data looks in the source and how it comes up on the other side.
We can analyse the char relationship from the following view points
1) When data is sent from Input schedule to Cube
2) When data is drawn into the reports from Cube
3) When data is transferred between cubes
Data sent from Input schedule to Cube:
When the data is sent from a query to the cube, and the query is built on an aggregation which has few info objects, then the data in other info objects will be derived if a char relationship is established between them.
For example: Please find below that some data was submitted through a input schedule and please observe that there is no FERC Account, PCAT, Company code and Refund code in the aggregation.
Please find below that in RSPLAN we have established relationship between Order number and company code, Plan category, refund code, and FERC account.
We can see from the below data that the data in FERC account Company code, PCAT and Refund code is automatically derived.
On the other hand if we have all the info object in the aggregation and also the characteristic relationship is established then the data will get validated, when the data is sent to the cube and only the right combination will be allowed to be written into the cube. Please find from the below screen shot the invalid combination is rejected and an error is thrown.
Data drawn into the reports from Cube
When we do not have Info object in the aggregation then the data in the cube sums up when pulled up in a report as per the following example:
Data in the CUBE: Please find below where we can see that there are different internal orders (000300482502, 000300482503) at the line item level
Please find below that the aggregation does not have order number
Data in the Report: Please observe that all the data is pulled up into the report and the query from the above aggregation sums up the internal orders
Data transferred between cubes:
For the data to be transferred in between cubes then we need to build an aggregation on the multi provider which will have the respective cubes in it. On this aggregation we need to build a planning function giving from and to as the respective cubes.
When we are transferring the data from one cube to another on a specific aggregation then the data will get derived for the info object which is not present in the aggregation. If it should not derive then we need to de activate the char relationship in the receiving cube
For Example : We have the following
If we have relationship between Internal order and budget code then the data will be derived into receiving cube for budget code
If there is no relationship then the data in budget code will not be transferred
2. The data will be automatically validated in the receiving cube and only such data will be imported. Other non-validated data will be rejected.
3. When transferring data from one cube to another and the data is not to be derived or validated then we need to deactivate the char relationship using a program as below, deactivation and activation needs to be executed before and after the copy function respectively
Logic for the program is as below:
Function to de activate characteristic relationship in a cube.
Function to activate characteristic relationship in a cube.
4. The data will not be transferred to the cube if the sending cube has an info object which is not there in receiving cube. If we will have to send such data then the aggregation should not include such info object.
5. When the data is copied from one cube to another then the existing data in the receiving cube will be over written.
Gnaneesh Reddy, a Senior Business Consultant at PwC SDC – India. He is qualified chartered accountant, certified BPC 10 & holds a diploma in IFRS professional with experience in diverse roles in Accounting and SAP BPC. Further he has hands on experience in Auditing & Accounting including Auditing, Finalization of Accounts, Investigations & Income Tax Consulting. He has an overall experience of 6 years in the IT industry spanning design, development, testing and support of system/business applications on client/server and multi-tiered architecture models using SAP BPC technology.
SATYA TEJA MOVVA
Satya Teja Movva, a Senior Software Engineer with PricewaterhouseCoopers SDC - India is a SAP professional in BI. He holds a Bachelors degree in Engineering and has five years and five months of experience in SAP Business Intelligence Warehousing. He has experience of working on different versions of SAP BO XIR3, SAP BI 4.0, SP 4.1. As a SAP BO consultant he has executed five projects that include end-to-end implementation, enhancement and support projects. He has good work experience in ETL and expertise in BO Web Intelligence, and SAP Lumira. He has implemented reporting on SAP Bex queries, SAP HANA calculation views and other relational sources.
Vipin Jain, a Senior Business Consultant at PwC SDC – India. He is qualified chartered accountant with Dimpoma in Information Systems Audit and certifications in SAP HANA 100, BPC 10.0 and PMP. He has more than 13 years of experience in Global Consolidation, Planning, Business Analysis and Project Execution. He has comprehensive knowledge of key business processes underlying complex planning scenarios, IAS, IFRS, US GAAPs. He has an overall experience of 9 years in the IT industry spanning design, configuration, development, enhancements, roll outs, testing and support of business applications on multi-tiered architecture models using SAP Technology.