О пользе принудительной оценки времени

Давно я не общался с вами. Надо срочно исправить это недоразумение.

Сегодня я хочу поделиться с вами ситуацией, которая изрядно попортила мне жизнь. В США суммированный учет реализован несколько иначе, нежели в России. Одной фразой он звучит как «любая работа сверх 40 часов в неделю считается сверхурочной». Поэтому в стандарте есть два варианта реализации. Либо сверхурочной считается вся работа больше 40 часов, либо вся работа после 5 дней. Каждый выбирает сам. Так вот в обоих случаях есть одна досадная неприятность.

Представьте, что мы отправили сотрудника на обучение в субботу. Суббота уже идет как сверхурочная работа, все хорошо. Оценка времени у нас работает по ночам ежесуточно для актуализации баланса и выгрузки данных в BW. Наступает закрытие и мы выясняем, что на самом деле человек сходил на обучение в воскресенье, а не в субботу. И у него еще было отсутствие в пятницу.

Оценка времени уже прошла за те периоды. Система использует механизм видов времени — флажков, которые накапливаются ежесуточно и потом сбрасываются. И у нас может случится такая ситуация, когда мы изменив что-то предыдущим числом, инициируем оценку времени только с даты изменения. А флажки «за вчера» не обновили.

В системе наступает казус и расчет идет неверно. Выхода два:

1. Пересмотреть алгоритмы, чтобы не использовать «сегодня данные для завтра».

2. Запускать оценку времени в принудительном режиме с начала расчетного периода. Это позволит избежать подобных недоразумений.


Планирование численности персонала

На сегодня я знаю два способа, как можно организовать планирование численности персонала в SAP.

Планирование численности персонала на стороне ERP

В системе на уровне организационной единицы есть инфотип 1019, который доступен как из PPOME, так и из MSS. Суть его в том, что он может хранить потребность в должностях на период. Например, нам нужно на следующий год двадцать компьютерщиков. Мы в этом инфотипе указываем должность «Компьютерщик» и указываем количество. У инфотипа есть подтипы, которыми можно определять потребность: «нужно еще», «нужно всего», «уволить нафиг». Как вы сами определите подтипы, так система и станцует. Дальше этой информацией можно воспользоваться по-разному.

Можно сделать квери, которым показывать численность по МВЗ или оргединицам. 

Можно передать информацию в контроллинг в виде статистических показателей в разрезе МВЗ, чтобы уже там собрать бюджет (программа RHWPC_HDCNT2SKF).

Создать штатные должности по заявленному количество голов (программа RH_GEN_AND_RED_FROM_BUDGET).

Планирование численности персонала на стороне BW

С помощью инструмента планирования можно сделать конфетку. В BW мы в любом виде можем вытащить фактические значения за любые периоды. Далее рядом делаем колонку с планом. С помощью прав доступа раздаем полномочия менеджерам и они заполняют эту колонку. Все это агрегируется в одном кубе. Теперь у нас есть численность. Зная фактическую заработную плату (соцпакет) за год, можно получить плановый бюджет на следующий. К сожалению, автоматически все это отдать обратно не получится в красивом виде, но можно с помощью небольшого АБАПа и механизма ретракции создать нужные объекты уже в ERP.


Протоколирование и аудит в SAP HCM

В качестве напоминалки хочу поделиться несколькими табличками и программками для шпионажа за пользователями  помощи пользователям вспомнить, когда и что они сделали (по сути это аудит в SAP HCM). В системе для этого есть две возможности:

  • Протоколирование изменений инфотипов. Настраивается в ракурсах V_T585A, V_T585B, V_T585C. Отслеживается в программе RPUAUD00. Рекомендуется включать в продуктиве сразу же после миграции данных (загрузки данных). 
  • Протоколирование запуска программ. Настраивается в ракурсе V_T599R. Отслеживается в программе RPUPROTD. Удобно, что сохраняет параметры селекционного экрана. При этом программа должна быть реализована с помощью логической базы данных. Рекомендую включить в протокол программы ОНД, Оценка времени, Продуктивный расчет заработной платы.

Мы за безопасный САП.


Решение: расчет производственной премии

Привет!

В результате изучения различных решений я пришел к выводу, что проще и универсальнее сделать расчет производственной премии следующим образом. Для расчета мне нужны некоторые цифры, а именно среднесписочная численность по МВЗ, производственные показатели, суммы. На первом этапе внедрения механизма мы решили сделать полуавтоматический режим. В этом случае численность и сами сотрудники берутся из BW-HR, производственные показатели пока вводятся вручную (как только настроим модуль PP, то будем тоже брать из BW-PP).

В HR системе делаем правило для формирования вида времени с численностью. В правиле мы считаем, что сотруднику положен бонус, если он не отсутствовал по ряду причин. Искомый вид времени 9BW2. zbw_rule

Читать далее


Выход книги «SAP HR. Вид сбоку»

И снова здравствуйте.

Наконец-то могу сообщить всем и вся, что это свершилось. Вышел в свет мой первый опус о том, что такое SAP HR словами простого человека. Это не курс компании САП, это не копия библиотеки SAPHelp, это что-то другое, мое, выраженное своими словами так, как бы я стал рассказывать человеку, который задает мне вопрос лично. Я постарался изложить свой скромный опыт в различной форме: от простых повествований до заумных настроек.

Читать далее