Modelling your e2e process using Result Model Tabl...

JoanJabagat · ‎2020 Dec 15

The functions of SAP Profitability and Performance Management uses Building Blocks that interconnect functions to create scenarios and structure of a business model that fulfill end to end processes depending on the requirements of a company.

In general, Function Building Blocks are composed of the following:

Fig1. Function Building Blocks (Header, Input, Lookup, Signature, Rules and Checks)

Availability of these Building Blocks such as the Header depends on the functionality of a function. The Header can be seen at the top part of a function and has four (4) standard settings such as Result Handling, Suppress Initial Results, Includes Original Input Data and Result Model Table.

In this blog post, I will be focusing on scenarios with a configured Result Model Table that has a wider impact on the function’s result once used.

Fig2. Result Model Table

Earlier this year 2020, one of the enhancements implemented in SAP Profitability and Performance Management was with the Result Model Table. As suggested by its given name, an activated Model Table function (Environment type) is necessary to use this functionality. The assigned Model Table will serve as the storage of results which can be further used as an input of another function or functions in their modeling environment. You may use and find the Result Model Table visible in the following:

1.Processing Functions

Allocation

Calculation

Conversion

Derivation

Flow Modeling

Funds Transfer Pricing

Join

Transfer Structure

Valuation

View

2. Analytics Function

Machine Learning

So, some of you might be asking the question: How should I use the Result Model Table in modeling my end-to-end process and affect its result? In the succeeding section, I will be discussing how to use this setting and provide three (3) scenarios that will help you understand its functionality.

Note: above all the given functions, I have chosen View to illustrate the behavior of Result Model Table all throughout the three (3) scenarios. Also in the next paragraphs, I will be using the abbreviation ‘RMT’ as a short-term of Result Model Table for easier discussion and to refrain altering the results of each scenario, I select first the Delete Data of the reoccurring functions before moving on to the next example.

1.Function without vs with RMT

1a.View function without RMT

1b.View function with RMT

2.Function with RMT used as an Input function (cont. of 1b)

2a.Set as Sub-Function

2b.Set as Executable

3.Two View functions with the same RMT

Let us now proceed on the given scenarios.

1.Function without and with RMT

1a.View Function without RMT

Fig 3. Model table (INPUT) used as Input data of the View function

Fig 4. View function (VIEW) configuration WITHOUT RMT setup

Fig 5. Result of the View function shows all four (4) fields from the Input data after selecting the Run button

In scenario 1a, I have prepared a single Model Table that consist of four (4) environment fields used as an Input data of the View function. As highlighted above, the RMT doesn’t have any configuration, hence its functionality won’t kick-in. By selecting the Run button, the result of the View function will show all fields since it is set as Implicit type and read data coming from the Input function.

1b.View Function with Result Model Table

Fig 6. Configuration of the Result Model Table (RMT) limited to three (3) fields

Fig 7. View function (VIEW) configuration WITH RMT setup

Fig 8. Result of the RMT shows the configured fields (Account, Amount and Team) after selecting the Run button

While for scenario 1b, the View function configuration used the same Input function of scenario 1a but maintained a RMT that is limited to three (3) environment fields (Account, Amount and Team). After selecting the Run button, the result of the View logic is stored in the RMT and at the same time considered the configured fields of RMT.

As a conclusion for scenario 1:

The normal behavior will use only the View function logic hence its result shows all four (4) fields in the Input function.

While when a View function use the functionality of RMT, result’s structure will store data records to the RMT and respect the configured fields.

So now we are aware how the RMT affects the result of a function. Another question came up, can we use the function with RMT using both Processing Type (Sub-Function and Executable) as an Input of another function and how it will influence the result and stored data of the RMT? Before moving on to our scenario 2, take note of the View function in 1b as it will be used further to illustrate these behaviors.

2.Function with RMT used as an Input function (cont. of 1b)

2a.Set as Sub-Function

