Учет ночных смен

Случайно наткнулся на описание учета ночных смен от самой компании САП. Часто консультанты сталкиваются с непониманием у пользователей, как это учитывать всю смену в сутках ее начала, а не пропорционально или не относя на сутки окончания.

Любопытно Note 356716 — Subsequent day rule for night shift.

Кстати, столкнулся с интересной особенностью системы, может быть кто подскажет решение?

Есть график с 00:00 до 08:00. Если работник отметился в 23:45, то система никаким образом не отнесет это время к указанному графику (отметки в табличке TZP будут созданы предыдущим днем в виде 23.8 — 32.**, а график будет сформирован как 00.00 — 08.00). Вся смена будет засчитана в предыдущих сутках. Кто-то смог это побороть без использования переноса времени 24:45 — 24:00?


Что проверять перед расчетом заработной платы в SAP

Привет!

Думаю многие из нас помнят первое закрытие после старта системы в продуктивном режиме. Кошмарные ночи, жалобы пользователей, наезды руководства и так далее по списку. Хочу предложить вашему вниманию свой подход по облегчению первого закрытия. Вряд ли это будет новым для вас, но может быть освежить память. Например, перед первым-вторым-третьим закрытием я бы проверял основные данные.

Читать далее


Управление табельными номерами в PTMW

Привет. У нас тут товарищи клерки решили перестановку сделать в рядах противника. И стало им лень переделывать все идентификаторы выбора (списки табельных номеров, по-русски) в транзакции PTMW. И попросили они перенести им списки выбора между шахтами (я хочу списки вот того клерка, с шахты АБВГДейка).

Десять минут и вот результат. Все списки хранятся в таблицах HRSEL_*. Там есть как списки с табельными номерами (когда мы напрямую указываем табельные номера), так и с функциональными модулями, оргструктурами и так далее. Кому интересно — SE16N и прогуляйтесь по этим табличкам HRSEL_.


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

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

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

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

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

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

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

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


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

Привет!

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

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

Читать далее