Org. Plan maintenance

Thu Nov 15 13:17:38 EST 2001

Here is the way I have done it at several clients...

I create the PD Org (Org units, positions, relationships between these
objects) in the golden client (clean customizing client). I also create HR T
tasks if needed in the golden client. Then, I use ALE to move these PD Org
objects and relationships to the development box, testing box and production
box. The only catch here is that ALE does not support HR T tasks and so I
use the transport system to move these (I use RHMOVE30 to create the
transport request for the HR T tasks). You have to transport the HR T tasks
first and then do the ALE (this is because if the tasks exist in the
receiving system, ALE will successfully create the relationship between task
and position). In the production box, I set up the user to position
relationships as these users might not exist in all the systems in the
pipeline.
By using ALE, the object ids of the HR objects stay the same in each system.
It has worked beautifully for me....I am not creating new PD Org objects in
production so I do not end up messing anything up.

If you need details on how to do the ALE setup, let me know and I will email
it.

Ritu
HP

-----Original Message-----
From: Gregory Kowalik [mailto:gkowalik at ashland.com]
Sent: Thursday, November 15, 2001 9:58 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Org. Plan maintenance

I kind of have hard time believing that SAP (as a company) would recommend
this approach.
It is evidently against the general policy not to transport anything back
from production unless absolutely needed.
I have seen many SAP consultant recommending really bad solutions so let's
not take their words for granted.

Think about the mess you leaving in production in case you decide you are
not going live with some positions/org units or other PD objects.
Then you have to remember to clean both development and production.

... but I guess you can skin the cat in many ways, .... no offense - this
is just "opinion my own".

Greg

Patrick Green <patrick.d.green at us.pwcglobal.com>@MITVMA.MIT.EDU> on
11/15/2001 11:22:15 AM

Please respond to "SAP Workflow Users' Group" <SAP-WUG at MITVMA.MIT.EDU>

Sent by:  SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>

To:   SAP-WUG at MITVMA.MIT.EDU
cc:
Subject:  Re: Org. Plan maintenance

Patrick & Jennifer,  here's an approach that was suggested to me at the
Fall 2001 ASUG conference in New Orleans.

Create the needed PD Org objects in your production client as master data.
Then use program RHMOVE30 to move the objects to your development clients.
The objects will then be readily transportable with your workflows without
wreaking havoc on existing production structures.

A gentleman from Eastman Kodak Chemicals (thanks Tom Walker!) told me that
this is the approach SAP recommended for his company.  And it is how we are
handling the issue for our BP Chemicals client now as well.

Best Regards,
-- Patrick D. Green
GSAP Interface Architect
PricewaterhouseCoopers BPO Solutions
Tulsa,  OK  74102

Gregory Kowalik <gkowalik at ashland.com>@MITVMA.MIT.EDU> on 11/15/2001
07:05:40 AM

Please respond to SAP Workflow Users' Group <SAP-WUG at MITVMA.MIT.EDU>

Sent by:  SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>

To:   SAP-WUG at MITVMA.MIT.EDU
cc:
Subject:  Re: Org. Plan maintenance

I recommend you guys to setup a separate number range for your org. objects
in development client.
Secondly I think you should maintaint positions/jobs and org units in
development, transport them accross systems, but maintain user assignments
in target system.
Reasons: you will not have user ID that you have in prod in your dev
client, plus transport would overwrite your user assignments.
To accomplish that you need to set a block for transport of infotype A 008.

Greg

Jennifer Bragg <bragg.j at pg.com>@MITVMA.MIT.EDU> on 11/15/2001 07:55:11 AM

Please respond to "SAP Workflow Users' Group" <SAP-WUG at MITVMA.MIT.EDU>

Sent by:  SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>

To:   SAP-WUG at MITVMA.MIT.EDU
cc:
Subject:  Re: Org. Plan maintenance

Patrick,
Did you ever get an answer to your question?  We are now trying to move our
 WF to testing environment where we have setup a new org structure.
However we
do not have authorization to make changes in our testing environment and we
are trying to transport the WF with organization ids integrated as roles.
In
the development evirnment these organization ids are already exist as a
different type of object.  Any ideas, or did you get an answer to your
question
below?

Jennifer

 Internet Mail Message
 Received from host:      cherry.ease.lsoft.com
 [209.119.0.109]

From: "de Valensart Schoenmaeckers, Patrick"
<deValensartSchoenmaeckers.Patrick at pmintl.ch>@MITVMA.MIT.EDU> on 08/31/2001
02:16 PM ZE2

                        "de Valensart Schoenmaeckers, Patrick"
To:   SAP-WUG at MITVMA.MIT.EDU
 <deValensartSchoenmaeckers.Patrick at pmintl.ch>@MITVMA.MIT.EDU>
Cc:    (bcc: Jennifer Bragg-J/PGI)
                                                                 Subject:
Org. Plan maintenance

         Sent by:  SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>
                                           08/31/2001 02:16 PM
                 Please respond to "SAP Workflow Users' Group"
                                      <SAP-WUG at MITVMA.MIT.EDU>

Hi workflowers!

We are currently hestitating between doing the day-to-day maintenance of
the
organizational plan direcly in production system, as if it was master data,
or first in development environment and then transport it to Q/A and Prod,
as if it was customizing.
How should that kind of maintenance activities be considered? Customizing
or
master data? If you consider it as master data, how did you de-activate the
transport connection in the development environment?

Thanks in advance for your answers.

Patrick de Valensart
Associate IS Analyst
NV Philip Morris Belgium SA
Boulevard du Souverain, 24
B-1170 Brussels
Tel : + 32 (0)2 674 18 56
Fax : +32 (0)2 674 18 74
Email :mailto:devalensartschoenmaeckers.patrick at pmintl.ch

----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.