FW: FW: FIPP WFReleaseReset doesn't yield expected results

[Stephan Becker]

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
> >