Skip to Content
avatar image
Former Member

Make User Parameter ID's available through the CUA

Hi,

Our client requires two user parameter ID's to be populated to users in the CRM application:

CRM_SDB_VALID_SOLUT

CRM_SDB_VALID_SOLUTI

The CRM application is linked to the CUA in the R3 application. The parameter ID's do not exist in R3 and the client does not want to maintain the user master record in the CRM application. Hence we need to find a method of distributing the Parameter ID's in to R3 (from CRM), perform the assignment of the parameter ID's to users in R3 and then redistribute the assignment to CRM.

Has anyone tried this before?

Do you know how to get parameter ID's, which does not exist in the central CUA system, assigned to users in the child systems without assining the parameter user ID's directly in the child system?

Any help appreciated

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Nov 12, 2008 at 09:49 AM

    Hi Wes

    Have a look at OSS Note 395841 - If I understand you correctly that should meet your requirements.

    It's a very quick fix.

    Cheers

    Alex

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi Alex,

      Thank you the note is spot on! We jhave tested this in Development and it seems to do the trick.

  • avatar image
    Former Member
    Nov 11, 2008 at 06:03 PM

    There is no standard solution for this because Parameter ID's are system specific. Of course there are some PID's that are 'global' (for example, SU53_STYLE) but by design they are all meant to be system dependent.

    It is generally a bad idea to maintain PID's via CUA. (You may want to refer to this thread [here|AUthorizations needed to change parameters in SU3; if you haven't done so already.) Try reasoning with your client explaining the challenges they will run into if PID's are expected to be maintained in CUA only.

    And for argument's sake, let us assume that your CUA client and child client are of the same type (CRM). There is no guarantee that your users will not change their PID's to something else after initial setup. You would then have to revoke access to SU3 from all users in child systems thus defeating the purpose of PID's. If your client still insists that they want to maintain PID's via CUA only and no user should maintain personal defaults in child systems, then the only solution that comes to mind is to manually add all PID's from all of your child systems to table TPARA in your CUA system. This is easier said than done because you will then have to ensure that all dependent tables (check tables and foreign-key tables) reflect relevant changes else your data soon becomes inconsistent.

    Add comment
    10|10000 characters needed characters exceeded