HCM P&F hiring and concurrent employment

[Former Member]

Hi!<br>

<br>

First of all, a small apology to post a non SIfBA issue here but since there are so many HCM P&F folks around in this forum please forgive me...<br>

<br>

I'm currently working on an HCM P&F hiring process and we came across a initially tricky seeming customer requirement regarding concurrent employment. The requirement is related to concurrent employment and what they want is similar to what they currently have in transaction PA40 while executing a hiring action. <br>

<br>

This is how it currently works via SAP GUI:<br>

1. Go to PA40<br>

2. Select the relevant hiring action and enter an effective date, execute<br>

=> a popup called "employee recognition" is opened. The popup contains lookup term fields such as title, first name, last name and date of birth<br>

3. Enter lookup term (= name of person to be hired), start search<br>

=> if no person is found, a new popup is opened with text "No employee was found. Do you want to change the search criteria or hire a new employee?" and the selection options "New employee" and "New search". By selecting new employee the hiring action is started and the user can begin entering the data. If new search is selected, we go back to step 3<br>

=> if a person is found, I can select it and then a new popup "New work relationship" is opened with options to either create a new personnel assignment for the employee or to change the employees organizational assignment<br>

<br>

What this in other words means is that the selected action is possibly changed on the fly by the user from hiring to additional organization assignment.<br>

<br>

Where it gets tricky is that HCM P&F does not (according to my knowledge and initial tests) provide this kind of dynamic functionality of changing a selected process dynamically. You can either start the start processes app without a person selection and start hiring or you can first select the employee and then start the suitable person-relevant processes (which do not include the hiring process).<br>

<br>

Before I start debugging the whole start processes WDA application for suitable enhancement spots and to start figuring out its inner workings, have any of you come across this kind of requirement? Any hints or recommendations?<br>

<br>

We're on EhP4 SP19.<br>

<br>

Best regards,<br>

Mikko

[Former Member · Accepted solution]

Hi Mikko.

<p>

<p>

It looks like you are trying to do 3 different operations in 1 service which will get very tricky (without all the ABAP :-). 1 option is to have 3 different processes: 1 - New Hire (no start object), 2 - New Assignment (no start object), and 3 - Change Assignment (start object).

<p>

<p>

For #2, since you need the ability to provide a PERNR (or perhaps a Central Person), you can add a search feature on the form. Since the user will start without an object a new PERNR will be assigned but you can allow them to search for an existing PERNR to create your relationship.

<p>

<p>

We do this currently for a client and it works extremely well. We have 3 processes but each use the same form. For process #2, we provide the option to search for a PERNR with 1 field and 1 button (of course there is a lot of magic in the backend during the search). It's a clean and consistent look. And by having 3 processes, the user clearly knows what function they are performing; and the client can do better reporting on which processes were started.

<p>

<p>

After successfully searching for the existing PERNR, we populate most of the EEs data on the form. In our setup, we create the relationship between the new and old assignement with the central person. But at this point, you should have the relevant data (old pernr, new pernr, and central person) to create the link however you wish.

<p>

<p>

If you must do it in 1 service, then it truly is possible. But you will get into heavy ABAP, FormCalc, JavaScript to make it happen in 1 process and 1 form.

<p>

<p>

Oh, and unless your client is one of those who don't mind their system chopped into pieces, I would stay away from the idea of debugging the application to try to change selecting the process dynamically :-). Instead focus on how you can do it all in 1 process (radio buttons, dropdowns, checkboxes, etc.. are a good way to let the user make decisions on the form).

<p>

<p>

Thanks.

<p>

Derrick Banks

<p>

Banks & Company, LLC

[Former Member · Accepted solution]

Hi Derrick,

and thanks for your good input!



