Экстрактор 0HR_PT_2 еще граната

Так, товарищи. Печальная новость — найдена еще одна недокументированная граната экстрактора 0HR_PT_2. Точнее не так, она документирована, но специфично. В табличке V_T569R есть два модификатора (05 и 06), которые определяют временное окно, в котором BW экстрактор ищет данные для загрузки. Если вы только стартанули или нужно сделать полную загрузку данных, то нужно модификатор 05 (самая ранняя дата перерасчета) установить на дату старта (или когда у вас появились данные в системе).

Если вы уже сделали полную загрузку, отработали годик, а потом вам нужно перезагрузить весь объем данных, то увы, система выдаст данные только в указанном временном окне. Поэтому алгоритм таков:

  1. Перед полной загрузкой (или инициализацией дельты) меняем дату на самую раннюю в табличке V_T569R
  2. Как закрыли год от изменений, то меняем дату на начало следующего года
  3. При перезагрузке см. пункт 1.

Investigation efforts: 1 час.


Оценка персонала в SAP HR

Поговорим про оценку персонала в SAP HR. Чуть-чуть. Я еще только учусь, поэтому за что купил, за то продал.

Есть задача настроить хранение данных по оценке персонала в системе. Сама форма оценки достаточно стандартная: несколько разделов, в каждом разделе несколько вопросов и простая шкала оценки от одного до пяти. Решение состоит из двух частей: настройка шаблона (логики, полей) и настройка печатной формы (PDF или BSP).

Шаг номер раз. Настраиваем шкалы оценки персонала. Кластер ракурсов VC_T77SK. Примеры уже есть и очень наглядные.
Шаг номер два. Настраиваем шаблон в транзакции OOAM. Сначала создаем группу с общими свойствами шаблона. Например, годовая оценка, квартальная оценка — две группы; годовая постановка целей — другая группа. На уровне группы мы задаем общие параметры в виде колонок и участников. Колонка — по сути способ оценки/измерения. Например, колонка FAPP — Final Appraisal позволяет задавать только результат оценки. Колонка OBJL — Target задает конкретные целевые показатели, OBJ0 — Objectives — цели. Товарищи ГУРУ, если я ошибся, то поправляйте. Начинающих не бьют!
Шаг номер три. Теперь нужно создать сам формуляр уровнем ниже и все его узлы (разделы и вопросы из бумажки). На каждом уровне можно определить какая шкала и способ оценки (читай колонка) будут работать.
Шаг номер четыре. Больше всего я промучился со статусами. Они привязаны таким образом, что для определенных колонок должна соблюдаться строгая последовательность статусов. Например, если речь идет о постановке целей, то нельзя пропустить статус планирование (Planning). На последней закладке в Status Flow и определяется что за чем идет. Для каждого статуса отмеченного галочкой и затененного (обязательный статус) указывается вид кнопки и следующий статус для перехода. Таким образом и выстраивается процесс: создает анкет, планирование, процесс оценки, пересмотр, утверждение.
Шаг номер пять. Поток операций. Для каждого шага по уму бы надо указать событие потока операций и настроить сами потоки, чтобы система автоматически рассылала участникам «письма счастья» с напоминаниями что и когда нужно сделать. Плюс это сильно облегчит жизнь в части автоматизации процесса и контроля статуса.

Читать далее


Настройка HR-PDC интерфейса

Если вы вдруг надумали делать интеграцию системы учета рабочего времени (позитив, терминалы и иные решения) с SAP, то обратите внимание на стандартное решение. Называется HR-PDC интерфейс. Слов о нем мало написано. Вся коммуникация идет через транзакцию PT80. Есть также нота по настройке, рекомендую, очень полезная.

Note 647145 — Setting up the HR-PDC interface


Обратный расчет заработной платы

Расчетчики, это обычно самые злюки в HR. И все по уважаемой причине — они деньги считают. Ругаться за каждую копейку ходят именно к ним, а не к консультантам вроде нас. Особенно они злюки, когда система с бухты барахты начинает обратный расчет крутить с начала года. И непонятно почему, что самое невообразимое.

Подумал я на ночь глядя и решил изобрести велосипед. Опять же, ничего нового, просто структурирую. Можно потом в инструкцию для злюки включить. Совершенно бесплатно.

Итак, если предупрежден, то вооружен. Чтобы вооружить злюк делаем следующее:

  1. Создаем в SAP Query элементарный отчет по третьему инфотипу, чтобы показать даты последнего изменения основных данных. Перед зп пусть запускают отчет и сразу увидят, по кому будет перерасчет.
  2. Включаем в системе аудит изменений инфотипов HR. На первом этапе нашли по кому будет перерасчет, на втором ищем причину. В большинстве случаев, это изменение прошлым числом. То есть по нужному табельному номеру запускаем протокол аудита и смотрим, кто и что менял во времена царя Гороха. 
  3. И совсем конфетка: делаем отдельный расчетный листок для внутреннего использования. В него выводим все виды оплаты, понятные пользователю (налоги, базы, начисления, удержания). Не нужно различные балансы, супер технические виды. В программе вывода расчетных листов (RP*EDT*) указываем параметр вывода перерасчетов в листочек. Здесь есть маленькая хитрость, которую я пока не разобрал, но сделаю скоро. В программе вывода РЛ можно сказать, чтобы расчетный лист не выводился для оригинального периода (есть user-exit). Надо попробовать исправить ее так, чтобы выводились только перерасчеты. Тогда мы красиво в симуляции запускаем расчет зп по всему предприятию с выводом этого перерасчетного листочка. Он покажет только перерасчитанные виды оплаты, периоды. Сразу злюке станет проще, так как будет понятно что изменится по работнику и с почему.
Примерно такие мысли 🙂
P.S. Злюки, если вы меня читаете, то я использовал это выражение исключительно для эмоциональной окраски. Я вас очень уважаю и обожаю. Счастливее вас нет людей, когда проводки в САП прошли без красненьких кружочков слева в обзоре документа 😉