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

[Stephan Becker]

Why wouldn't you use FIPP.CHANGED instead?
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
Thomas Schroff
Sent: 26 June 2000 21:17
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Refiring of the event FIPP.CREATED after changing a parked
docum ent with the WFReleaseFlag cleared
 
 
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.
 
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
 
Professional Services
IXOS Software AG
Technopark Neukeferloh
 
Bretonischer Ring 12
D-85630 Grasbrunn / M|nchen    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
> >