on 11-10-2014 12:36 PM
Hello Consultants,
I have to determine approvers at run time from a custome table. I am looking for the solutin on how to go about it ?
Can some one help me out , or provide some document?
Thanks
Sudhanshu
Hello All,
Thank you for the valuable suggestion to be considered . However i am still looking out for solution to create workflow based on custome table.
I am working on all custom developement , which only has first level approval in dynamic parallel processing , that will not be work with org structure.
Thanks
Sudhanshu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
All these workflow experts are urgently advising you not to do it, but you are determined to use a Z table anyway. I admire the chutzpah!
I don't quite understand what you are asking though. How to read from a Z table?
Obviously(?) you just create a rule to read the table, given some workflow criteria, and return a list of workflow agents.
Just to warn you: the people who have to maintain this workflow in future, will not be endorsing you on LinkedIn.
cheers
Paul
Dear Paul,
Thank you for the suggestion , I have already been agreed on words of other consultant.
I know that is certainly a correct to use org structure.
However i am working on the system , which is already using custom table and i do not have other choice 🙂
And i am also agreed on the points which have been metioned by each one of you .
I have already done the changes and my requirements have been fufilled.
Thanks
@Sudhanshu Please don't get disheartened by the "expert" ramblings of consultants (like me!) in this thread. Using a "custom table" for agent determination is a tried-and-true method used in workflow for years and years (dating back to clay pots of the early Egyptians, I believe? haha).
All that is being said is that there are "sometimes" better ways of doing it....and by using custom tables, you are also taking on more responsibility (ie. someone has to know about the table and maintain it as needed). However, there are times (especially with very complex rules coupled with a tangle of exceptions) where custom tables are just easier than trying to "bend" HR org structure and "walking/climbing" up and down the org tree to get your result. Just think in terms of the old stand-by cliche...."choose the best tool for the job" and the equally fun on "if your only tool is a hammer, every problem looks like a nail." haha
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Sudhanshu,
I'm not a consultant but a customer. I hope I can steer you in a better direction.
I've heard tales of consultants who take the ever-ready shortcut of using custom tables to store approvers for Workflow. Please believe me when I tell you that this may seem like an ideal solution *right now* but in the long run, the customer will suffer for it.
The tables will grow and grow and grow. The poor workflow administrator will need to do increasingly more maintenance on the table, as users or roles or approvers change.
I highly recommend that you investigate other means of identifying approvers. The HR Org structure is one favorite (because HR maintains this data by law anyway) or you could use a role or a rule.
Before you post back to me to provide you with the solution, try reading some of the search results here:
https://www.google.com/#q=sap+workflow+agent+determination
Regards,
Sue
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Right on, Sue! Before I ever (if ever) consider another (YET ANOTHER) custom table, I usually built a custom ABAP class to use with all workflows (if my client doesn't already have one) and in this I will have various methods to look up approvers based on necessary business logic and (hopefully) making full use of the Org structure (NOT custom table dancing haha) For instance, from the workflow container, I could pass the userid/pernr/whatever from my workflow container and then return the agent(s) back right in the "Agents" entry for the step as an "expression"....something like....
&WF_ASSIST.GET_MGR_FOR_USERID(USER=&userid&)&
...where "WF_ASSIST" is a workflow container "variable" which I have assigned the name of my "utility" class and "GET_MGR_FOR_USERID" is a method of my class which takes the input parameter "USER" and will return the manager for that user-id.....works just fine!
I was not the developer on that project. Well, actually, I'm not a developer at all, I'm a Basis guy, and not a workflow expert by any means. All I can say is that we have a table that uses cost centers as the key and then has several 'approver' columns containing usernames. The custom workflow takes the cost center associated with a shopping cart and looks up the approvers in the table, then routes the approval step to those users. It's incredibly simplistic. We roll up budget authorities to a higher level in a cost center hierarchy, and so the 'zapproval' table only needs to be maintained at that level (not every cost center must be entered). If a specific cost center is entered, the workflow will use that, if not, it uses the higher-level rollup.
Hello,
If you really want to use a Z table then just write a method to select from that table.
It's a custom development so that's all I can say about it.
How do you fill that Z table? What are the fields? I would double-check that you can't get the same information from standard tables. Or you could create a responsibility rule (AC....)
regards
Rick
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.