It never fails that once someone actually gets familiar with HCM P&F, once they understand how the "Start Application" works, and once they begin to actually run through some testing, one of the first questions I will get is "So how does it know what processes to put in the Process Selection List screen for us to pick from?". Is it "magic"? No. Is it a simple one sentence answer? No. Does it require coding? No. Is it flexible? Yes. Is it configurable? Yes. So what is it?!?!?!?!
Well, in a nutshell, the "it" is a number of configuration options as your disposal which allows you to filter and further filter the processes shown in the process list down to pretty much as specific a level as you can or will ever want to get.
First off, and maybe to backtrack a bit, what are we talking about? Well, in the HCM P&F "Start Application" whenever a user starts, or "initiates", a process, they will be "guided" through a number of screens/views/pages as follows:
If you look at these steps, you will see that the second step is where the initiator will select WHAT process they actually want to execute for the selected employee (or in some cases, without an employee previously selected...such as "new position" or "hiring"). This page will appear something like:
So now back to our question and topic of this blog? "How does it know WHICH processes to display in this Process Selection List?" Personally, I like to think of these in filters that can be combined in an ever compounding fashion...in other words, filters with more filters with more filters.
Now, it has been my experience that most people will only go as far as using our first two options below, however, there are several "filters" available to us. These "filters" fall into these categories:
WHO:
Probably the first place to start is by defining "who sees what" before we define any additional filtering of this list. Think of this as our "all possible processes under the best conditions" for our user.
Initiator Roles
This one is fairly straight forward and will always be configured. With this setting, you are basically setting up who can start (aka. "initiate") a process which means it will show in their process list.
As you can see, there are a number of standard delivered initiator roles available. However, you can also create your own custom roles if you wish (ex. "ZUSMGR"). What is confusing to many people is how we "assign" an initiator role to a user. Well, do not think of this "role" in that way. This "initiator role" in HCM P&F is really just an "id" or code or key we use to "group" processes together. The only way it is used by a user is that when launching the Start Application, this initiator role "id" gets passed to the application as a parameter (either directly as query string parameter, an application parameter on the iView, via the Homepage Framework config, etc). If nothing is passed, the default is the HR Administrator initiator role (HRASRA). You can see this if you look at the actual Webdynpro ABAP application, asr_process_execute.
There is no direct assignment of the "initiator role" to a user. (*I cover this more in an upcoming blog.) Keep in mind, assigning the "initiator role" only decides who starts the process off. Who interacts with it from there and how (ie. edit or review form) is completely controlled by the assigned workflow.
WHAT:
Ok, so now we have defined the list of "possible" processes available by simply configuring the "initiator roles". But next, we want to define from that list, what is available. We have a few more options...
Object Groups
This allows us to restrict processes to a specific group of employees (objects). For example, we might want to allow only certain employees from a certain country to be able to have a process run for them. Since the initiator will first select an employee (in most cases), this information is readily available. The configuration for this occurs in the same location as for the initiator roles in the Design Time. If you have selected an initiator role, you then select "Included..." as the entry under the column for "Restriction". This will make a new column appear for Object Groups.
By clicking on this column, you can then select an existing object group or define a new one by clicking the "Feature" button. The Object Group is actually defined via a "feature", PASRG (which you can go to directly as well via t-code PE03).
Process Groups
Another option at our disposal in determining a further filter to our process list is defining "Process Groups". This is simply a way to group together a bunch of processes that may be related or considered together.
Defining process groups really does two things for us:
- It makes sure that all processes in the same process group appear together in the Process Seleciton List.
- It allows us to do "collision" checks for a process against our group. (* collisions are discussed further down)
First, we simply define a "name" for our Process Group. Then we select all the processes that are part of that same group (or from within a process we are working on, we simply add it to an existing process group). So for example (and the one SAP uses a lot), we might have a process group we call ORG which groups all our processes together that relate to organizational changes. The result is that first off, all the processes in the ORG process group will be grouped together in the Process Selection List, and second, it will check that when we select a process, it does not collide with the other processes (if we configured the collision check).
WHEN:
Validity Period/Dates
This setting allows us to specify when a process should be available. This setting is done on the specified version of our process and can be found as the first node below the top node for our process in the Design Time (t-code HRASR_DT).
For instance, we might have some process related to "End of Year Bonuses" that we only want available during the last quarter of the year. By setting the date range (date from/to) for this process, we can control when it appears in the Process Selection List.
Frequency Restrictions
Another "time based" restriction we have available to us is the Frequency Restriction configuration setting for our process.
This defines how often a process can be run for an employee. For example, we might not want to allow a "Pay Change" to be run 10+ times within one month for an employee! (haha) Straight from help.sap.com documentation, we have the following possible settings available:
- The process can be run any number of times (default).
- The process cannot be run if it was run one or more times within a certain period that is before the desired process start.
- The process cannot be run if it was run one or more times within a certain period that contains the desired process start. The period is calculated as an interval that regularly repeats itself as of a set date.
- The process cannot be run if it was run one or more times within a certain period from a fixed start date.
Process Collisions
Pretty much as the name implies, this allows us to configure a check whether our selected process is allowed to occur while other processes are in process for our selected employee. There are actually two sections in configuration for this which you can see in the screenshots below. I know this makes about as much sense as beans in a bathtub, but oh well, that's SAP....why put it all in one screen and make it easy? (haha)
What might constitute a collision though? Let me make this easier. For example, it would not make a lot of sense for us to try to start a "Promotion" process while there is a "Termination" process on-going or completed for our employee (give them a raise while they get fired? I don't think so.). For this "collision" configuration, we have a few options:
- We can define what running processes that our process might collide with.
- We can define what completed processes that our process might collide with.
When there is a collision detected, we can further define what the system should display (ie. information, warning or error message) and how the system should react (allow process to continue or stop the user from executing process).
Parallel Run
This setting is very process specific. Basically, we set this flag if we do want to allow a process to be ran multiple times in parallel. Typically, this will cause an error otherwise. Again, this is solely comparing a selected process against itself. This might be something we want to allow in some cases. For example if an employee wishes to request several vacations/leaves, we would want to allow them to run that process multiple times if needed.
Further Restrictions
We also have one last way to further filter/restrict our processes if none of the other possibilities fit our needs or in other words the "if all else fails" option.
BAdI HRASR00PROCESS_START_RESTRICT
By creating an implementation of the BAdI HRASR00PROCESS_START_RESTRICT, we can further restrict a process under certain conditions.
Again, to use the good old standard SAP example, we could make it so a "Maternity Leave" process would only be allowed for a female employee. Per SAP documentation, to display the documentation on this BAdI, branch to the IMG activity Determine Restrictions for Starting Processes. Personally, I have not had to use this capability yet....but it sure is nice to have if I need it!
Order of Operations
So given all these options at our disposal, how does the magic all happen to determine our final list of processes that are shown to the user?
First and foremost, these two checks happen right away and in this order to determine the list of processes displayed for the user:
- Initiator Role
- Object Group
From the process list that comes out of this, the following checks happen exactly in this sequence:
- Permit Parallel Run flag
- HRASR00PROCESS_START_RESTRICT BAdI
- Frequency Restriction
- Collision
And now we have our final list of processes for the Process Selection List for our user. Just that easy! (haha)
There you have it! Given the options above, you should now be able to fully whip your process selection list in shape. For more information (and much the same as above), please go to: http://help.sap.com/erp2005_ehp_03/helpdata/en/ff/1b169c1d7e4045a389dd2248a3b9b3/frameset.htm
Thanks as always!
- SAP Managed Tags:
3 Comments
