Принудительное изменение статуса кандидата в E-Recruiting
В заметке, посвященной настройке TREX для E-Recruiting, я затронул важную, с моей точки зрения, тему про то, какие именно кандидаты являются «искомыми», или лучше сказать, доступными, через Web Dynpro приложения ERC_A_CAND_SRCH. Повторюсь: кандидат становится доступен в результатах поиска в приложении ERC_A_CAND_SRCH только при условии, что в таблице HRP5102 в поле STATUS для него установлено значение 2 - Released(Деблокировано).
Сам же кандидат, или, правильнее сказать, профиль кандидата, по умолчанию не деблокирован. Не деблокированные кандидаты «теряются» в поиске. Это, естественно, может не устраивать функционального заказчика. Ниже предлагаю ознакомиться с возможным вариантом решения данной задачи.
0. Вступление
Начиная работу с функциональностью E-Recruiting, необходимо обратить внимание на SAP Note # 997181 - ERP integration SAP E-Recruiting 600 and SAP ERP.
В ней описаны возможные интеграционные сценарии использования функциональности E-Recruiting, и соответствующие предварительные шаги, которые необходимо выполнить в системе.
Аналогичную информацию можно найти в официальной справочной библиотеке:
1. В какой момент формируется объект NA?
Если вы выполнили все необходимые предварительные настройки (см. раздел 0. Вступление) объект NA - Candidate/Кандидат автоматически сформируется для вновь принятого на работу сотрудника.
Рисунок 1. Соединения объектов, используемых в Personnel Administration и E-Recruiting
Помимо того, что объект NA соединяется с объектом CP, он также сохраняется в инфо-типе 5102 Candidate Information.
Получается, что каждый работник, как новый, так и уже работающий, с точки зрения системы — являются кандидатами.
2. Как выглядит процесс с точки зрения стандартного решения SAP?
По умолчанию, объект NA формируется со статусом 0 — _Locked (поле STATUS таблицы HR5102). _Поиск вновь принятого работника, при условии, что произведена полная индексация пула кандидатов, будет недоступен. И этому есть логичное объяснение.
С точки зрения процесса, как его «видит» SAP, каждому кандидату предоставляется возможность самостоятельно определить для себя, хочет он или нет, чтобы его профиль был доступен в поиске. Для этого, в сервисах самообслуживания сотрудников используется приложение My Career Cockpit.
Используя это приложение, кандидат может обновить информацию по своему профилю, и в итоге принять решение деблокировать его или нет
После того, как кандидат деблокировал свой профиль — он доступен для поиска.
До тех пор, пока деблокирование не выполнено, его профиль может быть рассмотрен только на позиции, на которые он откликался самостоятельно
3. Принудительное изменение статуса кандидата
А теперь немного о том, что послужило триггером для написания данной заметки. Все очень просто — опять бессердечный проектный опыт. На одном из проектов, функциональный заказчик выступил против того, чтобы кандидаты самостоятельно могли деблокировать свои профили. Было сформировано требование, что каждый кандидат должен быть по умолчанию Деблокирован, тем самым сразу становясь доступным для поиска через соответствующее Web Dynpro приложение.
Никаких настроек на эту тему в системе не оказалось. Поэтому действовать пришлось через класс CL_HRRCF_ERP_CONVERT_P_2_CAND метод PP_CREATE_CANDIDATE
Создайте Post Exit Enhancement для метода с соответствующей логикой определения статуса кандидата
В случае успешного «абапинга», есть шанс получить требуемый результат, а именно, деблокированный профиль кандидата для нового сотрудника, и, как следствие, доступный кандидат при поиске.
Удачи!