Вопрос — ответ 7. SAP HCM для новичков

Вопрос:
Итак, про меня: я год выгружала данные с пом. SAP BW (курсов никаких не проходила), а сейчас перевелась в персонал на отчётность в HCM.
Распиши, пожалуйста, как организовать процесс обучения и общения с местными программистами. Моя задача будет — наладить выгрузки для анализа данных по персоналу (текучесть, причины ухода, стаж и проч.).
В BW были готовые отчёты в excel) Здесь же приходится работать в самой базе и я не очень представляю, как это освоить. Люди вокруг пользуются несколькими отчётами, следуя стародавним инструкциям, мне же хотелось бы проводить более глубокий анализ и использовать больше возможностей SAPа. Надеюсь на твою помощь!

Ответ:
Любопытный вопрос. Нужно уточить — наладить выгрузки куда? В BW или просто в отчеты/Excel.
Подразумеваю, что пока мы говорим об отчетности на уровне ERP системы. Я бы пошел таким путем:

  1. Изучить базовые курсы по HR, чтобы понимать какие есть инфотипы, кластеры — возможности для хранения и организации данных по персоналу.
  2. Изучить курсы по SAP Query — инструмент для формирования отчетов в ERP системе. Наиболее популярный на мой взгляд. Причем следует обратить внимание на то, как устроены инфонаборы, какие есть в них управляющие элементы. Изучить создание дополнительных полей.
  3. Сделать базовые отчеты, которые можно выгружать в Excel, где уже сводными таблицами/формулами доводить до приемлимого вида.
  4. Проанализировать объем данных, который введен в продуктивной системе и который ведется вне системы. Часто существенную часть бумажной волокиты можно переложить в инфотипы системы. Перенести эти данные в систему и сформировать по ним отчетность.
  5. Изучить экстракторы BW HR для формирования отчетности из BW.
  6. Пойти ко мне на обучение.

Если сможете дать больше специфики, то смогу конкретнее ответить. 🙂


Вопрос — ответ. Смена единицы расчета

Вопрос.Смена единицы расчета:

Вариант событий 1

Имею:
Раздел персонала№1
Раздел персонала№2

Выполняем перевод сотрудника с сохранение табельного номера (сотрудник уже рассчитывали в Раздел персонала№1)
из Раздела персонала№1 в Раздел персонала№2 с 15-го числа

Система расчетчикам не дает поменять единицу расчета — «смена только в конце периода расчета» + «по сотруднику уже был расчет»

Это у всех так?
Как у Вас такие перемещения реализованы?

Ответ:

На эту тему есть несколько нот (849363, 1104733), где сказано, что изменение единицы расчета в середине расчетного периода возможно только для нескольких стран. Увы, Россия и СНГ в этот перечень не входят. Поэтому обычно при перемещении единица расчета остается прежней, а в конце месяца (расчетного периода) копируют первый инфотип с уже новой единицей расчета. Таким образом сотрудника считают в том отделе, где он начал работу в начале периода.


Вопрос — ответ. График отпусков

Вопрос:
Формируем график отпусков Т-7 на 2014 год.
На селекционном экране выбираем орг.единицу, год 2014,
дата январь 2014 года.
Других параметров для выбора ТН нет.
В отчет выводятся Все ТН, ШД которых когда-либо имели соединение с указанной на селекционном экране орг.единицей. (То есть переведенные в другие вышестоящие, нижестоящие орг.единицы в 2012,2011…годах).
Где не получается отсечь ненужные ТН — не понятно, это стандартный код. Ноту не нашли.

Ответ:

Привет. С этим вопросом будет чуток сложнее, так как мне негде проверить. Я почитал код формы и пришел к выводу, что все дело в стандартной логической базе данных (ЛБД). В этом отчете используется PNP, которая использует общие куски кода с PNPCE. Если для первой ЛБД нормальной документации нет, то для второй она более чем исчерпывающая (транзация SE36 — дкоументация). Судя по отладчику, если мы используем поиск по оргструктуре, то система подставляет максимальный диапазон для поиска 01/01/1800 — 31/12/9999. Поэтому и попадают все оргединицы и табельныа номера.

Читать далее


Вопрос — ответ. Лимит отсутствия

Вопрос. Лимит отсутствия:

Сгенерили лимит на рабочий год. Потом человека перевели на должность, где лимита больше (или меньше). Может система пересчитать старый лимит автоматически (полуавтоматически)? Я пока такое видел только при ограничении ИТ 2006 при увольнении.

Ответ:

У меня есть несколько вариантов решения.

  1. При переводе ограничивать период действия лимита и заводить новый. Иначе система не поймет, что надо изменить базовое право. Это вроде бы голый стандарт.
  2. При переводе в динамическом мероприятии программно запланировать запуск программы генерации лимитов с передачей в ее параметры периода и табельного номера. Это позволит избежать блокировки табельного номера (нельзя запустить программу сразу же, так как табельный номер еще блокирован мероприятием). Это можно обойти технический, но не стоит. Техническим регламентом определить время и запускать. Для пользователя это прозрачно с одним исключением — если приказ нужно печатать сразу же, то цифры будут неактуальные. Либо планировать такой запуск на совершения события (объекты BUS*).
  3. Генерировать лимит в оценке времени. Зачастую оценка времени запускается ежесуточно, поэтому лимит автоматически через user-exit можно заполнять данными с новой позиции. Опять же в случае необходимости приказа «сейчас и сразу», кадровик может сам запустить оценку времени по одному табельному номеру, а затем распечатать приказ.

Вопрос-ответ. Налоги

Вопрос:

Сталкивались ли Вы с ситуацией, когда в расчёте ЗП в промежуточных таблицах (например, IT) и в таблице результатов RT есть несколько строчек по одному и тому же виду оплаты с разными суммами? На предприятии до внедрения расчёта ЗП в SAP ERP была принята именно такая практика — например, налог ложится на один и тот же вид оплаты, но показывается в расчётном листке несколькими суммами: удержанный из премии и удержанный из основной зарплаты. В SAP ERP есть вариант завести для таких случаев несколько разных видов оплаты, но это неидеальный путь (таких новых видов оплаты потребуется не так и мало, а их нужно будет настраивать отдельно, и они засорят справочник видов оплаты), поэтому сначала хочу узнать Ваше мнение: единственный ли это выход?

Ответ:

Короткий ответ — сталкивался, но никакого смысла в этом не нашел и сейчас не вижу. Сначала о причинах. Такое решение обычно появляется там, где прежнюю систему АСУ просто скопировали в САП. Зачастую на больших предприятиях Советского устоя многие виды начислений и удержания считали вручную. При перерасчетах или межрасчетах бухгалтерам приходилось вручную считать налоги и алименты. Это и наложило свой отпечаток на нынешние реалии. Люди просто так привыкли и не могут измениться. Никакой бизнес выгоды я в этом не вижу.

В России, насколько мне известно, расчетный листок не является официальным налоговым документом (в США является, например). Разделение налогов по видам начислений никак не поможет работнику отчитаться по налогам, ибо нет такой необходимости. Отчитывается предприятие. Даже в случае различных ставок по налогам компания подает декларацию за работника. В 2-НДФЛ виды начислений, льгот также разделяются укрупненно, а не по каждому виду оплаты. Ставка налога также «плоская», поэтому нет сложности его посчитать в отличие от тех же Штатов.

Резюме: сделать можно, но не нужно. Вообще не нужно.