Org structure maintenance

[Keohan, Susan]

Hi Gavin,

We do not transport our org structure - although I have done so in the past.  But we have HR implemented, and it makes no sense for those folks to be creating and transporting positions, jobs, etc.
As a result, our Dev box Org structure has gotten butchered over the years, and it's a real struggle to keep a semblance of reality, but then again, we don't have to worry about a 'real' org structure where developers like to play.

We assign users in our various systems via PA0105 - and again, no transports.  Not sure if this is a Basis deal or what.  Our user ids are assigned to Persons, who hold Positions, which are encompassed by Jobs.
Kind of different from the traditional layout, but it works *pretty much* for us.

We all use PLVAR 01.  I know that additional Plan Versions are possible, but WF wants version 01, and since we have peaceful co-existence with HR, we only need that one version.

Hope this helps,
Sue

----
Susan R. Keohan
SAP Workflow Specialist
Enterprise Applications
Information Services Department
MIT Lincoln Laboratory
244 Wood Street, LI-200
Lexington, MA. 02420
781-981-3561
keohan at LL.MIT.EDU

________________________________
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Gavin Mooney
Sent: Monday, November 17, 2008 9:58 PM
To: SAP Workflow Users' Group
Subject: Org structure maintenance


Hello everyone,

We're trying to decide how to manage our org structure. The actual structure is very simple, just based on Org Units, Positions and Users (we're not implementing SAP HR here). We're on ECC 6.0 / WAS 700. I've been reading some former WUG posts and the SAP documentation but still have the following questions and I'd like to know what other projects have done and what is recommended please.

1) Where to maintain the org structure.
As we don't have a Production environment yet we are maintaining it in Development. The Transport Connection is set to automatic (i.e. T77S0 entries for TRSP CORR, TRSP STOBJ and TRSP WFOBJ are all set to space) so the system asks for a transport for any changes to the org strucure. This seems to be working ok for now, but I see that we could specify "Transport via object lock (repair flag)" or "No automatic transport connection" and then manually run RHMOVE50 or RHMOVE30 to transport to other environments. What are the pros/cons of these other options?

Although I see that some projects choose to maintain the org structure in Production because it is faster, allows for more reactive fixes, etc. I don't think we will need to do that as our structure is very simple and hopefully won't change that often. Also if we maintained it in Prod we would have to merge any changes back to Dev for testing. Sound ok?

2) User assignments
At the moment the system asks for a transport whenever a user is assigned to a position. So even for unit tests in our Dev environment we need to assign the user in the golden client and then run SCC1 to move the changes across to the unit test client. Ideally we'd like to change this so that we can change user assignments directly in the unit test client (and in the future we'd want to maintain user assignments direct into production). Is this possible and if so how?

Actually what happens is if I try to change a user assignment in the unit test client I can do it in PPOMW, then when I click on save the system pops up a message saying that the client has status not modifiable, but then saves the data anyway. So we can do it, but it's just not very intuitive - ideally we'd want to be able to do it without getting the popup (and without opening up the whole client of course).

Also - we don't want to tranport the dev user assignments to production when we transport the org structure, so do we need to maintain entries in OOTR or is there a different / better way?

3) Plan versions
We would potentially like to maintain different plan versions (for example as backups) and so have set up number assignment across all plan versions (Table T77S0 entry NUMRG COMP = 'X').

Looking forward to hearing your opinions and experiences.
Many thanks,
Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081118/2128a9f3/attachment.htm