<html><DIV>
<P>Arnoud,</P>
<P>I had this same problem when I was working on 3.0F. I sent a message to SAP and they sad that they could solve the problem until release 4.0C. The message from SAP was:</P></DIV>
<DIV><STRONG><EM> Reply</EM></STRONG></DIV>
<DIV><STRONG><EM> SAP AG 08.06.1998 08:56:24<BR> Frans,<BR> I am sorry I do not have good news about this problem. A complete<BR> fix for this problem will not be available until 4.0C release. Listed<BR> below is an explanation from SAP AG Quality management about this<BR> question.</EM></STRONG></DIV>
<DIV><STRONG><EM> SAP AG Quality management:<BR> The Reject function, as exists in Workflow, cannot be modeled in<BR> purchase requisitions for 3.1. The solution to the problem described<BR> is more of a functional enhancement and would require a lot of<BR> technical effort. In addition to enhancing the DDIC structures, we would<BR> have to implement change document updates in purchase requisitions.<BR> Workflow interpretation would require enhancements to the function<BR> modules involved.</EM></STRONG></DIV>
<DIV><STRONG><EM> Therefore, there can be no solution in the short term. As agreed with<BR> the program director, Rolf Schulte-Rebbelmund, the enhancement will be<BR> implemented for 4.0C. For the reasons already mentioned, it will not be<BR> possible to work around the problem with customer exits etc.</EM></STRONG></DIV>
<DIV><STRONG><EM> Wish I had better news for you.</EM></STRONG></DIV>
<DIV><STRONG><EM> Regards,</EM></STRONG><BR></DIV>
<DIV>I solved the problem myself doing what you've suggested, that is: store the release strategy on a container element and, after the requisition is changed, I compare the new release strategy with the old one. If they are the same, I am raising the event Significantly Changed manually. This solved the problem and is quite ease to be done.</DIV>
<DIV> </DIV>
<DIV>Flavio.</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>>From: "Raskin, Alon (Soliance)" <ARASKIN@CPS-SATX.COM>
<DIV></DIV>>Reply-To: SAP Workflow Users' Group <SAP-WUG@MITVMA.MIT.EDU>
<DIV></DIV>>To: SAP-WUG@MITVMA.MIT.EDU
<DIV></DIV>>Subject: Re: R/3: Problem with revising a purchase requisition after rejec tion
<DIV></DIV>>Date: Thu, 5 Jul 2001 08:47:38 -0500
<DIV></DIV>>
<DIV></DIV>>You could create your own event (in a subtype) and raise it from you're a
<DIV></DIV>>user exit.
<DIV></DIV>>
<DIV></DIV>>
<DIV></DIV>>Alon Raskin
<DIV></DIV>>Workflow Advisor - Soliance
<DIV></DIV>>
<DIV></DIV>> -----Original Message-----
<DIV></DIV>>From: Van Heerde, Arnoud [mailto:arnoud.van.heerde@sap.com]
<DIV></DIV>>Sent: July 04 2001 10:28
<DIV></DIV>>To: SAP-WUG@MITVMA.MIT.EDU
<DIV></DIV>>Subject: R/3: Problem with revising a purchase requisition after
<DIV></DIV>>rejection
<DIV></DIV>>
<DIV></DIV>>Hi Workflowers,
<DIV></DIV>>
<DIV></DIV>>Case:
<DIV></DIV>>Instead of merely informing a person with a work item (very ugly) that a
<DIV></DIV>>purchase requisition was rejected I would like to offer the user the
<DIV></DIV>>opportunity to revise it or delete it. In case the user revises the PR, it
<DIV></DIV>>may be significantly changed so that a different release strategy is
<DIV></DIV>>necessary. In case it is not significantly changed, the PR is submitted for
<DIV></DIV>>release again.
<DIV></DIV>>
<DIV></DIV>>Problem:
<DIV></DIV>>Event BUS2105.ReleaseStepCreated is only automatically triggered after (in
<DIV></DIV>>fact simultaneously with) significant changes to a PR
<DIV></DIV>>(BUS2105.significantlyChanged). However when a user revises the PR without
<DIV></DIV>>the need for another release strategy, there is no event at all.
<DIV></DIV>>After revision we can create a new work item for the "releaser" by
<DIV></DIV>>triggering the event BUS2105.ReleaseStepCreated from the workflow (that will
<DIV></DIV>>trigger a new workflow). You only know that a PR was not significantly
<DIV></DIV>>changed if the event BUS2105.significantlyChanged was NOT triggered. The
<DIV></DIV>>real problem is thus the fact that there is no event to state that the
<DIV></DIV>>change was not significant. From the event log:
<DIV></DIV>>
<DIV></DIV>>* Initial release step event triggered by standard application
<DIV></DIV>>BUS2105 RELEASESTEPCREATE 05.07.2001 10:13:49 WS01300030
<DIV></DIV>>* Rejection event triggered by standard application
<DIV></DIV>>BUS2105 REJECTED 05.07.2001 10:14:32 WORKITEM
<DIV></DIV>>* Release step event triggered by workflow after revision
<DIV></DIV>>BUS2105 RELEASESTEPCREATE 05.07.2001 10:15:20 WS01300030
<DIV></DIV>>* However significant changes were made so both release step event and
<DIV></DIV>>BUS2105 RELEASESTEPCREATE 05.07.2001 10:15:20 WS01300030
<DIV></DIV>>* significant change event are triggered by standard application
<DIV></DIV>>BUS2105 SIGNIFICANTLYCHAN 05.07.2001 10:15:20 EVENTITEM
<DIV></DIV>>
<DIV></DIV>>One solution may be to add the attribute "Release strategy" to a subtype and
<DIV></DIV>>work with delegation and container operations and condition steps. But is
<DIV></DIV>>there another way? Has anyone had to deal with this kind of problem before?
<DIV></DIV>>
<DIV></DIV>>Any suggestions will be much appreciated.
<DIV></DIV>>
<DIV></DIV>>Best regards, Arnoud van Heerde
<DIV></DIV><br clear=all><hr>Get Your Private, Free E-mail from MSN Hotmail at <a href="http://www.hotmail.com">http://www.hotmail.com</a>.<br></p></html>