Decentralised Material Master Creation Workflow

[Former Member]

My company wants to put in a workflow to create materials, I have been working on some ideas on and off over the last few weeks, but I am struggling to finalise the solution.

The business wants a decentralised system whereby various departments create various views of the material, i.e. suuply chain create the purchasing views, material control creates the MRP and work scheduling views etc.

I have no porblem building the basic workflow definition, but I am struggling with the part where I have to split up the various maintenance views by department.

I am using BUS1001006 as my main business object and I have tried 2 different approaches, neither of which is working exactly as I want it too:

Firstly I am triggering the workflow when a user creates the basic data view of a material, the workflow should then route the remaining MM views/screens to various depts.

1... I have tried to use the method GETMISSEDVIEWS with a fork into subsequent steps using method CREATEVIEWS. This doesn't seem to work since the method CREATEVIEWS seems to insist that the user creates ALL the missing views not just some of the missing views he/she is responisble for. This results in the work items dissappearing from the inboxes of others in the fork.

2... I have tried to simply create a fork into subsequent stetps using the method CREATE but for some strange reason when I use this method the material number does not come to the CREATE task even though there is binding from &BUS1001006& -> &_WI_OBJECT_ID& in my workflow step.

If someone can help me get past either of these two obstacles I'll be sorted

many thanks.

Edited by: Neil Ward on Nov 16, 2010 2:14 PM

[pokrakam · Accepted solution]

G'Day Neil,

I believe it should be possible without coding, but memory is very rusty as my more recent work in this area has been completely bespoke. The CREATEVIEW method should be called using dynamic parallel processing. You may want to put this in a subworkflow so that you can easily introduce different behaviours for different views. This way each view is processed independently.

Material masters are usually highly individualised processes, which is why I assume no standard SAP flow exists. Some can be cobbled together without code, and others are a little more complex. I've spent months and even years building material master processes at various customers.

Cheers,

Mike

[Former Member · Accepted solution]

Hi Mike and thanks for the response.

I'm willing to persue either of the 2 methods I outlined in my original post to achieve a working solution.

In the case of the CREATEVIEWS method, would you mind elaborating a bit more on parallel processing, i.e. how exactly do I set this up?

I'm a bit of workflow noob, having done the SAP course and set up a few standard workflow using templates I know my round the funcitonality but I'm no seasoned pro. This is the first workflow I'm having to build myself and as such I'm a little shaky.

I greatly appreciate the help from you guys

[pokrakam · Accepted solution]

Oh dear, material master is pretty much the deep end of workflow but don't let that stop you.

Have a look through the help on dynamic parallel processing. BAsically if you have a table of elemetns you create one task (or subworkflow) for each item. This is defined in the miscellaneous tab and the binding defines which single recipient container element each entry in the source table container element is bound to.

[Former Member]

Hi Neil,

So you have to send the same work item to multiple user's and if any one open's the work item, it will disappear's from other's work item right?

If you want to prevent this instead of using fork step, use the Multiline element option in the Miiscellaneous option of the Activity step.

It will send the individual work item to each user's of the workflow container.

Thanks,

Viji.

[Former Member]

Hi,

thanks for the response, I'm not sure if thats the issue, I think the issue is to do with how the methods GETMISSEDVIEWS and CREATEVIEWS work, let me try and explain...

First I execute the method GETMISSEDVIEWS in a workflow step, this method determines all the missing views and populates table MOFF with each missing view, the field STATM holds the value for each type of view (D = MRP, A = work scheduling etc) It then creates an available object for each missing view in the workflow container.

The method CREATEVIEWS then uses these available objects as an input and prompts the user to try and create each missing view.

This is where the problems comes in ... in my workflow users are only permitted to create SOME of these views, not ALL of them. however when they process their workflow step, create the views which they are authorised to create and then save, the workflow tries to get them to create the other views, which of course fails, if the user tries to back out, the system attempts to loop through each remaining view until it reaches the final one and then only allows the user to back out to the inbox. After this it seems to think the user has processed the other views and then removes all the work items from others inboxes.

If I could figure out how to limit the available objects for processing to the various parts of the fork, (or similar restriction) I believe I could have a working solution.

have you ever created a material master workflow before, any ideas?

[Former Member]

Hi,

You wrote,

in my workflow users are only permitted to create SOME of these views

So you have the views that needs to be executed by the user. Like for user1 some A, B and C views only to be executed

For User2 A, C and D only needs to be executed. If you have the User and Views information's, then you can create the method to handle this.

In the method you can check the user against the View. Take the current view and user. If the user needs to be execute the current view, then allow it. otherwise skip the task.

Thanks,

Viji.

[Former Member]

Thanks again,

I'm not an ABAPER, and I do not want to resort to ABAP to solve this problem... surely this must be possible to do without writting a custom method?

To be honest I would prefer to go with my second scenario, simply using the CREATE method of BUS1001006, but why does it not pass the material number to the workflow item even though there is a binding.

anyone?

[Former Member]

Hello,

Developing workflows without ABAP, that's not going to be easy.

You say:

2... I have tried to simply create a fork into subsequent stetps using the method CREATE but for some strange reason when I use this method the material number does not come to the CREATE task even though there is binding from &BUS1001006& -> &_WI_OBJECT_ID& in my workflow step.

