Skip to Content

Calculate with Attributes – Comparison Of Two Methods

In some scenarios we need to calculate key figures on BEx report by attributes to the master data. Let’s say, product price is one attribute for master data ZPRODUCT and we need this to calculate sales revenue. There are two ways to achieve this and I will compare the difference here. 1,The first method is to use the Multi Provider which simulates Info Object as a data target. So,first of all,you should insert the Info Object,which is with the attribute you need,as a data target under the info area. Then,create a Multi Provider and pick this IO as a component.Select the attribute as key figure for this Multi Provider. After this, you can use the attribute as a key figure directly in Query Designer.It’s a simple way and easy to understand. However, please notice the following things when using this method:  (1), Since this method is done at modeling level, the selection criteria in Query could affect the result. In most situations, we have some restrictions in Filter of the query like Company code / Year & Month and etc. But for most Info Objects with attributes we need to calculate,they don’t have the above attributes that Filer needs. Thus, with this kind of Filter in query, you won’t get the attributes as expected due to the Multi Provider’s data selection.  (2),If you want to avoid this problem, of course we can use the constant selection on the Info Object in Query Designer. But this time another problem occurs: If you are using authority object in Filter and also applying the constant selection of this Info Object on attribute key figure, you will encounter an authority error.The conflict of authority check and constant selection of the Info Object is the point.  I don’t have good solution for problem 2 yet and that’s why I tried to find another workaround:   2,Check this document first: It explains the method in detail.Nothing need to be added in your basic cube or Multi Provider, the only thing need to change is a new variant using replacement path in Query Designer. Still, if necessary, don’t forget to use NODIM() function on the attribute key figure.  Now there is no need to worry about the data selection and authority check on the Info Object.  Unfortunately I met some weird problem using this method. Sometimes the replacement path of variant doesn’t work. If only you remove it from the formula and drag it back again, everything is OK. In addition, the result page would report warning like not all the attribute key figures could be properly calculated while actually all the numbers are correctly on the page at that time.   In conclusion, if the data selection of query is simple and no authority check is not needed(especially this on), the first method is easy to use; if not, the second one is a must.
You must be Logged on to comment or reply to a post.
  • Hey there,

    You have addressed a very common problem. I had this in on of my projects and I remember spending some time over it. I would like to understand your approach 2. However, I am not able to open the document I need to read for understanding approach 2. Can you please send that document to me ? My email is



  • Hi,

    both scenarios are based on nice ideas. Theoretically do both of them work, the only clue is in detail.

    1-> what to do with configurable materials? (they have the same material number, but another prices)

    2-> how is it about time dependance of material and its’ price? it is not possible to store more prices to one material based on time in a sap standard scenario, isn’t it?

    3-> what about the performance impact of such a scenario?

    4-> why not to save information such a price with amount?