How is security to organizational units maintained through path to prod?

[Former Member]

Hi,

I am a security analyst working on a project that will be transitioning our procurement users from EBP to SRM. I am building security roles in SRM for Operational Purchasers and will be restricting access at the "Responsible Purchasing Organization" level (auth object field BBP_PURORG).

I have pointed the authorizations to the appropriate purchasing org's that we want the users to have access to (ex: O 60000110). However I just found out that the organizational ID's to these purchasing org's will not be the same across each environment (Development, QA, Production). I was told by our SA's that the purchasing org data is loaded into each SRM environment directly and that SAP automatically assigns them org ID numbers sequentially. So the value in dev may be different that what it is in cons (dev might have O 60000110 and cons might be O 60000012 for the same purchasing org).

Because the org ID values are not the same in each environment and our security roles are migrated (via a transport) from dev to these other environments...how does SAP handle this discrepancy? Will it automatically adjust the authorization object in the role to point to the correct purchasing org? I'm pretty sure this does not happen because I tried assigning a value in one environment (pathfinding) and then uploading the role into another environment (development) and the org ID number did not change.

Manually modifying the security role in each environment (thereby bypassing change control) is not an option for us. We want to make sure all role changes are made in development and then transported up the normal path to production.

Since we will have the org ID numbers prior to migrating the roles to production, it will not be a problem to load the production org ID numbers into the roles. However, we feel that since the org ID's will be different across environments, then we will run into authorization conflicts. In other words, if the role contains the org ID's for dev, cons, and prod...then we could potentially be giving access to an org ID that we don't want in prod.

The only way I can think to get around this is to create seperate roles specific to each environment that would contain only the org ID's for that environment. But then we won't be able to perform a real test because the roles we test will not be the same roles that are in prod.

Any ideas on what we can do to alleviate this problem? Is there a way to force the numbers to be the same across all environments? Our SA's are looking into the possibility of migrating the org ID's for purchasing org using ALE or some other method but not sure this is feasible.

I hope I expained this clearly...any input you have would be greatly appreciated.

Thanks,

Corey

Edited by: Corey Nickell on Jan 8, 2008 5:26 PM

[masa_139]

How many Purching Org in your organization ? My client maintains it manually.

Regards,

Masa

[Former Member]

We have at least 32 purchasing org's/sourcing org's at this time but that number is expected to grow as we move more of our business on to SRM.

When you say that your client maintains it manually, do you mean that they manually update their security roles in each SRM environment (dev, cons, prod)?

Thanks for the response!

Corey