PPOME - taking away transport request

Former Member · ‎08-06-2011

Hello,

I was hoping someone with PPOME / workflow knowledge could help me here... Currently, are company locks down the transaction code PPOME, meaning you have to submit a transport request any time making a change to the struture, when a user...

THe way we have it setup is we have an organization unit at the highest level, followed by a position, and then a user assigned to the position.

What we would like to do is anytime we want to change a user (add/remove from a position), we would like for it to NOT ask for a transport request, but anytime some tries to change a position or organization unit, it does...

I hear this may be possible... cna someone tell me how/if it is?

Former Member · ‎08-08-2011

[Tried Google yet?|http://www.lmgtfy.com/?q=PPOME,transport,request]

Former Member · ‎08-08-2011

Im sorry, but you obviously did not read my issue above to the full extent... If you would have, it would be obvious that this is more then just a simple opening up the trasaction for transport request (which we know how to do).

Please reframe from writing comments like "was that so hard" when you clearly don't understand the issue.

Former Member · ‎08-08-2011

Now now... you also did not state what you have tried nor what exactly you have heard (and tried but did not work...?).

e.g. have you tried a "current setting" view cluster? Are your client (role) settings correct in Scc4? (this would be my first port of call).

Cheers,

Julius

arpan_paik · ‎08-10-2011

 Currently, are company locks down the transaction code PPOME, meaning you have to submit a transport request any time making a change to the struture, when a user...

If this is the target then why do you want this?

 What we would like to do is anytime we want to change a user (add/remove from a position), we would like for it to NOT ask for a transport request, but anytime some tries to change a position or organization unit, it does...

And locking PPOME means lock it in production? Seems so and you are looking for making all changes in Dev. But are all business users present in Dev?

Anyway I am confused or failed to understand the scenario....

Regards,

Arpan Paik

Former Member · ‎08-10-2011

Question - If this is the target then why do you want this? - ** Answer - We want PPOME to be locked down so when changes are made to the organizational unit, or the position, a transport request is made. We dont want this when a change to the user position is made (meaning no transport request).

Question ; And locking PPOME means lock it in production? Seems so and you are looking for making all changes in Dev. But are all business users present in Dev? Answer - we would make changes directly in PRD when it comes to changes to the user position/agent. If changes were to be made to the organizational or position levels, it would be transported through the system... the impact of accidentaly delete to an organizational unit or position is huge, vs a change to the user is small and can be corrected easily.

Edited by: farmerj3 on Aug 10, 2011 6:56 PM

Edited by: farmerj3 on Aug 10, 2011 6:57 PM

arpan_paik · ‎08-11-2011

Thanks for clarifying the issue.

Now to point 1 : Changes to user position - It will be made directly in production. So user (preferably some super user/firefighter) will do so in production by PPOME. And in production system there should not be any transport pop-up. So what is the issue here?

Point 2 : Changes to org unit/position - As this is your dev system where you are making change so TR should always be there. That is the way dev been configured. Again what is the issue here?

Is this a system settings (SCC4) problem?

Regards,

Arpan Paik

Former Member · ‎08-11-2011

Thanks for clarifying the issue.

Now to point 1 : Changes to user position - It will be made directly in production. So user (preferably some super user/firefighter) will do so in production by PPOME. And in production system there should not be any transport pop-up. So what is the issue here?

Answer - The issue is the transport request (pop) DOES appear when the group/user attempts to make changes for the user position. We do not want the transport request to appear when a change is made to the user position... This is the whole point of the question I have - How do we get PPOME to allow NO transport request when a change is made to a user position, but DOES appear when there is a change made to a position or orginizational level.

RIght now - we get transport request for everything - We dont want to open up PPOME to all no tranpsort requests for everything, as we dont want changes to be made to the poistion and organizational levels without going through the testing and quality boxes. We just want the transport request NOT to appear when changes are made at the user position level in PRD.

Former Member · ‎08-12-2011

Quick question (this time trying not be sarcastic):

Would you consider stopping changes to organisational structure using authorisations rather than transport request popup?

In this solution you would need to open PPOME for changes without transport (T77S0: TRSP-CORR=X and SCC4 settings).

Then you should control what is allowed in PPOME using authorisation object PLOG.

If your user has following PLOG objects with PPOME it should allow only changes to user assignments:

PLOG (This object allows displaying)

Infotype: 1000, 1001...

Pl. stat: *

Obj. type: C, O, P, S, T, US

Pl. vers: 01

Func Code: DISP, LISD

Subtype: *

PLOG (This object allows changes only to relationship 'is holder of' between position and user)

Infotype: 1001

Pl. stat: *

Obj. type: S, US

Pl. vers: 01

Func Code: *

Subtype: A008, B008

Former Member · ‎08-12-2011

Hmm... interesting proposal...

Do you by chance have any information related to that setup you put there? I'm new to the whole PPOME structures, so will need to provide information to someone with a little more techincal background...

Thanks for the follow up, as i didnt even though that could be an option.

Former Member · ‎08-15-2011

Hi,

I assume you can find a test environment where you can change table T77S0 Group TRSP Sem.abbr. CORR value to X that should stop transport request window popping up when saving data in PPOME.

Then to demonstrate how we can control PPOME access using authorisations I would create a test user (SU01) and test role (PFCG).

In PFCG assign tcodes PPOME, PPOSE and SU53 to the test role. Since you have tcode PPOSE assigned it will bring authorisation object PLOG with required display values (PLOG: 1000, 1001 | * | C, O, P, S, T, US | 01 | DISP, LISD | * ).

Then you need to change the maintenance PLOG value to limit access to create relationships between S and US and specifically relationships A008 and B008. Some background for PLOG object fields:

Infotype and object type concept in HR works like object model. Infotype 1000 holds the name of the object. There are numerous different object types but PPOME displays mainly Jobs (C), organisational units (O), positions (S), persons (P), tasks (T) and users (US).

Infotype 1001 hold the relationship information between objects. When you assign user to a position you actually create a relationship (intoype 1001) between objects S and US. Relationships have different codes to describe the relationsip. In infotype 1001 the code is a subtype of the relationship. You can see all available values per infotype from table T778U.

So our second PLOG object should have authorisation to create infotype 1001 for object type S with subtype A008 and since relationships need to be created both ways I also need authorisation to create infotype 1001 for object type US with subtype B008. (PLOG: 1001 | * | S, US | 01 | * | A008, B008). If you want to restrict more specifically who can create and delimit relationships you can use different function codes (INSE, CUTI etc).

Play around and eventually HR object type and infotype concept is very straight forward. It's so different to other modules of SAP that it may first look bit weird...

Cheers, s

Former Member · ‎12-01-2011

Hi,

I have an exactly similar requirement for my project.

Can you please let me know the approach you followed to solve the issue?

Any help would be much appreciated.

Thanks in advance,

Bidisha

Former Member · ‎07-02-2014

Just wanted to share a word of caution from my experience working with PPOME.

I wanted to assign a user to a position (Release code workflow to work for Purchase requisition release strategy). When I tried in Production it did not allow me to save and got message that client is not modifiable.

Therefore I created a transport with new users adding to the positions I wanted and moved it to ECP. I assumed this would assign new users to the position that I am moving via TP and keep the existing user assignments in tact in ECP. Unfortunately, after this TP was moved all the existing user assignments disappeared except the new users (that existed in ECD organization structure).

After I read on SDN blogs I updated TRSP-CORR via OOCR tcode and moved the transport to ECP thinking this will allow me to do changes in ECP. But this did not help either so seems like my last resort is to make a request to open up ECP so I can update the user assignments to the positions directly in ECP.

Former Member · ‎03-11-2015

Hi

You can deactivate the transport request generation when you do an assignation of an employee by modifying these two entries in the table T77S0. Both entries must be set to "X".

Check the link to see a full explanation

Former Member · ‎02-02-2016

Could you tell me if the effect of this change indeed allowed you to change the user assignments but still required a transport for organization structure changes? If so, did you use the authorization route?

Thank you!