Approval procedures with workflow

[Dror Weiss]

Thank you very much for your help.
 
Another option I'm trying before that is to set the request to a
distinguished status and start the workflow only if the request is at its
original status.
If this fails I'll try your method.
 
Thank you
Dror
 
----- Original Message -----
From: "Zmudzin,Tomasz,VEVEY,GL-IS/IT" <Tomasz.Zmudzin at nestle.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Tuesday, May 20, 2003 1:23 PM
Subject: Re: Approval procedures with workflow
 
 
> You can have a check function module registered in the linkage of your
> workflow and your event. When the event is raised, the check function
module
> is called before the raising a new workflow. In this FM you can check, if
> there's another workflow instance already running (i.e. in status "In
> process" / "Error?") for your object (e.g. via a call to
> SAP_WAPI_WORKITEMS_TO_OBJECT).
>
> If there's another workflow in process for your object, your check FM
needs
> to raise an exception. In this case the new workflow will not be started,
> and your existing process will continue. If there's no other workflow
> running for your object, your FM needs to finish without any exceptions. A
> new workflow instance will then be started.
>
> Hope this helps,
> Tomasz
>
> -----Original Message-----
>> From: Dror Weiss [mailto:drorw at hotmail.com]
> Sent: Tuesday,20. May 2003 12:17
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Approval procedures with workflow
>
>
> Hello everybody,
>
> I have a general question regarding approval procedures with workflow.
> In the example I'm dealing with the case is approval of an employee trip
by
> several functions in the company management.
> The general scheme of the workflow I created is a loop that occurs until
the
> trip is finally approved or the initiator chooses to withdraw his approval
> request. Every time a rejection occurs the trip request is sent back to
the
> initiator for repairs and the approval procedure starts over.
> I implemented this process using the 'loop-until' step in the workflow
> template.
> The triggering event for the workflow is EmployeeTrip.Requested (business
> object BUS2089).
>
> The big problem is that when the initiator changes the trip request after
a
> rejection occurs the triggering event is raised and another instance of
the
> workflow is created - in parallel to the original workflow which is still
in
> progress. Of course this situation is very undesirable.
>
> Another possibility I considered is to stop the workflow and send the trip
> request back to the initiator. When the initiator repairs the request a
new
> workflow for the repaired request will start. This method is very
> problematic since the history and attached documents will not be preserved
> from the original workflow.
>
> If any of you have experience with similar cases or have any idea please
> respond.
>
> Thanks in advance,
> Dror Weiss
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>