Refiring of the event FIPP.CREATED after changing a parked docum ent with the WFReleaseFlag cleared

[Thomas Schroff]

Dear all,
 
if a workflow variant is assigned to a company code of a parked =
document
with the 'WF release necessary flag' cleared (either cleared by the =
object
method 'FIPP.WfReleaseReset' or by using the report RFCORR57 with a
subsequent firing of the event FIPP.DELETED), a relevant change to the
parked document will re-create the event FIPP.CREATED and will set the =
'WF
release necessary flag' in the document header.=20
 
In my opinion this behaviour is to be considered a feature for =
'reanimating'
workflows,
not a bug !
 
Here is a description how to 'reanimate' a workflow:
 
1. The FIPP workflow waits for FIPP.DELETED in a parallel branch
   (see SAP standard workflow WS 10000051)
2. On selectively executing the report RFCORR57, the corresponding =
workflow
instance will
   be completed by a run through the parallel 'FIPP.DELETED' branch, =
and the
'WF release
   necessary flag' will be cleared.
3. A relevant change to the parked document (i.e. text area of a line =
item)
   will then retrigger a workflow instance for processing it.
 
Several customers currently benefit from this 'reanimation =
functionality'.
Please do not encourage SAP to consider this functionality to be a bug. =
 
 
Thank you,
 
Dr. med. Dipl.-Inform. Thomas Schroff
Manager                   =20
 
Professional Services      =20
IXOS Software AG        =20
Technopark Neukeferloh =20
=20
Bretonischer Ring 12
D-85630 Grasbrunn / M=FCnchen    http://www.ixos.de
 
 
 
-----Original Message-----
From: Stephan Becker [mailto:stephan.becker at walldorftech.com]
Sent: Monday, June 26, 2000 11:51 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: FW: FW: FIPP WFReleaseReset doesn't yield expected results
 
 
Thank you very much for your suggestions.
 
I have tried to release the document (FIPP.FlagReleaseSet which
releases the whole document) before resetting the workflow release flag =
with
FIPP.WfReleaseReset, which should make it not eligible for the =
Workflow.
 
Unfortunately, that doesn't do the trick either.. I still can't do
anything apart from changing the document..
 
There is a user requirement that I need to solve that they want to =
release
the parked document from workflow for exception processing that would =
be too
one-off and quirky to model with workflow.
 
If anyone has any other suggestions, I'd love to hear them.
 
As per the duplicate event: In my view, the creation of the =
FIPP.CREATED
event on a change of the document is a bug, and I have created an OSS =
note
for that; I'll keep you posted on the result. In the meantime, I will
probably have to resort to using the check function module to solve the
duplicate event problem..
 
Thanks in advance,
 
Stephan
 
 
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
> AHans
> Sent: 22 June 2000 20:43
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: FW: FIPP WFReleaseReset doesn't yield expected results
>
>
> Here are some of the suggestions to deal with it:
>
> Problem Definition:
>
> 1- If you are using WF for the parked document, document needs to be
> released before you can post, however there is no manual release push
> button
> availble outside WF to do it.
>
> 2- If the document is processed with workflow and is posted, you are =
fine,
> but if there is posting error  and user needs to make a change to the
> document  before  posting  it, the release is reset due to the change =
and
> manual release is not possible, probably a new trigger too.
>
>
>  Issues are:
>
>  -How to release it manually
>  -How to stop the duplicate workflow from started as FIPP.created is
> triggered again.
>
> This is what I would suggest :
>
> 1- Use the change function module to stop the duplicate WF
> 2- Provide a manaual release on a custom  transaction to release the
> document .
>
> In  my flows I  provide all fucntionality in the transaction to =
handle
> erred
> invoice e.g. change( with PO or without as there is a difference), =
post ,
> Release,  so if it is changed, it can be release right there, in your =
case
> you do need the manual release, where ask your process team where =
would
> they
> prefer it. Since you have WF , I would not do  any procesing outside =
the
> flow.
>
> Now how to Release it Manually:  FIPP.RelaseReset may not be working =
for
> you
> as it is a conditional release, you need unconditional Release as =
posting
> will  catch any problems with the document.
>
> Future Issue with this Flow:
>
> Watchout for your closed posting periods(months and years both)
>
> Good luck.
>
> Alan Hans
>
> -----Original Message-----
>> From: Stephan Becker <stephan.becker at walldorftech.com>
> To: SAP-WUG at MITVMA.MIT.EDU <SAP-WUG at MITVMA.MIT.EDU>
> Date: Thursday, June 22, 2000 9:17 AM
> Subject: FW: FIPP WFReleaseReset doesn't yield expected results
>
>
> >I am trying to give the supervisors of my parked document workflow =
the
> >possibility to "release" a parked document from workflow processing =
so
> that
> >they can continue processing it without workflow (in case of =
exceptions
> >where it doesn't make sense to model a flow that will only be used =
once a
> >year).
> >
> >I am using method WFReleaseReset of object type FIPP, which =
correctly
> sets
> >the xwffr field in vbkpf (the parked document header) to blank.
> >
> >However, when I then try to post, complete, or delete the parked =
document
> >manually (i.e. through the normal transactions), the relevant menu =
items
> are
> >blanked out.
> >
> >Even worse, the next time the document is changed, the event FIPP =
CREATED
> >(!) is triggered, which trows the document back into workflow =
processing,
> >which somewhat defies the purpose of the whole exercise..
> >
> >Surely I'm missing something here.. any suggestions are appreciated.
> >
> >Greetings,
> >Stephan Becker
> >