R/3: Problem with revising a purchase requisition after rejection
Danny Kelly
danielmkelly at optushome.com.au
Sun Jul 8 10:14:55 EDT 2001
Arnoud,
I have a couple of different work arounds for the problem you are having. It
generally depends on what the client wants as to how much I put in the
workflow. You don't need to worry about additional EVENTS. But you need to
create a new subtype so you can add the Release strategy as an attribute and
some new methods. The bits I generally add in to the workflow are the
ability for the Originator to resubmit the requisition after it has been
rejected without making any changes, force the Manager to enter a rejection
message (either as an attachment or as a new text message on the requisition
called 'Rejection Reason') and to give the option of either returning the
requisition to the originator when it is rejected or having it step back
down the release strategy if there are multiple approvers. For example, if
the requisition is rejected by the third approver in the strategy it goes
back to the previous approver instead of the user who created the
requisition. This is a bit more involved, not necessarily difficult, but
requires a number of background steps. I haven't included that option below.
I have a rough flowchart of how I set up the workflow to cater rejections
but it's on another laptop and I can't get access to it at the moment.
However, the process I use to get around your problem is as follows:
* create a new subtype with the attribute 'ReleaseStrategy'
* move the ReleaseStrategy attribute to a container element called
'OrigReleaseStrategy' in the binding of the triggering EVENT.
* Placed all the steps of the workflow inside a loop. I usually use a flag
called 'ProcessComplete'. This loop will control the resubmission of a
rejected workflow.
* Whenever the requisiton follows a path other then rejected set the
ProcessComplete to 'X' to end the loop.
* in the path that follows the rejection you can set up another loop which
checks to see if a rejection message has been entered on the requsition. If
not send a workitem back to the approver stating the rejection message has
not been entered. You will need a background step which goes and checks if
the message has been entered.
* after the reject message loop is completed create another loop to contain
the change requsition task. This loop allows the user to go back and change
the requsition after they have exited the change requsition task and realise
they may have made a mistake. Basically this is a safety measure for when
they exit incorrectly. The next three points are also inside this loop.
* when they do exit the change requsition task a check is performed (by a
condition step) between the OrigReleaseStartegy and the ReleaseStrategy
(which will change if the requsition was significantly changed).
* If the requsition was changed significantly then the flags which control
the various loops must be set to allow the workflow to finish as a new one
will start by vitue of the requsition being changed significantly (both
releaseStepCreated and SignificantlyChanged EVENTS will be published, the
first will start the new workfow the second will have no effect as the task
it effects was actioned earlier).
* if it wasn't significantly changed then the other side of the condition
will present a DECISION step. This DECISION step will give the options of
RESUBMIT, CHANGE and COMPLETE. The RESUBIT option will set the flag to end
the loop in which the change task sits and go back to the original release
task. I also have another container element defined called 'RESUBMITMESSAGE'
which is part of the initial workitem message. First time through it is
blanks, If the user selects RESUBMIT I set it to 'RESUBMITTED' so that it
appears in the message advising the approver the message is a resubmission.
If they select CHANGE then the workflow loops back to the change task to
allow the user to have another go at changing the requsition. If they select
COMPLETE all flags are set and the workflow completes. In this case the user
must do something manually to the requisition. ie. cancel it.
This might make more sense with a diagram but basically SAP does not handle
rejections very well. My requisition workflows are made up primarily with
handling the times the requsition is rejected. In most organisation I have
found that rejections do not happen often. But when they do you need to be
able to cover different scenarioes.
I hope the above gives you some ideas to go on. If you want the diagram let
me know and I will either quickly create a new one if I can't get hold of
the old one.
Regards
Danny
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of Van
Heerde, Arnoud
Sent: Friday, July 06, 2001 11:01 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: R/3: Problem with revising a purchase requisition after rejec
tion
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20010709/4a20ac4a/attachment.htm
More information about the SAP-WUG
mailing list