Analysis Authorizations

Analysis Authorizations are used to secure individual InfoObjects during execution of queries. If we get a requirement of the form – “user should be only able to see for sales for the US companies but not for the European ones”, Analysis Authorizations are the way forward. In this post we will try to take a closer look at how these authorizations work and how to maintain them.

SAP provides the transaction RSECADMIN for working on different aspects of analysis authorizations. The different tabs of the transaction allow authorization maintenance, user assignment, transport and tracing potential errors. Analysis Authorizations are also be directly maintained through the transaction RSECAUTH. In addition to the tcodes, A person needs access to the authorization object S_RSEC to work with analysis authorizations.

RSECADMIN - Authorizations
RSECADMIN - Authorizations

The figures below shows an analysis authorization to secure 0COSTCENTER

Analysis Authorizations 1
Analysis Authorizations 1

Individual values can be maintained for 0COSTCENTER as shown below

Analysis Authorizations 2
Analysis Authorizations 2

In addition to EQ (Equals) which is used to give access to actual values as shown below, we might also use CP (Character Pattern) for wildcards or BT (Between) for ranges. Also, instead of values, individual hierarchy authorizations or user exit variables might also used for InfoObjects. In addition to actual values or hierarchies, two special characters are often used in authorizations. These are

  • Colon (:) – Colon is used to authorize access to aggregate data. For example, a person with : for 0COSTCENTER would be able to see aggregate data for all cost centers (cost center in the free characteristics section of the query) but would get an authorization error when trying to drill down on 0COSTCENTER. Colon (:) authorization is also needed for all authorization relevant characteristics which are not used in a query.
  • Hash (#) – While loading data into cubes, there might be some fields for which no values are maintained in the data source. Hash is used to authorize these undefined values as otherwise a full acces (*) would be needed for them.

If we look at the first screenshot showing the definition of the analysis authorization, we find that in addition to 0COSTCENTER, the analysis authorization uses three other characteristics. These are

  • 0TCAACTVT (Activity in Analysis Authorizations) – Default value 03(display) is sufficient for reporting. However, 02 (change) is needed for using planning functionality of BI as planning essentially allows updation of data into InfoProviders.
  • 0TCAIPROV (Authorizations for InfoProvider) – We maintain the InfoProviders for which the authorization is meant to give access. Default is *
  • 0TCAVALID (Validity of an Authorization) – Default value is * but can be used to restrict analysis authorization by validity dates.

It is imperative that all three of the above InfoObjects are part of at least one of the analysis authorizations assigned to a user but its good practice to add them to each authorization that you create.

Once created, there are two ways of assigning analysis authorizations to users.

  • Direct Assignment – Direct assignment of analysis authorizations to users is possible by following the path RSECADMIN >> User >> Assignment which calls transaction RSU01 transaction.
  • RSECADMIN - User Actions
    RSECADMIN - User Actions
  • Assignment through roles – SAP provides the authorization object S_RS_AUTH with the single field BIAUTH. Individual analysis authorization values can be maintained for this field and added to the users’ roles.

53 thoughts on “Analysis Authorizations

  • May 4, 2011 at 6:27 am
    Permalink

    This is very helpful information.

    I want to know how we handle a scenario in which a user needs to be given access to display one field in the query but another field is not included in the output.
    Will using : (colun) solve the issue.

    Thanks,
    Phani

    Reply
    • May 4, 2011 at 4:52 pm
      Permalink

      Hi Phani,

      Whether colon (:) i.e. authorization for aggregates, will work is determined by the design of your query and whether any restriction for the field is being used . I can think of a few cases below

      – Field not included in query – : authorization will work
      – Field include in query but part of the free characteristics. – : authorization will work
      – Field included in rows of the query. No restriction – : will not work. You need * to give access
      – Field included in rows of the query and the field is restricted to particular value. – : will not work. Both * and actual restricted values can be used to give access.

      Hope this helps!

      Regards,
      Aninda

      Hope this helps!

      Reply
  • June 13, 2011 at 8:35 pm
    Permalink

    Hi Aninda

    We have over 65 infoobjects which are marked as Authorization relevant. So whenever we create authorization in analysis authorization, we need individually select * for all the objects which we want complete access. Normally all we need is to control is access 2 couple of infoobjects, but land up in declaring * for remaining large amount of infoobjects. It is very time consuming. One way is to do a housekeeping of autho relevant check of all the infoobjects which need not be part of security.
    Is there any method to consider only infoobjects of interest ?

    Reply
    • June 14, 2011 at 4:25 am
      Permalink

      Hi Paddy,

      I can think of two options to reduce maintenance.

      Firstly, if you are not securing any of the 65 characteristics, you can revisit the decision of whether you really need them to be authorization relevant. If they don’t need to be auth relevant, switching off the auth relevant flag in RSD1 will save entering them in analysis authorizations.

      Secondly, you can create a single authorization with all these 65 characteristics which do not need to be secured. Maintain all of them with * access and use this authorization for all users (maybe through a common role?). Now you need to only create authorizations for the infoobjects which you really want to secure.

      Hope this helps!

      Regards,
      Aninda

      Reply
  • July 26, 2011 at 1:23 pm
    Permalink

    Hi,

    we are trying to restrict the user with Cost center and we have add EQ xxxx. and also maintained antorher row with EQ Colon(:). now when we assgined this cost center to the user he is still able to access the other cost centers. do you want us to remove the Colon(:) and then try or any other way to restrict the cost center.

    Note we have also maintained the Hierarchy stucture.

    Thanks
    Sudhakar M.

    Reply
    • July 30, 2011 at 4:55 pm
      Permalink

      Authorization values are intrinsically related the query design and the input values while running the query. A colon (:) for cost center would allow you to run an unrestricted query on cost center as long as cost center is not part of the rows sections in the query design. So first check the query design and then the requirements.

      Reply
  • August 10, 2011 at 4:26 pm
    Permalink

    Thank you for the detailed post. IT was very helpful. We have a requirement, where we have to give a particular user access to a cost center (1000 &2000)and also want to give access to aggregate value ( cost centers 1000-9000). When defining analysis authorizations I gave EQ 1000, EQ 2000 and in another line EQ “:”.

    The users can view the amounts for 1000 and 2000 cost centers and for totals can only see (1000+2000) but not the aggregate $ amount that a user would see with full access.

    Is this even possible with “:” authorization?

    Thank you much in advance

    Bindu

    Reply
    • August 22, 2011 at 5:53 am
      Permalink

      Hi Bindu,

      Adding colon (:) for cost center should allow you to see the aggregate (totals) value for cost center. However you mentioned that this is not working for you. This might be due to how the queries are constructed. Are you running the queries with costcenter restricted to 1000 + 2000? If its restricted, obviously the totals will also be for these two values. However, also note that in case, cost center is present in rows section in the query, you would actually need the characteristic to be restricted to the two values. Otherwise you will get an authorization error.

      as long as cost-center is in free characteristics, costcenter is not restricted, you should be able to display totals with : value.

      Reply
  • August 23, 2011 at 3:45 pm
    Permalink

    Hi Aninda,
    Thank you for the reply. The query itself is not restricting to those particular cost centers. With the analysis authorization object that I created, I can restrict what the user can drill down to w.r.t cost center. Our requiremet is that the user should see costcenter they are authorized to + the aggregate value. However, I am able to give them the cost center they can access; but for the aggregate totals they just see the total for the cost centers they are provided authorizations for.

    For example
    Costcenter Analysis Authorization-1
    EQ 1000
    EQ 2000
    EQ:

    The user can only see data for 1000, 2000 and for totals the total of 1000+2000. For total we are expecting that with the colon authorization, user should see 1000-9000 cost centers which does not seem to work. Is there anything our developer has to do to modify the query (w.r.t variable type used) as we are clueless what needs to be done to make this work.

    Thanks in advance
    Bindu

    Reply
    • August 24, 2011 at 5:16 am
      Permalink

      Hi Bindu,

      The behaviour you are reporting is typical of the case, when you do restrict a characteristic at the query level. Can you please confirm that you are not using an authorization variable to restrict cost center at the query definition? if you are using an authorization variable, the query will only pull in data for 1000+2000 during execution.

      Regards,
      Aninda

      Reply
  • August 24, 2011 at 10:23 pm
    Permalink

    Thank you Aninda for the reply. Yes, the query does use an authorization variable for cost center. If we want the aggregate to show up in totals (for : authorization to work) what type of variable should be used?

    Thank you
    Bindu

    Reply
    • August 25, 2011 at 5:16 am
      Permalink

      An authorization variable will just pull in actual values, not colon (:). As a result, you can not at the same time restrict a characteristic to values and expect it to return data for all cost center values.

      I can think of 2 options now. Create a new version of the query where cost center is not restricted by the authorization variable. Make sure that cost center is in the free characteristics. This query will not allow you to drill down on cost center.

      A second option will be to change the first query, so that it prompts you for the cost center during instead of just running with the authorized values. When you want to drill down you can restrict to actual values. To see totals, you run it unrestricted. I believe, you can set up authorization variables so that it suggests the possible authorized values instead of running for all.

      Reply
  • September 6, 2011 at 8:55 am
    Permalink

    Hi Aninda,

    Can you please briefly explain about BI Security upgrade. I need to use migration tool(RESC_MIGRATION). Can you please provide more proactive approach for this BI Security upgrade.

    Reply
    • September 7, 2011 at 7:59 am
      Permalink

      Hi Vinuthan,

      I have been involved in a few BW upgrades but nowhere was the migration tool used. I would accept that the tool can get you 80% of the way to a successful migration but the remaining 20% would still need to manually adjusted. If you decide to go for the tool, make sure you thouroughly go through the SAP documentation around it and the if any manual changes would be needed for you.

      Regards,
      Aninda

      Reply
  • December 21, 2011 at 2:23 pm
    Permalink

    Hi,
    Thankyou for the helpful post.

    Can we use colon authorization and structural authorization at the same time. In our HR system we follow the structural auhtorization on 0orgunit. And for a particular requirement, i had to create colon on 0orgunit.

    My question is will the colon authorization overwrite the structural authorization in this case?

    Thanks,

    Jothi

    Reply
    • December 23, 2011 at 3:40 am
      Permalink

      Hi Jothi,

      Structural authorizations are implemented in BI through a customer-exit variable. So the behaviour will be governed to a large extent by the code that’s put in the customer exit. I would suggest you take the help of an ABAP developer to check the code maintained for the exit and see if you can incorporate the colon (:) authorization at that point.

      Regards,
      Aninda

      Reply
  • March 3, 2012 at 9:37 am
    Permalink

    Hi Aninda,

    We create 3 custom authorizations objects like ZBASIS, ZPRIVATE, ZFINAN from object 0EMPLOYEE.
    ZBASIS contains attributes from 0EMPLOYEE that everyone can see.
    ZPRIVATE contains sensitive data from 0EMPLOYEE that some of the user can see.
    ZFINAN contains sensitive data from 0EMPLOYEE that some of the user can see.
    We put all the Z* objects in free char. When we select one of the object in free char we got the authorization message that we need the value “*”. I expect to see “:”.
    Do you know the reason?

    Reply
  • March 3, 2012 at 9:45 am
    Permalink

    Basically when we try to drag something from the free chars, the auth check is done with a * auth and since we have restricted the user with “:”, * does not go with it so it throws an auth error. Also the three Z* objects are authorization relevant.

    Reply
  • March 3, 2012 at 8:09 pm
    Permalink

    Hi Aninda,

    I have 3 custom Z* objects derived from 0EMPLOYEE.

    ZBASIS ,everyone have access.
    ZPRIV ,only certain ppl haves access to sensitive data.
    ZFIN, only certain ppl have access to sensitive data.

    I only turned on the “Auth. Relevant” flag for the three objects not for the attributes.
    I put the 3 objects in free characteristics(no variable created)

    When i drag the three objects from the free characteristics to the report. I got the error message “Not enough authorization”. I miss the authorization value “*” for ZFIN and ZPRIV.

    The user 1 may only see basis data got :

    ZBASIS -> “*”
    ZFIN -> “:”
    ZPRIV -> “:”

    The user 2 may only see basis en FIN data got :

    ZBASIS -> “*”
    ZFIN -> “*”
    ZPRIV -> “:”

    etc.

    Regards,

    WMLI

    Reply
    • March 5, 2012 at 8:53 am
      Permalink

      Hi Wmli,

      The error messages that you have reported already give the correct answer. However I will re-iterate some of the points

      An unrestricted authorization relevant characteristic in the free characteristics of a query would require colon (:) value for it in an analysis authorization.

      When you are dragging a free characteristic to the rows area just colon will not be sufficient as you are drilling down on the characteristic . Colon is only meant to authorize access to aggregates not detailed values.

      In such a case, in addition to the colon you would need to restrict the characteristic to actual values through authorization variables or use (*) for the characteristic.

      Hope this works for you!

      Regards,
      Aninda

      Reply
  • March 3, 2012 at 8:10 pm
    Permalink

    Sorry for the double postings

    Reply
  • March 20, 2012 at 3:44 pm
    Permalink

    RSECADMIN does not exits in SAP 640

    I need to search role for the report provided by the user.

    Please help

    Baliram

    Reply
    • March 20, 2012 at 3:47 pm
      Permalink

      Are you using Analysis Authorizations or Reporting Auth Objects? Reporting Objects as used by the earlier security model in BW has its own tcodes.

      Reply
  • January 8, 2013 at 6:32 am
    Permalink

    Your posts are great, really helpful, however I`ve searched all over the net and I was not able to find an answer to my problem.
    I`ve to create more than 500 Analysis Authorization (unfortunately this is the only option that we have in our company), is there a way, to create all the authorizations at one time. Some mass creation or something similar? I know that I can update the massively, but the options there are very limited.
    Probably a LSMW or could be created, but is there some standard sap functionality?

    Best Regards,
    Lyubomir

    Reply
    • February 3, 2013 at 3:54 pm
      Permalink

      Hi Lyubomir,

      To my best knowledge there is no standard tcode or such to mass create analysis authorizations in BW. If you can record a LSMW or SECATT script to do the job, I suggest going forward with that. I have used the same technique when I had to create or update analysis auths en mass.

      However, SAP provides a FM, RSEC_INSERT_FLAT_AUTH which can create analysis auths programmatically. You can ask a ABAP developer to write a wrapper program around this to read data from a file and execute this FM with the data.

      Thanks,
      Aninda

      Reply
  • February 13, 2013 at 8:37 am
    Permalink

    Good day Aninda,

    Thank you very much for you answer, we will record a LSMW and we will use it for mass creation.

    Best Regards and thank you once again.
    Lyubo

    Reply
  • March 12, 2013 at 11:53 pm
    Permalink

    Hi Aninda,

    I have a requirement to restrict specific cost center from detail view but the keyfigure total should contain the value. It would look like this:

    Cost center Amount
    75000 $996,853
    75010 $354,005
    75020 *
    75030 *
    75040 $6,569,900
    75050 $1,567,113
    Overal Result $10,171,981

    You can back into the value of the 2 restricted cost centers to be $684,110 but it doesn’t show the individual value.

    I’ve tried many different configurations but because the security fails on 75020 and 75030 no values are returned just the failed auth message. Is there anyway around this and is the above doable within the bw security paradigm?

    I appreciate any input on this.

    Thank you,

    Dae Jin

    Reply
    • March 24, 2013 at 2:29 pm
      Permalink

      H Dae Jin,

      What you are trying to do can’t be done with standard SAP BW security. To show the cost centers in the detail view, you would have make sure that these values are authorized for the cost center characteristic. On top of this if you have access to the Amount key figure, it will show data for all the authorized characteristics. They choice you will have to make is to whether you want to give access to the two cost center values or not.

      Thanks,
      Aninda

      Reply
  • March 15, 2013 at 8:37 am
    Permalink

    Hi Aninda,

    Thank you very much for nice explanation and forum.
    I have one query.I am new to BW security.I created role with S_RS_COMP and S_RS_COMP1 and added one report to the role.i have not assigned any analysis authorization in this role or directly to the user.Now when i am executing the query in the system it showing you have not authorized to Info provide Ztest1 with display access.Now my query is how can i get the analysis authorization which is having the Info provide in table level.Please can you provide some BW security table names.
    Thanks for your help. Regards,Surya

    Reply
    • March 24, 2013 at 2:54 pm
      Permalink

      RSECVAL table gives you the analysis authorizations already created with the values maintained in them.

      Reply
  • August 5, 2013 at 7:27 am
    Permalink

    Hello Aninda,

    Thank you for all your posts.

    I am new to the BI 7.0 Analysis Authorization concept and your posts have helped me understand it better.

    My question is what is the /nsu53 equivalent transaction in BI 7.0 if we need to know which Anaylsis Authorisation (object/field) is missing in the user roles.

    Thanks once again.

    Regards,
    Siddharth

    Reply
  • November 8, 2013 at 4:55 am
    Permalink

    Hi Aninda

    For one user, I have a situation where we need to

    case 1:
    give access lets say 1,2,3,4 personnel areas for one Infoprovider 1 for query 1

    case2:
    and 1,2,3 personnel areas for infoprovider2 for query2 for the same user.

    I am thinking this can be solved by creating two analysis authorizations and assigning it to the same user in S_RS_COMP and then add query1,2 in S_RS_COMP1 in same role. I cant test it as sufficient data is not available in Dev.

    Can you please let me know if the solution is ok or if there is any alternate route.

    Thanks,
    Chandra

    Reply
    • November 8, 2013 at 11:59 am
      Permalink

      Two analysis authorizations would be needed as you mention. However analysis auths are maintained in S_RS_AUTH. The query authorization would need to be added to both S_RS_COMP and S_RS_COMP1.

      Reply
  • November 12, 2013 at 8:26 am
    Permalink

    Hi Aninda,

    We have a BI 7.3 security upgrade coming up and currently we are on BI 7.0, however using the reporting authorization concept.

    Now that we have to move to the new analysis approach, I have few steps to begin with , but again few queries on certain steps as this would be the first time I would be working on BI security. Please help me understand what needs to be done here.

    Step 1: Activate the authorization mode to “Current procedure with Analysis authorization” in the SPRO”… My query here is this has to be done before upgrade or afterwards

    Step 2: I hope we need to perform the SU25 upgrade here( not sure, please clarify)

    Step 3: Building Analysis authorization: Do we have to activate the 3 special characteristics i.e. 0TCAVALID, 0INFOPROV … ?? or is it by default auth relevant

    Step4: Because we have all the reporting Roles in place and working fine, we are thinking of redesigning the data for the queries of these Roles to the new concept.. Is this fine to go with??

    Step 5: While redesigning these Roles , we need to check for the infoproviders that provide data for the queries in these Roles and restrict the data accordingly in the Analysis authorizations… Now in our case when I analysed one Role which was providing some finance related reporting I got quite a few infoobjects that were auth relevant, but I am unable to find out how the data access was provided to these in the existing process as they do not have any custom objects which provides data.

    What would be the right approach to deal with this?? Do I need to consult the BI development TEam or is there any way where I can find out from the system as to how the user is trying to access data especially some org field related ones.

    Step 6: Restrict access based on either value or hierarchy authorizations. Is this again the BI development Team who would be suggesting us??

    Step 7: Add these analysis authorizations in the Role and provide access to the user, test it and move it to further environments.

    Please help me in understanding these.

    Regards,
    Preethi

    Reply
    • November 12, 2013 at 9:52 am
      Permalink

      Hi Preethi,

      Thanks for the extra long question. However I am very doubtful about how much help I can provide you here. An upgrade from reporting to analysis auths is a big event and can prove challenging for seasoned security consultants. My first suggestion is to get some real help from folks around you. Next look at SAP documentation about the steps involved in an upgrade. This is far too important a subject to base your actions on my website.

      I will still try to answer a few of the questions

      Step 1: Activate the authorization mode to “Current procedure with Analysis authorization” in the SPRO” – Can be done after Basis upgrade has been completed.

      Step 2: I hope we need to perform the SU25 upgrade here( not sure, please clarify) – SU25 is a big subject in itself. Its probably not going to make a huge difference with reporting but ideally SU25 should be performed after each upgrade of the system.

      Step 3: 0TCAVALID, 0INFOPROV – check these in RSD1 after the upgrade. I believe you will have to set them to auth relevant

      Step 4: Ideally the upgrade should be transparent to the end users. So queries should remain the same and the roles need to be updated with new authorizations. However if you to re-write some queries as part of the upgrade, thats fine too.

      Step 5: You need to get some help in how to analyze BW security. This site can provide a start but some of it just comes out of experience. SAP has a good training program for BW security – BW 365. Try if you can go for it.

      Step 6: Restrict access based on either value or hierarchy authorizations – How does security work currently? Both were supported as part of the reporting authorization.

      Step 7: Once the authorizations are built, added to roles, tested you would need to move both the roles and the analysis auths to production.

      I will end by re-iterating that if this is indeed your first BW project, get help from someone who has actual experience with an upgrade.

      Thanks,
      Aninda

      Reply
  • November 12, 2013 at 1:00 pm
    Permalink

    Hi Aninda,

    Thanks a lot for your patience and prompt reply.. Sure we would look for someone who has actual work experience and start it 🙂

    Regards,
    Preethi

    Reply
  • March 19, 2014 at 5:13 am
    Permalink

    Hi Aninda,

    where are you ?

    Reply
    • April 10, 2014 at 11:56 am
      Permalink

      I am fine Ramesh. How are you?

      Reply
  • June 4, 2014 at 1:35 pm
    Permalink

    Hello, i’m new in SAP BW and i’m in migration process to the new authorization concept.

    Here is what happening:

    I have a role with all access to a company (*) of a provider X.
    I have another role with restricted access to a company (ex: COMPANY1, COMPANY2 and COMPANY3) of a provider Y.

    When i attribute those 2 roles to a user and access a query of the provider Y, i can see all the companies when it was supposed to only see the 1, 2 and 3.

    What am i doing wrong?

    Thank you in advance.
    João Gonçalves

    Reply
    • October 31, 2014 at 6:25 pm
      Permalink

      What does the authorization trace in RSECADMIN say? There might be a third authorization which is resulting in the extra access. The trace will tell you what all is happening behind the scenes.

      Reply
  • July 18, 2014 at 2:15 pm
    Permalink

    hi Aninda,

    How to set authorization relevant flag for 0TCAACTVT,0TCAVALID, 0INFOPROV in RSD1 .In my system i found it in uneditable mode.

    Reply
    • October 31, 2014 at 5:54 pm
      Permalink

      Do you have security for changing these settings? Since these are InfoObjects, this is better done by a BI developer rather than a security person.

      Reply
  • July 19, 2014 at 8:27 pm
    Permalink

    Hello ,

    Thanks for details .Well explained.

    Can anyone please tell me how we can maintain the Authorization Values in Production ?
    As the values in PROD system are quiet different from the volumes and data in DEV . i have requirement to restrict on Hierarchy and i might need to change it in the Authorization values from time to time and can be done only in Production as i dont have the same Hierarchy in DEV.

    Can anyone please help on how i can maintain the Auth values in Production system directly ?

    Regards
    Ram

    Reply
    • September 26, 2014 at 1:33 pm
      Permalink

      If you are using hierarchies, you need to ensure that the hierarchies are maintained the same throughout the landscape or at least the top level nodes are present. Once these nodes are present you should modify your analysis auths in dev and transport to prod. Directly maintaining this in production is a very bad idea.

      Reply
  • August 26, 2014 at 1:56 pm
    Permalink

    I have two questions.

    – Is there a difference between assigning multiple info objects to the same analysis authorization object, versus, assigning each to it’s own analysis authorization object (other than the obvious need to add one vs multiple objects to S_RS_AUTH)?

    – Once an analysis authorization is generated, it will no longer let me modify it. Is there a way to get around this?

    Reply
    • September 26, 2014 at 1:23 pm
      Permalink

      Ans 1 – No difference in the two approaches except in the design philosophy.
      Ans 2 – Maybe you have create access for S_RSEC and S_DEVELOP but not change

      Reply
  • October 14, 2014 at 5:58 am
    Permalink

    Hi Aninda
    what are the authorizations required for end user to execute analysis authorization,if it is assign to directly to user via rsecdamin

    Reply
  • December 31, 2020 at 2:58 am
    Permalink

    Hi Aninda,
    I need your help in understanding the below issue.. If two AA’s provides access to one infoprovider say XXX which is used in query say YYY.. So when executing a report or a query the two AA’s maintained with XXX info provider must be checked right.. Here comes a question..
    AA 1 has sales credit restricted with some values and : whereas AA2 has * in sales credit.. So whether * access will be replaced by restricted actual values present in another AA??
    FYI—sales credit is maintained as free characteristic and drill down is done what will happen and what is the appropriate solution.

    Awaiting for your reply!!

    Reply
    • July 6, 2021 at 3:03 am
      Permalink

      The combining/merging of two or more analysis authorizations follows a complicated logic. There is a SAP note which talks at length about the merging of analysis authorizations. Ideally, * should override : and give full access to the characteristic. However, you have to think of not just sales credit but also any other authorization relevant characteristics that are present in the infoprovider and how all these authorization relevant characteristics have been maintained in the analysis authorizations which will determine what data is accessible in the reports.

      Reply
  • July 18, 2021 at 11:02 pm
    Permalink

    Hi Aninda,

    I have a scenario where I need to compare and verify if the version in PRD and dev is the same version..

    How can we do this verification.

    Regards
    Chandra

    Reply
    • July 18, 2021 at 11:03 pm
      Permalink

      I am referring to comparison of versions of analysis authorizations between PRD and dev

      Reply
      • July 19, 2021 at 1:27 am
        Permalink

        You can check the timestamps of the analysis authorizations between production and development. The other option would be to compare the entries for the analysis authorizations in RSECVAL table. I believe this table stores the actual entries made in the analysis authorization.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *