Often there is a requirement to have one single process and form for Hire and Rehire. This arise because the processes for Hiring for New hire and Re Hire are alike in most organizations. I would like to list down a set of development considerations which would help somebody designing single process for hire and rehire actions.
This blog is meant for developers who have the basic knowledge of developing HCM Processes and Forms. Here I mention only certain key considerations and developers who got trained / has prior experence in developing HCM processes and forms would be able to connect these with the standard development techniques. Beginers please go through the SAP documentation for HCM Processes and forms where the concepts are explained beautifully and tutorial on building relocation process is provided. The link is http://help.sap.com/saphelp_erp60_sp/helpdata/en/42/f273461e5132c3e10000000a1553f6/frameset.htm
Back to the topic here. To make it easy, I wish to list down the special considerations with following scenario. Hiring manager fills in the form with basic details such as employee first name , last name , date of birth, SSN or other ids , position etc and click on the initialization button. This should trigger a check for duplicate employees. No duplicates, its hire. Duplicate found and is not active, its rehire. The existing PERNR need to be re-used instead of creating new one. Duplicate found and is active, action is hire and action reason is set to second engagement.
Idea is to leave it to the backend to decide whether the hiring is actually a New hire or rehire. Sice standard SAP_PA doesn’t help in this, we do this code within custom backend service.
1. Hire or rehire? Default action type from backend service.
Do not default the action type manually as in standard. Configure default value for action with the custom backend generic service.
During initialization, set it to 01 - Hire, and then during the backend round trip on click of initialization button in the form or check and send etc. do the check within method IF_HRASR00GEN_SERVICE~DO_OPERATIONS , determine the action type according to the requirement of our scenario and return the field value back in parameter SERVICE_DATASETS .
Function module HR_RECOGNIZE_EMPLOYEE, or a custom copy of this one modified to suite your customer need would become handy here to check duplicates.
2. New PERNR or reuse existing? Doesn’t it make sense to default PERNR from backend?
Yes. In the process field configuration set the PERNR field to default from our custom backend service. In case of rehire return PERNR value in SERVICE_DATASETS.
But we have issues to get around.
- The first issue is that the standard SAP_PA generic service will always generate a PERNR when service field PERNR is blank and there is no validation error.
Even in case of re-hire, it might generate a new PERNR and use it instead of re-using existing inactive PERNR for the same person. The solution is to ensure that standard SAP_PA is called only after our custom generic service is called. This is achieved sequencing backend generic service in form scenario configuration.
With this sequencing for re-hire, by the time SAP_PA is called, we have value for PERNR, so no new PERNR is generated and used.
- The second issue is that to ensure that SAP_PA being called at sequence 2 generate a new PERNR only during ‘Check and Sent’ and not during any other backend turnaround triggered by user events triggered from Adobe form. (Like initialize button click, turnaround for any drop down refresh based on another field value etc.)
The issue is significant when internal numbers are used for PERNR. Manager could open the hiring form, do some action which triggers backend service and then decide to defer hiring to a later time and close the form. In case of re-hire we are good. But in case of Hire, though no hiring happened here, the backend service trigger cause SAP_PA to get called second in sequence to custom service and it generate a new number for PERNR. This number is lost. Next hiring will generate next number in sequence.
This solution is to ensure that SAP_PA is called only when you need it. It’s better to have it called only on Check and Sent / Sent. (Yes. A number for PERNR is lost if manager decide to defer hire after clicking check and sent, which doesn’t return error, but this its more close to actual hiring and I guess this could be justified by the fact that even in backend hiring in PA40 a number would be lost if PA40 is closed after just hitting enter key on the first screen after executing action.)
How to achieve this? The aim is to identify if the backend is called by user event or a click on ‘Check and Sent’ and then trigger SAP_PA only on ‘Check and Sent’.
We will create a create a service field say ‘EVTOPERATION’ of type ASR_FORM_OPERATION assign it with user event name each time before backend is called.
Configure for defaulting it from backend. This is to clear the value or set it each time a round trip to backend occurs from frontend.
I the Adobe form, map this field to a hidden text field. Using Java script / Formcalc script fill this field with the name of user event each time before the user event is triggered from script.
Now in the backend we get the user event name each time backend is called by a user event.
How to stop SAP_PA when user events trigger backend?
Create a rule SAP_PA_RULE which checks the condition EVTOPERATIONS = ‘SAP_PA’
Assign this rule to backend service SAP_PA. This ensures that SAP_PA will be called only when EVTOPERATIONS has value equal to ‘SAP_PA’.
Now, how and when EVTOPERATIONS get value SAP_PA?
‘Check and Sent’ button is part of the framework, but outside the form. Hence setting EVTOPERATIONS to ‘SAP_PA’ within form script won’t be possible. But we are good because we get EVTOPERATIONS filled for all other actions triggering backend.
So the backend checks help. In method DO_OPERATIONS, check if value of EVTOPERATIONS is equal to any of the user events.
YES means backend is triggered by user event, so just clear the contentof EVT_OPERATIONS which ensure it’s initial again when control is back at the frontend. The initial value cause the rule SAP_PA_RULE evaluated as false and SAP_PA service is not called.
NO means backend is triggered by ‘Check and Sent’ so check for no errors and then set EVT_OPERATIONS to ‘SAP_PA’ if there is no error. Value ‘SAP_PA’ in EVTOPERATIONS cause rule SAP_PA_RULE evaluated as true and SAP_PA service is called. If no errors, it sent the form to check and send screen by generating PERNR.
3. Want to generate PERNR even for Hire within custom generic service and leave SAP_PA to handle only infotype updates?
Call CL_HRPA_PERNR_CHECKS=>CREATE_PERNR within do operations when conditions for setting EVTOPERATIONS to ‘SAP_PA’ is true.