R/3: Problem with revising a purchase requisition after rejec tion

[Van Heerde, Arnoud]

Hi Flavio/ Alon,
 
Thanks for your suggestions, but a user-exit can't do the trick because you
only know a PR was not significantly changed if the event
BUS2105.significantlyChanged was not triggered. Triggering your own event in
a user-exit will not help because it may be that somewhere else in the
program event BUS2105.significantlyChanged is still triggered. Furthermore
with SMOD I haven't found a user-exit after the calling of function module
ME_REL_EVENT_EBAN, that creates all the events.
 
In order to compare the release code before and after the change I would
like to call the BAPI BUS2105.GetReleaseInfo but the information is returned
in a multi line container element. And I can't use two multi line container
elements for comparison in a condition step.
 
Does anybody have a suggestion on how to move the first row in a multi line
container element to a normal container element, using a container operation
in workflow?
 
Any help will be much appreciated.
 
Best regards, Arnoud van Heerde
 
 
-----Original Message-----
From: Flavio Oliveira [mailto:oliveiraflavio at hotmail.com]
Sent: Friday, July 06, 2001 12:52 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: R/3: Problem with revising a purchase requisition after rejec
tion
 
Arnoud,
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:
          Reply
          SAP AG                         08.06.1998  08:56:24
          Frans,
          I am sorry I do not have good news about this problem.  A complete
          fix for this problem will not be available until 4.0C release.
Listed
          below is an explanation from SAP AG Quality management about this
          question.
          SAP AG Quality management:
          The Reject function, as exists in Workflow, cannot be modeled in
          purchase requisitions for 3.1. The solution to the problem
described
          is more of a functional enhancement and would require a lot of
          technical effort. In addition to enhancing the DDIC structures, we
would
          have to implement change document updates in purchase
requisitions.
          Workflow interpretation would require enhancements to the function
          modules involved.
          Therefore, there can be no solution in the short term. As agreed
with
          the program director, Rolf Schulte-Rebbelmund, the enhancement
will be
          implemented for 4.0C. For the reasons already mentioned, it will
not be
          possible to work around the problem with customer exits etc.
          Wish I had better news for you.
          Regards,
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.
 
Flavio.
>From: "Raskin, Alon (Soliance)"
>Reply-To: SAP Workflow Users' Group
>To: SAP-WUG at MITVMA.MIT.EDU
>Subject: Re: R/3: Problem with revising a purchase requisition after rejec
tion
>Date: Thu, 5 Jul 2001 08:47:38 -0500
>
>You could create your own event (in a subtype) and raise it from you're a
>user exit.
>
>
>Alon Raskin
>Workflow Advisor - Soliance
>
> -----Original Message-----
>From: Van Heerde, Arnoud [mailto:arnoud.van.heerde at sap.com]
>Sent: July 04 2001 10:28
>To: SAP-WUG at MITVMA.MIT.EDU
>Subject: R/3: Problem with revising a purchase requisition after
>rejection
>
>Hi Workflowers,
>
>Case:
>Instead of merely informing a person with a work item (very ugly) that a
>purchase requisition was rejected I would like to offer the user the
>opportunity to revise it or delete it. In case the user revises the PR, it
>may be significantly changed so that a different release strategy is
>necessary. In case it is not significantly changed, the PR is submitted for
 
>release again.
>
>Problem:
>Event BUS2105.ReleaseStepCreated is only automatically triggered after (in
>fact simultaneously with) significant changes to a PR
>(BUS2105.significantlyChanged). However when a user revises the PR without
>the need for another release strategy, there is no event at all.
>After revision we can create a new work item for the "releaser" by
>triggering the event BUS2105.ReleaseStepCreated from the workflow (that
will
>trigger a new workflow). You only know that a PR was not significantly
>changed if the event BUS2105.significantlyChanged was NOT triggered. The
>real problem is thus the fact that there is no event to state that the
>change was not significant. From the event log:
>
>* Initial release step event triggered by standard application
>BUS2105 RELEASESTEPCREATE 05.07.2001 10:13:49 WS01300030
>* Rejection event triggered by standard application
>BUS2105 REJECTED 05.07.2001 10:14:32 WORKITEM
>* Release step event triggered by workflow after revision
>BUS2105 RELEASESTEPCREATE 05.07.2001 10:15:20 WS01300030
>* However significant changes were made so both release step event and
>BUS2105 RELEASESTEPCREATE 05.07.2001 10:15:20 WS01300030
>* significant change event are triggered by standard application
>BUS2105 SIGNIFICANTLYCHAN 05.07.2001 10:15:20 EVENTITEM
>
>One solution may be to add the attribute "Release strategy" to a subtype
and
>work with delegation and container operations and condition steps. But is
>there another way? Has anyone had to deal with this kind of problem before?
 
>
>Any suggestions will be much appreciated.
>
>Best regards, Arnoud van Heerde
 
 
  _____
 
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
<http://www.hotmail.com> .
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20010706/dd032800/attachment.htm