I have made the same conclusion in the beginning of the project that I would require two different "hiring" processes, one for the new hire and one for the new assignment. (Process #3 is to be implemented as a separate transfer scenario.)



I'm not sure however I understood the user aspect of the suggested new assignment process without a start object. Did you mean that the new assignment process / form would be used for both new assignments (where a PERNR is found) and new hires (where a PERNR is not found)? And that the new assignment form would functionally match the new hire process in the latter case and you would then somehow just dynamically rename the field labels etc. to hiring to let the user know they're doing a new hire instead of a new assignment? Wouldn't there be any problems e.g. with the process reporting if we are starting an actual new hire process from within a new assignment process?



In summary, I see my options as follows:

1. A single new hire process

• inside the form, users would be able to look for existing employees and select the new hire type (new hire, new assignment, change assignment) manually or automatically based on the employee selection <br>

+ usability: one single process to select and to operate on

- lots of resource consuming dynamic functionality in the process, complex solution



2. Three separate processes

• three processes, users first need to select the process and then fill the required form information. Option maybe to spoof the new assignment process and to do the new hiring from the same form<br>

+ straightforward solution implementation, not much dynamic functionality required

- usability: users may need to go back and forth between the forms e.g. in cases where they're doing a new assignment and they realize the should be doing a new hire and vice versa



3. Dynamic process selection in new hire selection

• matches the customer usability requirement<br>

• since I'm stubborn sometimes, I know what and how to deal/not to deal with SAP standard functionality and this would be the ideal solution (user selects the new hire process, system gives a popup, user is taken to one of the three processes in option 2), I can't resist the temptation to at least examine this option further <br>

So in conclusion, I will first have a look at option #3 despite your comments (get ready to tell me "I told you so" ). And if that is a dead end, I will only then have a look at options #1 and #2 and take them to the customer for evaluation usability wise.



I'll let you know how it goes,

-Mikko

UPDATE: just read through Chris Solomon's weblog /people/christopher.solomon/blog/2009/08/03/hcm-processes-forms-start-objectwe-dont-need-no-stinkin-start-object and it seems in EhP4 you can let the user decide whether or not start object relevant processes are started and if the employee selection can be skipped. This looks promising in my case since the user can first look for an employee and (1) if found, start the new/change assignment processes and (2) if not found, start the new hiring by skipping the employee selection. I just need now to see how to enable the skip function...

Edited by: Mikko Mäki-Rahkola on Aug 12, 2010 10:20 AM

[ChrisSolomon · Accepted solution]

@Mikko....

Derrick's advice is dead on (which is why I didn't reply too). As for the EhP4 change to allow "skip object", all that is simply doing is allowing the user to skip to process selection view so that you can list your "non start object" processes with your "regular" ones and access them all together. It will still check the process you select to make sure it doesn/doesn't need a start object. I don't think that is what you want. As Derrick suggests, if they are truly different processes, why complicate things by trying to do them all together? Call them separate processes even if they share the same form. Life will be MUCH easier for you that way.

[Former Member · Accepted solution]

Hi Chris,<br>

yes sorry for being a bit vague in my previous update, but this is what I'm aiming at currently and I think it's in sync with Derrick's previous comments about splitting the processes into individual scenarios:<br>

<br>

Start processes<br>

Step 1 - Select employees<br>

• skip employee selection enabled<br>

• first, look for an employee<br>

a) if found, select employee and go to step 2a) (for start object relevant processes)<br>

b) if not found, skip employee selection and go to step 2b (for non start object relevant processes)<br>

Step 2 - Select process<br>

a) start object relevant processes only displayed: new assignment, change existing assignment, transfer<br>

b) non start object relevant processes only displayed: new hire<br>

<br>

This way the user would get the dynamic selection of processes enabled based on the employee existence, although in this case the dynamic functionality would not be fully automatical and thus not as ideal as I was looking for. But I think it's something the customer would cope with since it would fulfil the main requirement of selecting a process based on employee existence as currently in PA40.<br>

<br>

Since I haven't been able to test this yet (there's something funny about table T5ASROBJECTS since I can't find its customizing path in IMG as per [help.sap.com|http://help.sap.com/erp2005_ehp_04/helpdata/en/0f/9d8815d27446fa8e25fb32ba7323b5/content.htm] and a change to view cluster HRASR00OBJPROCPRP doesn't seem to work even though we're on EhP4, any pointers here?), I don't know if I have fully understood the skip selection functionality. So please correct me if I'm wrong.

Best regards,

Mikko

UPDATE Sep 6, 2010: the skip option was not displayed because the business functions HCM_ASR_CI_1 and HCM_ASR_CI_2 were not activated. After activation, all was good (funny how the tables were accessible but only the activation made the start application function...).

[akimol]

Hi Mikko,

I have recently worked on a hiring request and i did not use any of the SAP standard services to save the data (run the hire action). I performed all the necessary actions with the help of ABAP code (Process-> Workflow-> ABAP method).

Any hire action in itself is very coplex (with changing screens according to diff. countries 'n all), you have further coplexity on top of it. I would suggest handling all of this in ABAP code.. (yes, I am an ABAPer ).

~Amit.

[Former Member]

Hi Amit,

and thanks for your quick reply.

I can see your passion for ABAP I will however stick with the HCM P&F based version for three reasons:

1. the hiring form and its operations are now configured ok and we can create the required infotype records through the HCM P&F hiring form

2. the customer has made the decision to go with HCM P&F and its update mechanism (direct custom coded entry not allowed)

3. my problem is not related to data update to the infotypes, but more to the process selection in the beginning

Any ideas anyone how to work with the original problem?

Best regards,

Mikko

[akimol]

Hi Mikko,

I can see two options:

1. Copy and moify standard WD ABAP application (OR your initial thoughs of enhancements in standard WDA application.)

2. Create a wrapper process (and form scenario) with search fields and then based on the outcome of search, the next step (in WF assigned to same user as initiator) would be your existing hire form scenario or Org. change form scenario. This is just a thought, but its worth a try.

~Amit.