Purchase requisition events

[Stephan Becker]

Felix,
 
as per solution 1, you're right, the check function modules will not see
each other as workflow instances. But you can delay that check until the
first step of the workflow. Just start the workflows and let them wait for a
minute or so to let everyone catch up with slow update tasks etc. Then
perform the check and ensure you keep one instance running. That should do
it.
 
Stephan Becker
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
Hassine, Felix
Sent: 09 May 2000 16:42
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Purchase requisition events
 
 
Hi all.
 
Thanks for the numerous responses.
Here are the tests I have done.
 
        1- Create a FM to choose 1 item among all those generated. The FM is
all right it reads the table SWWWIHEAD and the container of started items
for the same object, but the overall method does not work because the check
FM is executed in the context of the PR posting, that is BEFORE the PR is
posted. In other words, if 5 items are present in the PR, it starts the FM 5
times, and none of these instances "see" that a workflow was started. So
this solution does not work.
 
        2- I tested the OMEB transaction code, proposed by Philip. It does
not work. I think that this is probably the easiest solution, if it had
worked. In fact, triggering the overall flag annihilates the release
strategy.
 
My temporary solution: I have set up in the beginning of the workflow a step
that checks (if box)  if the item is the first item of the PR. If it is not
true, it terminates the WF.  I don't see anything better for the moment...
 
Regards,
 
        Felix
 
> -----Original Message-----
>> From: Stephan Becker [SMTP:stephan.becker at walldorftech.com]
> Sent: Tuesday, May 09, 2000 10:46 AM
> To:   SAP-WUG at MITVMA.MIT.EDU
> Subject:      Re: Purchase requisition events
>
> use function module rzl_sleep to pause for a few seconds and try several
> times. still a lot less overhead than starting a workflow. rzl_sleep calls
> a
> C system function and has very very little overhead.
> stephan becker
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
> Patrik vanOdijk
> Sent: 09 May 2000 11:20
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Purchase requisition events
>
>
> There might be a problem with this solution due to synchronisational
> problems.
> For example you have two events triggered for one blocked invoice. When
> the
> check function is run it might not recognize the other event since it is
> not
> "registered" yet. I think we tried this one and ran into the problems
> above.
>
> /Patrik van Odijk
>
>
>
>
> Stephan Becker <stephan.becker at walldorftech.com> on 2000-05-09 09:08:19
>
> Please respond to "SAP Workflow Users' Group" <SAP-WUG at MITVMA.MIT.EDU>
>
> To:   SAP-WUG at MITVMA.MIT.EDU
> cc:    (bcc: Patrik van Odijk/GBG/FRONTEC)
>
> Subject:  Re: Purchase requisition events
>
>
>
>
> try this for size instead:
>
> code a check function module that you put into the event coupling entry
> (swec).  the function module only needs to check if another workflow with
> the same partial key (only the po number) exists already. this is stored
> in
> one of the workflow tables; it escapes me at present which one, but with a
> little investigation, that will be easy to find out.
> In case an entry is found with the same po number, raise an exception in
> the
> check function module, and only one workflow will ever start for any po
> number. then model the first workflow to work for the whole po.
>
> stephan becker
>
>
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
> Everaldo Biselli
> Sent: 08 May 2000 20:39
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Purchase requisition events
>
>
> Hi Felix,
>
> The SAP R/3 works with the purchase requisition item and not with the
> purchase requisition. As far as I know, until release 40B, there was no
> change document that was sensitive for purchase requisition events, it
> just
> works for purchase requisition items. There was no user exits in the
> transaction that create purchase requisitions (ME51) that can be used too.
> In  my opinion, you should create a new Business Object that has  in the
> key only the purchase requisition number, create a new event in this
> object, and activate this event using the ABAP function module
> SWE_EVENT_CREATE. But you should create too a new transaction that
> encapsulates the standard transaction (ME51) and after calling this
> transaction you will include the CODE for calling this event. That's in
> the
> only solution that I can find.
> As you can see this is a complex solution that includes ABAP development
> and some experience constructing workflows. Maybe should be better review
> the process and check if it's possible to change something to help you
> with
> this problem.
>
> Anyway, I hope that this information can help you.
>
> If you need any further information, just let me know.
>
> Everaldo.
>
> ________________________________
> Everaldo Luiz Candolo Biselli
>
> ecandolo at br.ibm.com
>
>
> "Hassine, Felix" <Hassine.Felix at PMINTL.CH> on 08/05/2000 14:32:53
>
> Please respond to "SAP Workflow Users' Group" <SAP-WUG at MITVMA.MIT.EDU>
>
> To:   SAP-WUG at MITVMA.MIT.EDU
> cc:    (bcc: Everaldo Luiz Candolo/Brazil/IBM)
> Subject:  Purchase requisition events
>
>
>
>
> Hi all,
>
>         We need to create 1 workflow instance when a purchase requisition
> is
> created with the blocking flag on. Only 1 should be started, but the
> system
> generates as many events as line items in the workflow. As a result, my
> workflow may start several times, which is not the desired effect
>
> I have tested the "overall" release button in the customizing (Purchase
> Req
> release Strategy), but then no event al all is then generated.
> I have also attempted to create a "change" doc for change document class
> "BANF" , but it works only for CHANGED status, not for CREATE.
>
> Has anybody experienced the same problem ?
>
> Thanks for any clue.
>
> Felix Hassine