11-11-2008 5:03 PM
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
11-12-2008 9: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
11-11-2008 6: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|; 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.
11-12-2008 9: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
11-18-2008 8:57 AM
Hi Alex,
Thank you the note is spot on! We jhave tested this in Development and it seems to do the trick.