MDG Workflow approvers based on Customer/Vendor/Material views

[Former Member]

Hello Experts,

We want to assign different approvers based on different views in the CR for materials,customers and vendors .How do we do that.

For example when we create CR for customers/vendors with purchasing view and company code view , we want their respective departments to maintain and approve it.

Customers/Vendors:

Purchasing view - Sales team .

Company code view - Finance team

Material:

Sales view - Sales team

MRP view - Planning team

Plant Data view - Purchasing team

Accounting view - Finance team

The standard workflow (ex: WS86) in BRF+ , has steps for maintenance,approval,revision... , But can I add filters based on the views . I know we can add filters based on the UI field values.

Any inputs greatly appreciated.Thanks.

[Former Member · Accepted solution]

There are many ways in which you can achieve this. The most straight-forward is to assign a different step number for each role. For example, you can assign number 20 to the sales team step, and 30 to the planning team, etc. Then, in the CR step configurations, you can assign different UI configurations. The FPM UI configuration assigned to step 20 should include sales team views only and the FPM UI configuration assigned to step 30 should include planning team views and so on.

[Former Member · Accepted solution]

Hi Abdullah,

Thanks for the reply .We would like to minimize any customization and want to use the standard models without any modification and it looks that might not be possible now. So using the standard BRF+ workflows provided for MDG out of box we can only control who gets to maintain/approve the CR.

As per your approach mentioned above..lets say we want to do this for MAT01

After creating ZMAT01 from MAT01

Step1: Add required steps (20 purchasing,30 planning)

Step2: Add UI to these steps. ( copying the existing standard material UI that comes with all views)

Step3: configure the BRF+

If I am correct above , in step2 if I copy the existing standard material UI in which all views are activated/greyed based on the material type , should I explicit go and enable/disable the UIBBS in the UI config, like for purchasing step I only enable purchasing UIBB?.

Thanks.

[Former Member · Accepted solution]

When you say "copy existing standard material UI", you mean coping the FPM UI configuration. If that is what you mean, then you are correct. Yes, you need to have a different UI configuration for each step. In each copy you only enable the UIBB's relevant for that step.

[Former Member · Accepted solution]

Hi Abdullah,

What would be the other approaches based on the requirement above.

Thanks.

[Former Member · Accepted solution]

Another approach I can think of is using MDG Field-Level authorization. In MDGIMG: General Settings --> Data Modeling --> Define Authorization Relevance per Entity Type. Read the documentation of that node. Basically, if you mark a field there as relevant, then you can control access to that field using authorization object USMD_MDAT to control access to that field. So, first, you mark all the fields that can't be shared as relevant (meaning all the team-specific fields). Then, you update the "Sales Team" security role with object USMD_MDAT and assign only the sales team fields. Similarly, update the "Planning Team" security role with object USMD_MDAT and assign only the planning team fields.

Keep in mind that with this approach users can still see the other fields. They just can't edit them. You can use a mixture of both approaches if you don't want users to see those fields.

[Former Member · Accepted solution]

Ok , got it with the last approach , once we restrict the field level authorization by teams , we can then assign a user group ( which will be all the teams ) in BRF+ . Am I correct .

Thanks and appreciate your valuable inputs.

[Former Member · Accepted solution]

No, this second approach has nothing to do with BRF+. This is mainly to control field access for each user. However, BRF+ provides you with a mechanisom to deliver CR's to different teams regardless of which approach you use.

[Former Member · Accepted solution]

Hi Abdullah

Unable to interpreate your sentence correctly, Can you provide more details for your sentence

The most straight-forward is to assign a different step number for each role.

Do you mean that we can assign change request step number to role in PFCG?

My requirement is to route approval workflow per material type as well as per view also.

Example :

1. For ROH it should go to Supply Chain (Except Accounting view all fields should be editable) and Finance as well. (Accounting view is for Finance only and other fields should be non editable).
2. For FERTit should go to Sales Team(Except Accounting view all fields should be editable) and Finance as well. (Accounting view is for Finance only and other fields should be non editable).

Also

Unable to interpreate your sentence correctly, Can you provide more details for your sentence

Then, in the CR step configurations, you can assign different UI configurations. The FPM UI configuration assigned to step 20 should include sales team views only and the FPM UI configuration assigned to step 30 should include planning team views and so on.

Do you mean we need to create custom UI for each team in this case?

Then in decesion table can we maintain Step number in single decesion table?

[Former Member · Accepted solution]

No, it is not about assigning step number in PFCG. You create a different step for each role in the workflow step definition activity. Then, in the BRF+ application, you need to route the CR to that specific step. To route based on material types, you need to enhance the BRF+ application by adding the material type field. See this document:

Then, in the CR step properties activities, you can assign different UI configurations to that step. So, when the CR is routed to that step number, the specified UI configuration is displayed for that user. I don't have access to a system at the moment so I can't add any screenshots.

[Former Member · Accepted solution]

Hi Abdullah,

Thanks for your valuable inputs . I was able to achieve the above functionality by creating separate steps for each  views ( Sales,Planning,Purchasing etc...) and creating separate UI configurations for each of these views .In the CR process each view goes through 2 steps ,one for entering data and the next step for approving that particular view data.

I have few questions on further configuring these scenario's.

Lets say in the 1st step the planner enters 2 plants during their planning step and I would like it to go to 2 approvers based on the plant . I guess these can be achieved using the Rule_Context BADI. But my question is when I am approver1 , I should not be able to edit the approver2's data and Vice versa for approver2. How to achieve this . Shouldit be controlled in the user authorizations where they are given access by plant ?

thanks.

[former_member200911 · Accepted solution]

Hi Abdullah,

this link explains about triggering different user based on input we give

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/60f0cc68-5884-2e10-b8a9-a71ba25ad...

but it is limited to entity MATERIAL i guess, since LABOR is coming under structure ?/MDGM_S_PP_MM_MATERIAL

but my requirement is to trigger different user based on field COO and CAS which are coming under entity MARCFRGTR and structure /MDGM_S_PP_MM_MARCFRGTR and it is not working for me

I checked with the developer and he says this BADI/Enhancement is reading material from structure /MDGM_S_PP_MM_MATERIAL thats why it is not triggering other structure

Is that understanding correct?

Thanks

Arihant

[Former Member · Accepted solution]

Please create a new thread with your question to make easier for others to find answers if they have the same question in the future.

[former_member600236]

Hi Aravind,

You can assign the different user to your respective masters from workflow also. You just have to create Z table in which you will maintain your all approvals & their respective workflow steps based upon which the approval will get the rights of approvals once workflow triggers.

You have to assign this function module in which you will hit the created z table to fetch the users & workflow steps  which gets triggered on your approval of change request based upon the condition.

Best Regards,

Kaustubh

[Former Member]

A z-table is the least favorable solution and should be implemented in very limited situations. MDG workflow has many ways of assigning agents. I would never recommend creating a z-table to any one. It sounds like an easy solution but on the long run it is not dependable as maintenance of those tables become unmanageable.