<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px">
<DIV><FONT size=1>Hi,</FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>I grabbed this message from the MIT workflow discussion, I
hope you don't mind a direct email. I am looking for some clarification on
what order to send the organization objects in ALE so that they are processed
properly in the recieving system. Example, do you send jobs first, then
positions, then org structures? Are you using transaction PFAL to do
this?</FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>I would appreciate your help on this.</FONT></DIV>
<DIV><FONT size=1></FONT> </DIV>
<DIV><FONT size=1>Thanks,</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Rob Crawford<BR>Menasha Advantage<BR>1649 Bergstrom Rd.<BR>Neenah, WI
54957<BR>(920)751-2513<BR><A
href="mailto:rob.crawford@menasha.com">rob.crawford@menasha.com</A>
<BR><BR>>>> ritu_nagpal@hp.com 11/15/01 12:17PM >>><BR>Here is
the way I have done it at several clients...<BR><BR>I create the PD Org (Org
units, positions, relationships between these<BR>objects) in the golden client
(clean customizing client). I also create HR T<BR>tasks if needed in the golden
client. Then, I use ALE to move these PD Org<BR>objects and relationships to the
development box, testing box and production<BR>box. The only catch here is that
ALE does not support HR T tasks and so I<BR>use the transport system to move
these (I use RHMOVE30 to create the<BR>transport request for the HR T tasks).
You have to transport the HR T tasks<BR>first and then do the ALE (this is
because if the tasks exist in the<BR>receiving system, ALE will successfully
create the relationship between task<BR>and position). In the production box, I
set up the user to position<BR>relationships as these users might not exist in
all the systems in the<BR>pipeline.<BR>By using ALE, the object ids of the HR
objects stay the same in each system.<BR>It has worked beautifully for me....I
am not creating new PD Org objects in<BR>production so I do not end up messing
anything up.<BR><BR>If you need details on how to do the ALE setup, let me know
and I will email<BR>it.<BR><BR>Ritu<BR>HP<BR><BR>-----Original
Message-----<BR>From: Gregory Kowalik [<A
href="mailto:gkowalik@ashland.com]">mailto:gkowalik@ashland.com]</A><BR>Sent:
Thursday, November 15, 2001 9:58 AM<BR>To: SAP-WUG@MITVMA.MIT.EDU<BR>Subject:
Re: Org. Plan maintenance<BR><BR><BR>I kind of have hard time believing that SAP
(as a company) would recommend<BR>this approach.<BR>It is evidently against the
general policy not to transport anything back<BR>from production unless
absolutely needed.<BR>I have seen many SAP consultant recommending really bad
solutions so let's<BR>not take their words for granted.<BR><BR>Think about the
mess you leaving in production in case you decide you are<BR>not going live with
some positions/org units or other PD objects.<BR>Then you have to remember to
clean both development and production.<BR><BR>... but I guess you can skin the
cat in many ways, .... no offense - this<BR>is just "opinion my
own".<BR><BR>Greg<BR><BR><BR><BR><BR><BR><BR>Patrick Green
<patrick.d.green@us.pwcglobal.com>@MITVMA.MIT.EDU> on<BR>11/15/2001
11:22:15 AM<BR><BR>Please respond to "SAP Workflow Users' Group"
<SAP-WUG@MITVMA.MIT.EDU><BR><BR>Sent by: SAP Workflow
<Owner-SAP-WUG@MITVMA.MIT.EDU><BR><BR><BR>To:
SAP-WUG@MITVMA.MIT.EDU<BR>cc:<BR>Subject: Re: Org. Plan
maintenance<BR><BR><BR>Patrick & Jennifer, here's an approach that was
suggested to me at the<BR>Fall 2001 ASUG conference in New
Orleans.<BR><BR>Create the needed PD Org objects in your production client as
master data.<BR>Then use program RHMOVE30 to move the objects to your
development clients.<BR>The objects will then be readily transportable with your
workflows without<BR>wreaking havoc on existing production structures.<BR><BR>A
gentleman from Eastman Kodak Chemicals (thanks Tom Walker!) told me that<BR>this
is the approach SAP recommended for his company. And it is how we
are<BR>handling the issue for our BP Chemicals client now as well.<BR><BR>Best
Regards,<BR>-- Patrick D. Green<BR>GSAP Interface
Architect<BR>PricewaterhouseCoopers BPO Solutions<BR>Tulsa, OK
74102<BR><BR><BR><BR><BR><BR>Gregory Kowalik
<gkowalik@ashland.com>@MITVMA.MIT.EDU> on 11/15/2001<BR>07:05:40
AM<BR><BR>Please respond to SAP Workflow Users' Group
<SAP-WUG@MITVMA.MIT.EDU><BR><BR>Sent by: SAP Workflow
<Owner-SAP-WUG@MITVMA.MIT.EDU><BR><BR>To:
SAP-WUG@MITVMA.MIT.EDU<BR>cc:<BR>Subject: Re: Org. Plan
maintenance<BR><BR><BR>I recommend you guys to setup a separate number range for
your org. objects<BR>in development client.<BR>Secondly I think you should
maintaint positions/jobs and org units in<BR>development, transport them accross
systems, but maintain user assignments<BR>in target system.<BR>Reasons: you will
not have user ID that you have in prod in your dev<BR>client, plus transport
would overwrite your user assignments.<BR>To accomplish that you need to set a
block for transport of infotype A 008.<BR><BR>Greg<BR><BR><BR>Jennifer Bragg
<bragg.j@pg.com>@MITVMA.MIT.EDU> on 11/15/2001 07:55:11
AM<BR><BR>Please respond to "SAP Workflow Users' Group"
<SAP-WUG@MITVMA.MIT.EDU><BR><BR>Sent by: SAP Workflow
<Owner-SAP-WUG@MITVMA.MIT.EDU><BR><BR><BR>To:
SAP-WUG@MITVMA.MIT.EDU<BR>cc:<BR>Subject: Re: Org. Plan
maintenance<BR><BR><BR>Patrick,<BR>Did you ever get an answer to your
question? We are now trying to move our<BR>WF to testing environment where
we have setup a new org structure.<BR>However we<BR>do not have authorization to
make changes in our testing environment and we<BR>are trying to transport the WF
with organization ids integrated as roles.<BR>In<BR>the development evirnment
these organization ids are already exist as a<BR>different type of object.
Any ideas, or did you get an answer to
your<BR>question<BR>below?<BR><BR>Jennifer<BR><BR>Internet Mail
Message<BR>Received from host:
cherry.ease.lsoft.com<BR>[209.119.0.109]<BR><BR>From: "de Valensart
Schoenmaeckers,
Patrick"<BR><deValensartSchoenmaeckers.Patrick@pmintl.ch>@MITVMA.MIT.EDU>
on 08/31/2001<BR>02:16 PM
ZE2<BR><BR>
"de Valensart Schoenmaeckers, Patrick"<BR>To:
SAP-WUG@MITVMA.MIT.EDU<BR><deValensartSchoenmaeckers.Patrick@pmintl.ch>@MITVMA.MIT.EDU><BR>Cc:
(bcc: Jennifer
Bragg-J/PGI)<BR>
Subject:<BR>Org. Plan
maintenance<BR><BR> Sent
by: SAP Workflow
<Owner-SAP-WUG@MITVMA.MIT.EDU><BR>
08/31/2001 02:16
PM<BR>
Please respond to "SAP Workflow Users'
Group"<BR>
<SAP-WUG@MITVMA.MIT.EDU><BR><BR>Hi workflowers!<BR><BR>We are currently
hestitating between doing the day-to-day maintenance of<BR>the<BR>organizational
plan direcly in production system, as if it was master data,<BR>or first in
development environment and then transport it to Q/A and Prod,<BR>as if it was
customizing.<BR>How should that kind of maintenance activities be considered?
Customizing<BR>or<BR>master data? If you consider it as master data, how did you
de-activate the<BR>transport connection in the development
environment?<BR><BR>Thanks in advance for your answers.<BR><BR>Patrick de
Valensart<BR>Associate IS Analyst<BR>NV Philip Morris Belgium SA<BR>Boulevard du
Souverain, 24<BR>B-1170 Brussels<BR>Tel : + 32 (0)2 674 18 56<BR>Fax : +32 (0)2
674 18 74<BR>Email :<A
href="mailto:devalensartschoenmaeckers.patrick@pmintl.ch">mailto:devalensartschoenmaeckers.patrick@pmintl.ch</A><BR><BR><BR><BR>----------------------------------------------------------------<BR>The
information transmitted is intended only for the person or entity to<BR>which it
is addressed and may contain confidential and/or privileged<BR>material.
Any review, retransmission, dissemination or other use of, or<BR>taking of any
action in reliance upon, this information by persons or<BR>entities other than
the intended recipient is prohibited. If you received<BR>this in
error, please contact the sender and delete the material from
any<BR>computer.<BR></DIV></BODY></HTML>