Fig 9. Configuration of the View function with the result of scenario 1b as an Input function (VIEW)

Fig10. Sub-Function as the Default configuration of Input function(VIEW)

Fig 11. Result of the View function (VI2A) shows the configured fields after selecting the Run button

Fig 12. Result of RMT shows no record

Since this scenario has been setup the same way as with the previous examples, aside from the added complexity of using 1b as an input function, the result should be the same with respect to processing. The major difference that is evident though is the behavior with respect to populating the RMT.

As 2a focuses on an input function which was set as Sub-Function (processing type), you will see in Fig.12 that the RMT has not been populated. This is due to a reason that population or storing of data to RMT only happens when the function with RMT is executed manually.

But what if my function is just an interim function of the whole chain? How can then I be able to populate my RMT? Let me give you another example on how you can do it via scenario 2b.

2b.Set as Executable

Fig 13. Input function (VIEW) set as ‘Executable’

Fig 14. Result of the View function (VI2B) shows the configured fields of RMT after selecting the Run button

Fig 15. Result of the RMT shows the configured fields (Account, Amount and Team)

In this scenario, configuration is still the same with scenario 2a but the Processing type of the Input function is set to ‘Executable’. After selecting the Run button, the Input function was forcedly executed and as a result the configured fields with three (3) records were then stored in the RMT.

As a conclusion for scenario 2:

If the function is set as ‘Sub-function’, unless manually executed, results will not be stored in the RMT.

While setting it as ‘Executable’, the result of the interim functions with RMT will be stored or populated in the assigned RMT.

Since we now know that Processing type can affect the population of data in the RMT for functions that are not being “run” manually, how about doing the situation more complex by using two functions configured to have the same RMT. Which of these data records will be successfully written in the RMT? Will they conflict each other? Let me answer that before concluding this blog post, as my final Scenario.

3.Two View functions with the same Result Model Table

Fig16. Two Model table (INP1 and INP2) used as Input data of the View functions

Fig17. Two View functions (View-1 and View-2) configuration with the same Result Model Table

Fig 18. Result of the RMT shows data from the Input and limited to the configured fields after selecting the Run button

In this example, I have created two (2) Model Tables with similar fields but differ in data records. Just by focusing on the Account field, you will notice that Input1 has a ‘LOCALIZE’ account while Input2 has an ‘INTERNATIONAL’ account. Take note of these unique records as they will be reflected in RMT as we move along with the example.

As for the configuration of the View functions, it is parallel to scenario 1b which has defined and assigned the same RMT for both functions. After selecting the Run button, as expected the result of both View functions written directly in the RMT that has three (3) limited fields.

So, you might be asking the question, how will it react if I change the data of one input and select again the Run button of the View function? Will the result add the new data, or will it change the old data?

Therefore, I have changed the data of Input1(INP1) from ‘LOCALIZE’ to ‘LOCAL’ account as its new record.

Fig 19. Updated the data of Input 1 to Local Account

After selecting the Run button, as expected the result of the RMT changed the old data (LOCALIZE account) and replaced by the new data (LOCAL account) from the Input1, but the INTERNATIONAL data written by View-2 remained untouched.

Fig 20. Result of RMT after updating the Input 1 then selecting the Run button of View function 1

As a conclusion for scenario 3:

It is possible to assign a single model table numerous times to different functions with RMT. The RMT logic is sophisticated enough to distinguish and only update data records coming from the said function and retain the ones produced or written by other functions.

I hope the given 3 scenarios were able to show you the capabilities of the Result Model Table once strategically used in modeling your end-to-end process.

If you have SAP Profitability and Performance Management related questions, you can ask them through https://answers.sap.com/questions/ask.html and use primary tag: SAP Profitability and Performance Management before submitting.

You can also read other SAP Profitability and Performance Management blog posts via https://community.sap.com/topics/profitability-and-performance-management .

Thank you for reading and keep looking forward to our next blog post!