on 10-20-2010 9:29 AM
Hi Experts!
I am creating a workflow for Material creation scenario.I am not using LDAP and all user and roles are defined in SAP MDM.
I have 10 plants and have 2 level approver for 6 material types.
That means there are 6 material types with differen approvers and each in turn are different for 10 plants.
So I want to know which is a better way,
1.Maintaining 10 workflow for each plan and then branching for various types.
2.Creating 1 workflow which determines which plant and call from that Workflow other worflows.
If you have any other ideas pls share.
Thanks in advance!
Regards,
Ravz
Hello Ravz,
How you are maintaining different plants at material level?
Is it using tuple or using qualified lookup?
If yes then how will you restrict user's from modifying or approving data of other user's plant?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How you are maintaining different plants at material level?
It is maitained at Tuple level
If yes then how will you restrict user's from modifying or approving data of other user's plant?
I am trying to figure that out.Thing is Validation for plant at Tuple level gives me Tuple.record option.
I am trying to figure out how can a frame a workaround using this and HasAny function giving list that plant code.
The other fields that will be part of Tuple.record are very different they will not have that value.This is yet to be tested though,
If you have any suggestions pls tell me.
Thanks,
Ravz
Hello Ravz,
Your scenario is best suited for modeling outside MDM (possibly in BPM).
Modeling this in MDM will be more complicated from implementation as well as maintenance point of view.
Probably you will end up with lots of customizations, if you decide to model it in MDM.
Because you cannot dynamically assign approver's in MDM workflow.
Also you cannot access modifier (i.e. user) and its role details, anywhere in MDM (assignments, validations, and workflows);
hence you need to keep this plant to its approver mapping somewhere else.
Also consider the point that you cannot use checkin/checkout operations on Tuple or Qualified level.
This will lead to dirty read, because you have to save modifications on original record before approval,
that too you cannot revert modifications in case of rejection.
Tuple or Qualified level change Syndication is another headache.
Designing this scenario in MDM will become measure maintenance night-mer after go-live.
One option of design may solve most of the above problems.
That is: Create a dedicated main table for plants.
Means you will have two main tables one will be analogous to MARA and another will represent MARC.
But, this design is against the packaged Material repository provided by SAP.
Also decision of creating multiple main table should be taken carefully, because it may be a performance hit.
Regards,
Shaailesh.
Thanks for your input!
Yes you are quiet right,it seems very unscalable solution at MDM.
What I can do is based on Locationdata.record and only one Display field Plant i can break into various branches.
Then each branch would call individual users from that plant.
Issue here is if one user puts request for creation of record,how do i ensure only that user gets notification on completion?
This is a challenge as for one Plant under one Material type there are 3 roles and each roles will have 3-4 users.
Please guide.
Hello Ravz
Somebody should to launch your WF.
1)
If that somebody has limitation for records visability.Hi(she) can launch WF for specified records(or plants) depend of limitation rules.
2) branch working into WF only (you can not set rule for WF launch depends of materials or plants)
3) i suggest you to split WF because that is better for development, but it is not good for transport from one environment to another and for WF management
business process in that case will be:
main WF ->WF depend of materials ->WF depend of plants
main WF ->WF depend of plants ->WF depend of materials
Regards
Kanstantsin Chernichenka
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.