Two level PO Approval Workflow

[former_member193103]

Hi Experts,

I am new to sap workflow. I have a requirement to create a workflow for PO approval. The requirement is as follows

When the PO is created, the workflow will trigger and it will go for approval to first level approver ( get a new workflow in SBWP) and when the first level approver release the PO it will go to the second level approver.

I am using a copy of the standard workflow WS20000075. For me when a PO is created it will go for approval to the first approver but when the he release the PO it will not go to the second level approver.

For the start Event I am using Object Type : BUS2012 and Event of the Object  as RELEASESTEPCREATED. I use TS20000166 task and assign both the user in it.

Please see the below screen for your reference.

Start Event

for the first Activity

for Second activity

Please help me to resolve the Issue.

Thanks

Himadri

[StephaneBailleu · Accepted solution]

Hi,

What you want to achieve is the standard behavior of the workflow on PO.

In fact the MM-PUR workflow (PR, Contract, Scheduling agreement) are based on release strategy.

The customizing determines the number of step in the release strategy and then you can either use the rather restrictive standard table to maintain the approvers for each release code or you can use the exit provided by SAP.

Then you only need to turn on the event on the standard workflow, the determination of the agent is done at the task level where there is a standard rule .

This standard rule is only reading the result of the release strategy.

Here under is a resume for some of the MM object the exit structure is where you can fill the specific field of the structure, this structure represents the conditions you can use to trigger one release strategy vs another.

Objet	Description	Autorisation	Exit Structure	Exit Agent	Structure	Workflow
BUS2009	PR Item Based	M_EINK_FRG	M06B0002	M06B0001	CEBAN	WS00000038
BUS2105	PR Overall	M_EINK_FRG	M06B0005	M06B0001	CEBAN	WS20000077
BUS2012	PO	M_EINK_FRG	M06E0004	M06E0005	CEKKO	WS20000075
BUS2013	Scheduling Agreement	M_EINK_FRG	M06E0004	M06E0005	CEKKO	WS20000078
BUS2014	Purchase Contract	M_EINK_FRG	M06E0004	M06E0005	CEKKO	WS20000079

For the PO on the task TS20000166 you'll find the rule AC20000027

I hope that helps

Cheers

Stephane

[former_member193103 · Accepted solution]

Thanks for your reply Stephane.

My Release strategy is working fine.  But when I use the workflow it is giving me Problem

[StephaneBailleu · Accepted solution]

Himadri,

Just why don't you use the standard workflow ?

If you do your determination of the agent in the release strategy the standard workflow will work.

In the screen shot you have provided we can see that you hard coded the determination of the agents

and you do have two steps mandatory, (so place for evolution)

The standard workflow is determining the agents at runtime step by step.

As you can see the task you are using is sending you to a standard transaction for the release, so the workflow don't know that you have achieve the first step, and as you have released the first release code, send an event for the same PO for the second release code.

This (depending of your copy of the standard) shall finish your worfklow and start another one (but it will go to the first approver again)

So either you work with a custom workflow but with decision/or confirmation of the end of processing without a release strategy (then you will have to decide what to do in case of rejection, in case of change in the PO....) or you work with a release strategy and find your approver based on the release step ...

Trying to do something in the middle won't work or you have to make a test to bypass the first level of approval if the release code is ....

and you would have to make conditionnal start based on the release code

Finish you workitem either with an event or with a confirn end of processing

I hope that helps

Cheers

Stephane

[Former Member · Accepted solution]

Hi,

What do you mean problem?

You (or an MM-PUR consultant) should check the release strategies and agent assignment in customizing.

In release codes you define which release codes are affected with workflow, I'm guessing that this is where the problem comes from.

Also there is no need for custom workflow, the entire Business Requirement can be fulfilled 100% with customizing and the standard workflow.

Kind regards, Rob Dielemans