Workflows for releasing purchase documents!

Wed Feb 2 08:15:18 EST 2005

Hi Mark!
You saved my life. :) It was missing the significantlychanged terminating event.:)

Regarding this workflow I have an another problem, maybe you could help me.:)
After the final release I have to send a message to a specific user. For this I've created a condition in my workflow which checks the release status of the purchase document. The release status it's not a container element, so I defined in the task end workflow container. I've redefined the method singlerelease filling the new container element too. The event container contains the new element, but when is copied in the workflow container, then the new element disappears. The release status is an export parameter from the task container to the wf container. 

Any idea?

Thx
Zsolt

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mark Pyc
Sent: Wednesday, February 02, 2005 1:22 PM
To: sap-wug at mit.edu
Subject: RE: Workflows for releasing purchase documents!

Then it sounds like you're missing some logic to handle cancelling the 
Workflow. Possibly you don't have an appropriate 'Wait for Event' or 
equivalent in the process for 2nd level release..?

From: Márton Zsolt <Zsolt.Marton at t-systems.co.hu>
Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Subject: RE: Workflows for releasing purchase documents!
Date: Wed, 2 Feb 2005 12:55:02 +0100

Hi Mark!
You are right, the solution is not an ordinary thing. The customer wants to 
stop the workflow, when a release is canceled, but after changing the 
purchase document, they need to restart using a transaction code.
My workflow solution rests on the standard workflows (WS00000038, WS20000075 
and WS20000077), the only exception is this check function.
The function is working in the following way:
	When the release step is created, I'm checking the old and new value of 
FRGKZ (Release indicator) in the tables CDHDR (Change document header) and 
CDPOS (Change document items)). After that I select the release status from 
the T16FK with my old and new value. If the new value is less than the old 
value the workflow must be stopped. On the other case, the event is 
triggered.

The function module is working fine when I'm releasing and canceling 
requisition items (release by itmes), but when the release is canceled at 
the first level (overall release), the workitem concerning the second level 
release is still on my inbox.:(

Regards
Zsolt

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of 
Mark Pyc
Sent: Tuesday, February 01, 2005 6:21 PM
To: sap-wug at mit.edu
Subject: RE: Workflows for releasing purchase documents!

G'day Zsolt,

Yep, I've got plenty of ideas. Too many in fact to list here without a
better description of your problem.

You need to look at your design, explain what is in place and how you are
attempting to control the cancelling of the worklow(s?). It sounds like you
have a very bespoke/custom solution and so without knowing the solution it's
hard to comment.

To get a decent answer here it's best if the problem is as specific as
possible. It also helps if you explain what testing you have done, and what
alternatives you have already tried.

Also if you are not already familiar with the standard PReq / PO release WFs
read up on them. It's not typical to have the second stage release Workitem
existing before the first is already released. If you have a radically
different design and can't get it working, explain it and explain why you've
designed it the way you have.

Sorry if this sounds negative. I don't mean to be unhelpful.

Have fun,
Mark

From: Márton Zsolt <Zsolt.Marton at t-systems.co.hu>
Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Subject: RE: Workflows for releasing purchase documents!
Date: Tue, 1 Feb 2005 17:25:11 +0100

Hi Mark!

Sorry for belated reply!

I've created the check function controlling the events and the existing wf
instances, but I hit a new problem:
If the release strategy require two release steps and I cancel the release
after the first level, the workitem concerning the second release step
remains in the agents inbox.

Any idea?
Regards
Zsolt

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
Mark Pyc
Sent: Tuesday, January 25, 2005 5:38 PM
To: sap-wug at mit.edu
Subject: RE: Workflows for releasing purchase documents!

G'day Zsolt,

How are they manually retriggering?? Do they raise an event or start
directly?

If they don't use the event then you simply need to filter the event on
subsequent raises. Easy enough with a check function looking for existing WF
instances - if any exist, don't start another one.

The usual story, a bit more info will help.

Have fun,
Mark

PS I'm not asking any 'Why' questions here, I'm assuming you've already done
that.

From: Márton Zsolt <Zsolt.Marton at t-systems.co.hu>
Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Subject: Workflows for releasing purchase documents!
Date: Tue, 25 Jan 2005 16:46:02 +0100

Hi all!

One of our customers - they are using standard workflows for releasing
purchase documents   for a long time - request is to change the workflows in
a such a way, that workflow is started automatically only at the first time,
when the release step is created; when the document is created. That is to
say, they don't want to restart the workflow when the release step is
canceled. In that case they want to start manually. Does anybody know a good
solution to this problem?
The problem is not how to start manually the workflow (they are already
using this), but how to not start when the release is canceled.

My idea is, to create a new starting event, but in that situation, my
workflow will run just once, because at the second level the workflow is not
triggered, the release step is not created.

Any idea is welcome
Regards
Zsolt

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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