The binding should work. I assume &BUS1001006& is the on the workflow side? Check in the workflow log if it's instantiated, and if that happens before that step.

regards

Rick Bakker

hanabi technology

[Former Member]

Hi Neil,

Problem lies wit hthe import parameter of CREATEVIEWS ,since you have fetched the missed views by using GETMISSEDVIEWS, it will return you all the missed views.

In the next step, you are passing the 'MissedViews' as such in the import parameter of CREATEVIEWS, which will force user to create all the missed views.

You need to modify this MissedViews once you have got it from GETMISSEDVIEWS.Write a background step as import parameter MissedViews and export it back to workflow with the required views only. You have to write the logic in the method to get the desired views of that material.

Now since you have updated MissedViews structure, you can pass it to CREATEVIEWS and user wil lcreate only desired views.

Hope this helps.

Sangvir Singh

[Former Member]

Hi Rick,

I fear you are right, I guess SAP's claim that their workflow tool does not require programming experience is true, if you work for the ACME company!

Thing is what I'm trying to do should be fairly simple... I just can't seem to understand why the CREATE method doesn't auto-populate the material number field during runtime?

As you've suggested, I've looked into the workflow log and then into the container of the workflow item, the material number is coming through, I can see it next to the &BUS1001006& BO.... so the binding does work, it just isn't populating the screen field. strange.

I've done a few more tests to try and learn more... I have created my own method in my subtype and simply called tcode MM01, if I place this into my workflow the same thing happens, although the binding brings the material number into the workflow container it doesn't populate the screen field.

Then I tried to use the DISPLAY method to see if there is a bug of some sort in my workflow, this works fine and with exactly the same binding it populates the screen field.

so for some strange reason, if you use MM01 in your method it just doesn't populate the material number field.

[Former Member]

Hi Neil,

I'm getting a bit confused here. Correct me if I'm wrong:

- you have an instance of a BUS1001006 object in your workflow

- you have step which calls a task which calls the method CREATE of BUS1001006

- I assume you have a binding of the BUS1001006 object instance into that step/task

Is there a problem with what's being passed back to the workflow? What is this "screen field"?

regards

Rick Bakker

hanabi technology

[Former Member]

correct on all 3 counts Rick.

The screen field I'm referring too is the material number field on the MM01 transaction, the workflow is not populating the field with the material number even though it is instanced in the workflow and there is binding in the step to pass the material number fromt he workflow container to the task container.

I'm sorry if any of this is confusing, I'm fairly new to workflow and I may be not understanding the way these things work, but I assumed that if there is an instance of the BO in my workflow and if I bind &BUS1001006& to &_WI_OBJECT_ID& in the task container it would automatically populate the material number field in MM01 with the material being instanced in the workflow?

Edited by: Neil Ward on Nov 17, 2010 1:07 PM

[Former Member]

Hi Neil,

" if I bind &BUS1001006& to &_WI_OBJECT_ID& in the task container it would automatically populate the material number field in MM01 with the material being instanced in the workflow?"

No, you pass the object instance in the workflow to an object instance in the task, but the task doesn't automatically do anything with it. If you want the task to call a transaction and pass an attribute of the object instance to that transaction, then you have to program the method to do so - or find one that already does that. I assume that is the purpose of this CREATE method? Can you see in its code what it's doing?

regards

Rick Bakker

hanabi technology

[Former Member]

HI Neil,

Why don't you try edit method as material is already created and need to be modified only.

Regards,

Sangvir SIngh

[Former Member]

Thanks for the explaination Rick... I am not surprised that it's my lack of understanding that is holding me back, I'm a noob afterall!

Thanks to the other guy who suggested the Change method, but this won't help as you cannot create a new material master view in change mode.

Looks like my plan of action is too:

Learn about dynamic parallel processing.

Look into writing a bit of ABAP to pass the material number to the screen field in my method

I'll update this post with my solution in case anyone is interested

[Former Member]

OK I think I have a solution.

I got my ABAPER to help me debug the CREATE method of BO BUS1001006, and it would seem that the method does try and populate the Material Master field in MM01... the thing is the field that it is using (called NEWMATERIAL) was blank during run time... This is because when you use this method in a task and then use it in a workflow the system doesn't perform the correct binding for my requirements and therefore the field NEWMATERIAL was always blank.

I changed the automatic binding and created a new binding from &BUS1001006.MATERIAL& -> &NEWMATERIAL& in my workflow step ... hey presto, now it populate the screen field correctly.

So in case anyone is interested my workflow looks like this:

- User creates basic data views of material master manually using MM01.

- Upon saving the event CREATED is triggered, this is my start event for my workflow.

- A fork in the workflow then sends each department a work item to complete their views. This is using a task based on the standard CREATE method of BUS1001006 with custom binding (as described above) to populate the material number automatically for the user. Each department only has authorisation to create specific views of the material master, I am using the roles created to limit their views as my agent assignment for each step in the fork.

- upon completion of all the fork branches a message is sent the workflow initiator to inform of the creation of the material.

job done!

Many thanks for all that shared their ideas and knowledge

[Former Member]

Thanks for the follow-up.