WS20000077, refuse doesn't follow the wf, significantlychanged dominates

[Former Member]

Hi there

I wrote this tread already in the workflow forum:

I'm looking for someone who runs the workflow for the overall purchase requisition release strategy without additional setups in wf and therefore I guess these forum is good as well.

So could you please reply if you have any clue why the event "significantly changed" from the BO BUS2105 is send before the event "rejected"? In my case it leads to the unattractive situation that the wf is closed and if I don't provide a workaround I can't provide the information to the workflow initiator.

Sure, refusing a purchase requirement is a significant change however the workflow seems to be designed to process the task TS20000163 "Release of requisition cancelled" which doesn't work at the moment.

Thanks in advance,

Dirk

[Former Member]

Hi all,

at the end we modified the workflows.

Deleted the task TS20000161/163 and activate the subworkflow WS654000029.

For the recipients of the informations, where we created some own rules.

Jennies answer is very helpfull as well.

All the best,

Dirk

[former_member581212]

hi,

Please check SAP note 597784...

Which shows all settings in it...and compare it with yours...

Regards

Priyanka.P

[Former Member]

Hi Priynaka

thanks for the quick response.

I run the setup in ECC6.0. Beeing aware that the note 597784 is for enterprise and 4.6c I tried this settings as well. There are some more parameters as stated in the note, so I decided to leave them as they are. For instance I didn't change the event queue setting or the RFC stuff.

However using the older funktion modules "SWW_WI_CREATE_VIA_EVENT" instead of "SWW_WI_CREATE_VIA_EVENT_IBF" and adding the check modules "ME_REL_CHECK_EVENT_PARAM" does not lead to my result.

Please let me add, the standard path with an released purchase requisition is working quite well.

Do you run it in ECC without my mentioned problems? Then I would be glad to compare the settings within SWE2/3 with you.

Thanks in advance,

Dirk

[Former Member]

Hi,

I have the same problem with this event in the PO version in ECC6.0. The story is the same, though. Significantlychanged event is triggered before rejection_started and I could not prevent this. Tried the note mentioned above, did not help.

Do you have any workarounds for that?

Thanks,

Jenny Ozcan

[Former Member]

Hi Jenny,

good to know.

In parallel working to solve the topic with the events (may open a note the next days) we invented a small workarround.

To get the information to the workflow initiator (in my case the guy who created the PRequisition) I use the event within the task directly. So copy the workflow and tasks to an own one (or just change the standard version, however not too nice) and add the event in the task as a trigger event.

The result will be that this task is be processed in parallel to the ending of the workflow via the dominant significantlychanged event.

At least the message could be processed and within the workflow overview this step is considered. So not too bad alternative.

Maybe you watch this tread as I'll update it with the feedback in case I'll get an answer from the note. And check the answers in my second thread within the workflow guru group. There are some other alternatives, like starting another workflow, in the answers from these colleagues.

Good luck and please let me know if you've found another solution.

Dirk

Edited by: Dirk Martin on Sep 3, 2009 8:57 AM

[Former Member]

Hi Dirk, thanks for your message.

OK, here's my solution: It looks like this is a given: significantlychanged is triggered in cancellation and rejection. So what I did, step by step:

1. I removed the third outcome of rejection from 'release of po' step. Now this step has only 2 outcomes: po released and po significantly changed.

2. PO released handles the 'release of po effected' step.

3. PO significantly changed arm starts with a custom activity. Processing status. I created a task and this task has the bus2012 object and 'CHECKPROCSTATUS' method in it. This method checks if EKKO_PROCSTATUS is '08' or not. If it is '08', the po is rejected. The method contains the 'rejected' variable and it is set to 'Y' if the PROCSTAT field is '08'. This field is the only field in EKKO that identifies the PO as rejected or not.

4. After this activity, there is a 'condition' type step. This condition checks if the 'rejected' variable is '08' or not for that particular PO. Outcomes TRUE (PO is rejected.) FALSE (PO is cancelled.)

5. The TRUE arm handles a sub-workflow which is a copy of WS65400030. This is the standard rejection workflow.

6. The false arm handles the 'release of po cancelled' activity. (Task TS20000167)

With this configuration, PO creator gets the rejection message when the PO is rejected and the cancelation message when it's cancelled, although SIGNIFICANTLYCHANGED is triggered in both cases.

Thanks again & regards,

Jenny