Pur req-release wrkflw
John A Haworth
jhoworth at csc.com
Thu Apr 24 04:59:20 EDT 2008
Hi
Just realised one is for item release one is for overall release. So I
think it should be the 00000038 I should use, but your right it doesnt
seem to work as I would have expected. The action of item rejection by the
Approver, causes the signicantchange event to be issued which cancels the
workflow, and a second event Rejection_start is also issued which triggers
ws65400027. But at this point the initiator of 00000038 is lost (who was
the requisitioner) and the initiator of the 2nd workflow is actually the
Approver. So the requisitioner isnt informed of the approvers decision to
reject.
I would have expected the event REJECTED to be issued when the approver
rejected the requisition item, anyone help with the reason its not?
Thanks
John
CSC Computer Sciences Limited
Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire,
GU11 1PZ, UK
Registered in England No: 0963578
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Florin Wach (gmx)" <florin.wach at gmx.net>
Sent by: sap-wug-bounces at mit.edu
23/04/2008 21:28
Please respond to
"SAP Workflow Users' Group" <sap-wug at mit.edu>
To
"SAP Workflow Users' Group" <sap-wug at mit.edu>
cc
Subject
Re: Pur req-release wrkflw
welcome...
I would use of copy of the standard template anyway, but it seems that the
one having the higher number, is the newer one, even though they look just
the same to me.
Best wishes,
Florin
----- Original Message -----
From: John A Haworth
To: SAP Workflow Users' Group
Sent: Wednesday, April 23, 2008 12:31 PM
Subject: Re: Pur req-release wrkflw
Thanks again for your fast response & info.
Should I be using 00000038 or 20000077?
John
CSC Computer Sciences Limited
Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire,
GU11 1PZ, UK
Registered in England No: 0963578
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Florin Wach" <florin.wach at gmx.net>
Sent by: sap-wug-bounces at mit.edu
23/04/2008 10:43
Please respond to
"SAP Workflow Users' Group" <sap-wug at mit.edu>
To
"SAP Workflow Users' Group" <sap-wug at mit.edu>
cc
Subject
Re: Pur req-release wrkflw
Jup,
this seems to be not working a 100% as designed.
I usually deselect the SignificantlyChanged event as the terminating event
in the workflow pattern (as a copy from the SAP's original), as that event
is always accompanied by the .Rejection_start.
Also the (newer?) template WS20000077 has the same thing.
If you'd like to avoid that, you could also use a check-function module in
the instance coupling of the task TS20000159 that avoids the event
.SignificantlyChanged of beeing processed. Or you'd add a info-rejection
as the first step in the rejection flow.
Best wishes,
Florin
-------- Original-Nachricht --------
> Datum: Wed, 23 Apr 2008 10:22:54 +0100
> Von: John A Haworth <jhoworth at csc.com>
> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
> Betreff: Pur req-release wrkflw
> Thanks for that info.
>
> Continuing on the same workflow. I have an issue with the way this seems
> to be working, could someone please comment?
>
> It seems that when the Pur Req is created and saved, WS0000038 is
> triggered ok, and the approve request is sent to the correct Responsible
> Agent. If that agent then Approves the PReq, the workflow works
correctly
> and the initiator is informed via a wflw task from WS0000038. But if the
> agents rejects the Preq, then event 'SIGNIFICANTLYCHANGED' is raised
which
> cancels down the initial workflow (WS0000038), together with a second
> event REJECTION_START which then triggers a new single step workflow
> (WS65400027)
>
> This doesnt look correct, as cancelling down the initial workflow, means
> that the task 'Negative Confirmation' in WS0000038 doesnt get touched
and
> therefore isnt sent to the initiator (whereas the positive confirmation
> task is run when the Agent approves)
>
> WS65400027 then waits for the event REJECTION_STOP as a terminating
event,
> but the initiator is never informed.
>
> Many Thanks
>
> John
>
>
>
> CSC Computer Sciences Limited
> Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire,
> GU11 1PZ, UK
> Registered in England No: 0963578
>
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to
> any order or other contract unless pursuant to explicit written
agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose.
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>
> "Florin Wach (gmx)" <florin.wach at gmx.net>
> Sent by: sap-wug-bounces at mit.edu
> 21/04/2008 17:39
> Please respond to
> "SAP Workflow Users' Group" <sap-wug at mit.edu>
>
>
> To
> "SAP Workflow Users' Group" <sap-wug at mit.edu>
> cc
>
> Subject
> Re: user exit on Pur req-release wrkflw
>
>
>
>
>
>
> Hi John,
>
> if the box "Assigned agent" is left blank, der Task's standard role
> resolution is used, which is, what's exactly happening there.
>
> Look at the Task definition of TS... under "Rules".
>
> Best wishes,
> Florin
> ----- Original Message -----
> From: John A Haworth
> To: SAP Workflow Users' Group
> Sent: Monday, April 21, 2008 4:49 PM
> Subject: user exit on Pur req-release wrkflw
>
>
> Hi
>
> I am looking at a clients already created workflows. One is the purchase
> requisition release standard workflow WS00000038. They have the purchase
> reqs configured to use the LXM06U12 Customer enhancement to look in a
> customer table for the approver name, that all looks ok.
> But the first step in the workflow that sends the approval request to
the
> approver, has no entry in the 'Responsible Agents' entry box. Yet the
> workflow seems to be sending to the right person?? Surely this is not
> right, and my mental block thats happening more frequently is not
helping!
> Any advice?
>
> John
>
> CSC Computer Sciences Limited
> Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire,
> GU11 1PZ, UK
> Registered in England No: 0963578
>
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to
> any order or other contract unless pursuant to explicit written
agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose.
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080424/a90c00a4/attachment.htm
More information about the SAP-WUG
mailing list