cancel
Showing results for 
Search instead for 
Did you mean: 

WS20000075 - release PO

Former Member
0 Kudos

Hi Folks,

We went last weekend live with this WF for the approval of a PO. There seems to be a problem with starting the flow. When a user creates a PO, the event releasestepcreated is started, but there's an error saying that the import container is wrong.

So I tried to start the WF myself by launching the event manually, and this gives no error. Once the flow has been started for the first time, the second (and third and so on) approval doesn't 't pose any problem.

So it's only by creation of a PO that there seems to be something missing.

And the weirdest thing : On dev and Test (same flow) there's no problem at all...

So I'm hoping there's someone out there who can guide me a bit in the right direction...

thanks in advance !

Accepted Solutions (1)

Accepted Solutions (1)

KKilhavn
Active Contributor
0 Kudos

Have you triple-checked your classification data in the customizing? I don't think this is relevant if you use only one release strategy, and I have no idea if this would be the cause - but it's something that's rather quick to eliminate. Only one strategy should match the document.

I am quite sure there was a report or transaction that could be used to test this (for requisitions, there should be one for orders to then), but I have forgotten which transaction code or report that was. Can't even recall if it was documented in the customizing node documentation or somewhere else.

Former Member
0 Kudos

We checked them several times (me and a colleague) and everything seems ok. We compared with the settings on test, everything seemed the same...

I just did an authorization check for the user, he generated some errors on the documenttype of a PR...

I'm going to try with giving him this authorizations and see what is the result...

Former Member
0 Kudos

Sadly enough, this didn 't solved my problem. Now the flow is started, but he stills deactivate the startevent saying that the import container isn 't correct...

My trace didn 't give any result we could use...

Apparently, the system doesn 't make the link between the PO and the workflow...

Former Member
0 Kudos

Based on what you are saying, I would check the following areas closely:

1. for the triggering event and business object, are you using a custom BO? If so, make sure delegation is setup correctly and use the standard BO.

2. When you run manually, you obviously are giving the import container elements the correct data. So make sure the binding between the WF and the BO are all setup correctly.

3. Could be a timing issue between when the PO is saved (actually saved to the database, not the buffer) and the triggering of the WF. I've seen this happen with custm triggering logic but it wouldn't hurt to try using the event queue and send the WF to the queue for 5 - 10 minutes (giving the database time to commit the data).

I hope this helps.

Derrick

Former Member
0 Kudos

Hi Derrick,

I'm using the standard BO. The binding should be correct, because once I launched the WF manually and the first one in the strategy approves, the same event is triggered and the flow continues.

Using the event queue, I noticed that the event (on creating a PO) is triggered twice -> once correct, once incorrect. The second one causes the triggering event to disable.

So for one reason or another the event is triggered twice....

edit : it's the releasecode that isn 't filled out..

Message was edited by:

Björn Demol

Answers (2)

Answers (2)

Former Member
0 Kudos

Solved !

there was still an entrance in swec for EINKBELEG in production. (this wasn 't the case in dev and test)

due to this, flow was triggered twice, one was incorrect, and the event got deactivated.

after removing this line, no errors occured

thanks everyone for the help, really appreciatre it !

Former Member
0 Kudos

Please check the binding from Event to Workflow. This is standrad and i think it should not give issue. The event linkage is activated and also check that there is no start condition that might hinder you. Please try to test it again I think this will be solved.

Thanks

Arghadip

Former Member
0 Kudos

Hi Arghadip,

I tried that already, but no luck.

When a user creates a PO, and I look in SWEL, the system tells me that there was an error and that the startevent got deactivated. When I look further in SWEL, the system tells me that the import container isn 't correct...

I went to the flow, reactivated the startevent and launched the event by me. This works fine.

I forgot to mention one important thing : last saturday we created a PO with our user, and this didn 't generated any error. So my first tought was that there is a error concerning the roles, but we copied this roles from test to prod, and again, in test there's no error...

Message was edited by:

Björn Demol

Former Member
0 Kudos

If you create the vent manually from SWUE it shows no error that means there is some error with Wflow initiator. I request you to try to create a PO with your user Id. Also please check whether there is any Check FM configured for this or any Start Condition(SWB_COND Tocde) configured for this wflow.

Thanks

Arghadip

martin_nooteboom
Active Contributor
0 Kudos

Hi Björn,

You don't get information about the element that isn't correct? I think there is some kind of user related problem. Because on saturday it worked. You could try and see if you could still create a PO and start a workflow now. Maybe turn on the authorization trace for your user and the user's user maybe it is an authorization problem. Maybe a user compare still has to be done for the new roles?

Regards,

Martin

Former Member
0 Kudos

Hi,

as soon as there's a new PO to be created, I'll try it with my user to check.

Concerning the error : the system only tells me <i>: Import container contains errors (are any obligatory elements missing?)</i>

I don 't know very well how I can look any further on this error, can this be done ?

May I ask what you mean by an authorization trace ?

martin_nooteboom
Active Contributor
0 Kudos

Hi Björn,

I am not sure, but I think I got a bit more info once when I clicked on the error message but I could be mistaken.

The authorization trace is basically the system trace but only on authorizations (first checkbox, "bevoegdheidscontrole" as I am to lazy to log on in english ). Maybe an authorizations expert could check it with you, if you do it for the user for which it doesn't work he can see what is missing.

Regards,

Martin