No agent assignment after Transports

Mon Oct 20 22:11:15 EDT 2003

Hello Jocelyn. I got something new and interesting point from you (ie)
assigning Security roles to general task than making it as a general task.
We have completely integrated HR-Org structure to workflow. Since our Org
structure is huge the way the workflows are designed and running are
making it as 'General task' , but agents will be determined based on the
role resolution. Is it still the right approach or what impact  would that
be if the tasks
are assigned to security roles and then restricted by Role resolution ?
Below is our example:
Out of 13400 employees only 3500 employees are eligible for Travel and
Expense project. But we donot have a way to identify these 3500 users
( by means of security roles ).I believe that is one of the reason the tasks
related to T&E project have been made 'General task' but handled by role
resolution
to determine the agent.
Thanks
Swami Bala
----- Original Message -----
From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Monday, October 20, 2003 4:18 PM
Subject: Re: No agent assignment after Transports
 
 
> Hi All, Just to clarify - yes you can transport the "general task"
setting.  But this does not happen by default.  Your system needs to be set
up to record these relationships for transport purposes - or else use the
RHMOVE30 etc. reports. Talk to the HR consultants for more details.
>
> By the way, do please remember that where you have security requirements,
it is better to assign tasks to security roles (i.e. activity groups/profile
generator roles created via transaction PFCG) that set general task.
General task should only be used where you truly want anyone to be able to
execute work items from that task, or where other security measures are used
to offset general task.
> Regards,
>         Jocelyn Dart
> Consultant (SRM, EBP, Workflow)
> and co-author of the book
> "Practical Workflow for SAP"
> SAP Australia
> email: jocelyn.dart at sap.com
> phone: +61 412 390 267
> fax:   +61 2 9935 4880
>
>
>
>
> -----Original Message-----
>> From: ASSY, SOSTHENE [mailto:s.assy at afdb.org]
> Sent: Tuesday,21 October 2003 1:11 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: No agent assignment after Transports
>
>
> The system does not applied this transport. You have to classify  the task
> as general task after transportation.
>
>
>
> -----Original Message-----
>> From: Kouw, FA - SPLTX [mailto:fa.kouw at td.klm.com]
> Sent: Monday, October 20, 2003 9:01 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: No agent assignment after Transports
>
>
> Swami,
>
> We're on 4.6C and I also use the general task classification as possible
> users for standard tasks. When
> classifying a standard task as 'general' a customizing request is created,
> which after transport results in a
> standard task that has classification 'general' in the target client(s).
To
> be short: in my case this works
> well.
>
> Maybe you have to refresh the index after transportation (when displaying
> the agent assignment press button
> 'refresh index'?
>
> Regards,
>
> Fred Kouw
>
> Swam_in wrote:
>
> > Hello Carolyn,
> >
> > In the last implementation, we had an Org. structure assigned to the
> > workflow. So we too proceeded
> > the same way as you mentioned ( ie) creating agent assignment in the
> target
> > system. But now we have completely
> > integrated HR-Org into the workflow and we have the luxury of
determining
> > the agent assignment through role resolution.
> > So we are trying to convert some of the standard tasks into 'General
task'
> > and let the role resolution determine the agents.
> > When we move this standard tasks to the target system that's were we are
> > running into troubles. Probably we should try transporting
> > the table ( HRP1217) entries or do it manually.
> > Thanks for your feedback.
> > Swami Bala
> >
> > ----- Original Message -----
> > From: "Carolyn Fuller" <fuller at MIT.EDU>
> > To: <SAP-WUG at MITVMA.MIT.EDU>
> > Sent: Sunday, October 19, 2003 1:02 PM
> > Subject: Re: No agent assignment after Transports
> >
> > > Swami,
> > >
> > > Depending upon configuration, the agent assignment, "General Task",
for
> > > a dialog step standard task, is not included in transports.
> > >
> > > When we investigated changing our configuration to transport "agent
> > > assignment" with standard tasks, we discovered we would be
transporting
> > > a lot more than we wanted to transport. One of our consultants tried
to
> > > manually add the entry for the standard task of interest in the table,
> > > HRP1217, to the transport, but failed.
> > >
> > > Given this fact we've decided that it makes more sense for the
workflow
> > > developer to manually do the agent assignment after a transport is
> > > imported into a target system.
> > >
> > > Carolyn
> > >
> > > On Sunday, October 19, 2003, at 01:38 PM, Swam_in wrote:
> > >
> > > > I had set some of the standard tasks to 'General task' in the new
> > > > workflow that I created and transported the same to other clients.
But
> > > > all those tasks has no agent assignment in the target client after
the
> > > > transport.
> > >
> > > ----
> > > Carolyn Fuller                               M.I.T.
> > > fuller at mit.edu                       Financial Systems Services
> > > Senior Analyst/ Programmer Peer Leader      W92-210
> > > fax (617) 253-9661                    voice (617) 253-6213
> > > http://fuller.mit.edu/
> > >
> >
> >
>
____________________________________________________________________________
> _____________
> > This inbound message from KPN has been checked for all known viruses by
> KPN IV-Scan, powered by MessageLabs.
> > For further information visit: http://www.veiliginternet.nl
> >
>
____________________________________________________________________________
> _________________
>
>
> **********************************************************************
> This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
you
> are notified that no part of the e-mail or any attachment may be
disclosed,
> copied or distributed, and that any other action related to this e-mail or
> attachment is strictly prohibited, and may be unlawful. If you have
received
> this e-mail by error, please notify the sender immediately by return
e-mail,
> and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
> subsidiaries and/or its employees shall not be liable for the incorrect or
> incomplete transmission of this e-mail or any attachments, nor responsible
> for any delay in receipt.
> **********************************************************************
>
>
____________________________________________________________________________
> _________________
> This outbound message from KPN has been checked for all known viruses by
KPN
> IV-Scan, powered by MessageLabs.
> For further information visit: http://www.veiliginternet.nl
>
____________________________________________________________________________
> _________________
>
>
> This e-mail and any attachment sent with it are confidential and intended
> solely for the use of the individual to whom it is addressed. If you have
> received this e-mail by error please delete it immediately. No reference
> should be made of the information contained in this e-mail.  The views or
> opinions expressed in this message, unless otherwise clearly indicated,
are
> solely those of its author and do not necessarily represent those of the
> ADB.  Unauthorized publication, use, dissemination, forwarding, printing
or
> copying of this e-mail and its associated attachments is strictly
> prohibited.  ADB believes but does not warrant that this e-mail and any
> attachments are virus-free.  You must therefore take full responsibility
for
> checking for viruses therein. ADB disclaims any responsibility and
liability
> arising from your unauthorized use of the contents of this e-mail or your
> failing to ensure that it is virus-free.
>