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

Привет!

Давайте подумаем вместе и найдем интересные решения по расчету производственных премий? Под производственной премией я подразумеваю сумму денег, которая рассчитывается на основании некоторых групповых показателей, например, объема выпуска продукции. Плюс накручиваются различные коэффициенты стимулирующе-отбирающего характера. Я вижу следующие варианты решения задачи:

  1. АБАПим программку с интерфейсом, которая все считает. Негибко, неинтересно. 
  2. Используем связку Enterprise Compensation Management + Appraisals. Например, мы можем сказать, что ежемесячный бонус это ECM руководство (guidline), который зависит от результата оценки. Результат оценки, это формуляр в оценке персонала, где есть групповые значения и индивидуальные. Или наши коэффициенты. Целевые показатели  = физические объемы. В Appraisals можно хранить объемы и коэффициенты, ECM умеет показывать все на портале и записывать в инфотипы при утверждении. Расчетная часть идет в BADI.
  3. Используем BW BPS (бизнес планирование), которое позволяет вводить данные в кубик. А с помощью механизма ретракции мы можем либо получать полуфабрикаты и в HR считать бонус, либо уже готовый результат, который будет обсчитан в BW. Плюсы таковы, что можно встроить в портал, наглядно показывать в любом формате цифры и расчеты, удобно для менеджеров, так как не нужно ходить в САП.
  4. Ручной расчет в Excel и загрузка в САП. Скучно.
  5. Ваш вариант?

P.S. Через месяц мне нужно все это удовольствие запустить в продуктиве, поэтому не стесняемся, активничаем 🙂 О результатах и итоговом решении напишу 🙂


Удаление временных отметок

Знаете ли вы, что при удаление временной отметки в инфотипе 2011 она не удаляется, а помечается в поле TEVEN-STOKZ? Если вы хотите удалять отметки массово, то есть два варианта:

1. В тестовой системе программа RPTCCXDBDEL. Можно поломать в Z и использовать для своих меркантильных нужд.
2. Написать LSMW для удаления отметок. Я пошел этим путем.


Расширение PTMW

Сегодня наткнулся на решение по расширению PTMW. Оказывается есть очень мощный инструмент для управления данными (но не экранами, к сожалению) при работе в этой транзакции. Называется сие чудо BLP (Business Logic Processor). Работает через BAdi и фильтры на определенные события.

Более подробно можно почитать в нотах (а там же и найти примеры реализации):

Note 447097 — Questions and answers concerning the TMW implementation
Note 367249 — Customer enhancements for the BLP

Проверено — работает, чему я очень рад. Раньше PTMW для меня был закрытым инструментом.

P.S. Если покопаться в настроечных табличках PTMW (которых нет в SPRO), то там для каждой области PTMW и каждого чиха есть свой класс. Что если сделать свои классы и там прописать? Вроде бы и «настроение» транзакции можно поменять.


Транзакция для SAP Query

Многие об этом знают, но почему бы не напомнить друг другу?

Если у вас есть супер-пупер отчет, который «ну очень сильно хочется» рассылать по почте, то самый простой способ, это создать свою транзакцию к отчету SAP Query. Для этого нужно зайти в транзакцию SE93, создать новый код транзакции с параметрами (самая нижная «пимпочка»). Указываем имя транзакции (код), указываем вызываемую транзакцию (START_REPORT), ставим галочку напротив GUI и внизу заполняем параметры:

D_SREPOVARI-REPORTTYPE = AQ
D_SREPOVARI-EXTDREPORT = Название запроса
D_SREPOVARI-REPORT = Группа пользователей

Сохраняем и переносим в продуктив. Теперь можно запланировать задание с вызовом этой транзакции для SAP Query, и получать отчет в почту. Например, я так получаю статус по 3-у инфотипу за день до расчета заработной платы. Это позволяет увидеть потенциальные перерасчеты заранее.


Для чего нужен архитектор SAP

Знаете ли вы хотя бы одного консультанта, который знает весь САП? Или половину? Я не знаю. Система настолько объемна и велика, что сами САПеры далеко не всегда знают, что творится в своем огороде. И это нормально, нельзя все это помнить. Консультанты обычно владеют только своим кусочком модуля, где им комфортно. По моим наблюдениям, это приводит к тому, что и задачи решаются исходя из своих «привычных» знаний.

Приведу простой пример. Сегодня я столкнулся с задачей, которая с точки зрения стандарта достаточно простая. Есть правила, функции в оценке времени, механизмы в виде PTMW и инфотипов, которые позволяют решать достаточно большой круг задач с помощью одной настройки. По тем или иным причинам задача была решена с помощью самописных решений. Проходит время, появляются новые требования, и этот нюанс всплывает наружу. Возможны два варианта развития событий. Либо переделать все обратно на стандартные решения, либо продолжить этот путь. Переделать — значит есть вероятность появления ошибок. Да и сама по себе схема оценки времени не очень гибка к переменным алгоритмам, зависимым от даты (нужно делать свои правила и в них вставлять проверки на текущее число). Зачастую приходится именно доделывать, следовать уже сложившейся практике и руководствоваться принципом «работает — не трогай».

Читать далее