WF_TASK ALLAGENTSOFTASKGETANDDISPATCH

[Susan R. Keohan]

Hi Mike,

Thanks for the response.  I suppose in some scenarios it would be reasonable to send a workitem to 
someone who is not active yet.

In our case, we do set up substitutions for users who are leaving (if we know they are) but we do 
not do this systemically.  And there is always the odd employee who just takes off for parts 
unknown, and sometimes it can take a while to find out that they flown the coop.  Although why 
anyone would want to do that is beyond me ;).

Anyhow, thanks very much for reaching back to some reading about Release Notes.  I appreciate the 
feedback!

Cheers,
Sue


Michael Pokraka wrote:

> Hi Sue, 
> I should have thought of this before, but that is actually by design: You
> (well, someone else) might want to send a WF to someone who isn't active yet,
> but when their ID gets activated they have work in their inbox. I vaguely
> remember reading that in the 6.20 release notes or somewhere. 
> A good process would be to set up a substition when a user is locked/delimited.
> 
> Cheers
> Mike
> 
> 
> --- "Susan R. Keohan" <keohan at ll.mit.edu> wrote:
> 
>>Well, for what is is worth, OSS has stated that:
>>
>>>From my understanding BC-BMT-WFM layer
>>>does not perform any checking in order to prevent a Workitem being
>>>delivered to a Agent which User is Locked: USR02-UFLAG (User Lock
>>>Status).
>>
>>It seems counter-productive to me that I am allowed to route a workitem to a
>>user who is locked and 
>>delimited.  Is this just me ?  Of course, there are  work-arounds, but if
>>anyone else has 
>>experienced this problem, I would be interested to hear how you dealt with
>>it.
>>
>>Thanks,
>>Sue
>>
>>Susan R. Keohan wrote:
>>
>>
>>>Hi Mike,
>>>
>>>What's interesting is that in our Dev environment, which is not 
>>>necessarily the best place for testing :), I've had the following 
>>>results...
>>>
>>>USERID_A, name John Smith, no PA0105 record, can be selected either by 
>>>userid or by last name in the drop-down.
>>>
>>>USERID_B, name Michael Doe, with valid PA0105 record, can be chosen by 
>>>entering USERID_B in the entry screen, but *not* by entering 'Doe' in 
>>>the drop-down.
>>>
>>>USERID_C, name Mark Jones, with delimited PA0105 record, can be chosen 
>>>by entering USERID_C in the entry screen, and also by entering 'Jones' 
>>>in the drop-down.
>>>
>>>Of course, it would be nice if I had consistent data in Dev to work 
>>>with.  I suspect I need to spend some quality time with OSS.
>>>
>>>Thanks!
>>>Sue
>>>
>>>Michael Pokraka wrote:
>>>
>>>
>>>>Hi Sue, If you manually delimit 105, does it behave as expected? If so 
>>>>it should become
>>>>a query for the HR people rather than user admin/workflow.
>>>>I'm curious, so could you let us know the outcome? Cheers
>>>>Mike
>>>>
>>>>--- "Susan R. Keohan" <keohan at ll.mit.edu> wrote:
>>>>
>>>>
>>>>>Hello WF'ers,
>>>>>
>>>>>We are on 4.6c, Support Pack level 39.  We have used the wizard 'Choose
>>>>>Agent' to provide a dialog box to certain users(Agents A)  which will 
>>>>>allow them to choose the next
>>>>>agent(Agents B) in a subsequent workflow step.  This creates a task 
>>>>>which calls the method
>>>>>ALLAGENTSOFTASKGETANDDISPATCH of object WF_TASK, which, in turn, 
>>>>>calls function module
>>>>>SWU_WF_TASK_DISPATCH.
>>>>>
>>>>>However, I've discovered that Agent A may enter, or select via the 
>>>>>dropdown,
>>>>>a last name or username of for Agent B, whose SAP UserID is locked 
>>>>>and delimited (but not deleted). I've examined the SU01D records, and 
>>>>>they are indeed locked and delimited, the personnel records are
>>>>>'withdrawn' and delimited, but the PA0105 infotype records are *not* 
>>>>>delimited.
>>>>>
>>>>>It's unfortunate for Agent A that they can select people (Agent B) 
>>>>>who are no
>>>>>longer here.  I'm about to enter an OSS message, but thought I would 
>>>>>try our experts on the
>>>>>SAP-WUG first.  Has anyone come across this error before ?
>>>>>-- 
>>>>>Susan R. Keohan
>>>>>SAP Workflow Developer
>>>>>MIT Lincoln Laboratory
>>>>>244 Wood Street
>>>>>LI-200
>>>>>Lexington, MA. 02420
>>>>>781-981-3561
>>>>>keohan at ll.mit.edu
>>>>>
>>>>>_______________________________________________
>>>>>SAP-WUG mailing list
>>>>>SAP-WUG at mit.edu
>>>>>http://mailman.mit.edu/mailman/listinfo/sap-wug
>>>>>
>>>>
>>>>
>>>>Michael Pokraka
>>>>Workflow Connections Ltd.
>>>>Tel.: +44 (0)7786 910 855
>>>>_______________________________________________
>>>>SAP-WUG mailing list
>>>>SAP-WUG at mit.edu
>>>>http://mailman.mit.edu/mailman/listinfo/sap-wug
>>>>
>>>
>>-- 
>>Susan R. Keohan
>>SAP Workflow Developer
>>MIT Lincoln Laboratory
>>244 Wood Street
>>LI-200
>>Lexington, MA. 02420
>>781-981-3561
>>keohan at ll.mit.edu
>>_______________________________________________
>>SAP-WUG mailing list
>>SAP-WUG at mit.edu
>>http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 

-- 
Susan R. Keohan
SAP Workflow Developer
MIT Lincoln Laboratory
244 Wood Street
LI-200
Lexington, MA. 02420
781-981-3561
keohan at ll.mit.edu