Вопрос — ответ. Временные данные по ALE

Вопрос:

Есть две SAP HCM системы, требуется из одной в другую передавать временные данные (отсутствия/присутствия/замещения). Сделать это нужно через ale стандартными средствами. Расширение HRMD_A не предлагать, это банально, да и в стандартном решении есть вроде как ветка по передаче временных данных в SAP систему из внешней системы учета времени. По сути одна внешняя система учета времени реализована на базе SAP HCM TM модуля.

Ответ:

Немного изучив данный вопрос, нашел два способа (для себя). Пока не было времени попробовать на деле, но:

  1. Мы можем передавать временные данные из CATS. В этом и заключалась идеология общего табеля рабочего времени. С помощью программы RPTEXTPT и настроенного ALE для объекта PTManagerExtAttAbs осуществляется передача данных через буферные таблицы PTEX*. То есть в одной системе мы ведем данные в CATS, а другую они попадают в живые инфотипы с помощью этой программы. Если у нас CATS не используется, то нужно решить вопрос с формированием буферных таблиц из инфотипов, чтобы построить цепочку: инфотипы системы 1 -> буферная таблица системы 1 -> ALE -> инфотипы системы 2. Как произвести такую запись стандартными средствами пока не нашел.
  2. Второй способ, это формирование текстовых файлов на сервере в общих папках и их дальнейшая загрузка в инфотипы либо напрямую в инфотипы, либо через IDOC. Загрузчик можно реализовать в виде фонового задания LSMW. Выгрузка осуществляется через инструменты экспорта, транзакция PU12.
  3. Про расширение IDOC было обозначено в вопросе, поэтому не обсуждаем.

Это то, что пришло в голову в части стандартных решений. У кого есть что добавить — прошу!

Спасибо за хитрый вопрос 🙂


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

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

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

Ответ:

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

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

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

Вопрос:

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

Ответ:

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

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

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


Вопрос — ответ. Планирование графика рабочего времени

Вопрос. планирование графика рабочего времени:

На предприятии идёт планирование графика рабочего времени, и планирование осуществляется при помощи инфо-типа 2003, а также двух подтипов инфо-типа 2002 для того, чтобы особым образом пометить некоторые запланированные часы работы. А когда приходят запланированные дни, то у некоторых работников создаются записи ИТ 2001 (кто-то заболел и т.п.). Если запись ИТ 2001 ложится на заранее созданный ИТ 2003, то всё отлично. А вот если она ложится на заранее созданный ИТ 2002, то тогда ИТ 2002 удаляется, а это плохо, т.к. теряется информация о том, что болезнь пришлась на запланированные часы работы. Позволять настройками одновременное наличие ИТ 2001 и 2002 ужасно не хочется. Помечать такие особые часы другими подтипами ИТ 2003 тоже нельзя, так как несколько записей ИТ 2003 в один день не поддерживаются (нота 1780904) компонентом Shift Planning (для планирования графика используется именно он). Сталкивались ли Вы с подобной ситуацией?

Ответ:

Один раз сталкивался с такой практикой. На тот момент времени мы выбрали следующее решение. Планирование условно разделили на две составляющие. Одна задача — это планирование для целей формирования планового графика рабочего времени для оценки времени и заработной платы. Вторая задача — для печати планового графика присутствия на работе. Плановый график присутствия не учитывается в заработной плате, не формирует плановые часы. Используется только для печати бумаги и ознакомления работника.

Автор вопроса верно подметил нюансы реализации такого подхода в системе и ее ограничения. Мы для целей рабочего времени и заработной платы также использовали инфотип 2003 с отдельным подтипом «Плановый график» — все в рамках стандартной реализации. А вот с дополнительным временем, но уже для целей графика присутствия, использовали тот же инфотип 2002 с одним исключением. Записи были в нем блокированные. С помощью ракурса V_554Y_B такие виды присутствий (плановые) были выделены в отдельный класс (Time constraint class) и разрешено их перекрытие. Так как они блокированные, то они не учитываются при учете. И тем самым мы можем их сохранять параллельно с плановыми. Такой же отчасти подход используется в графике отпусков в стандартной реализации, если мне не изменяет память.

P.S. Если у кого есть что дополнить, то присоединяйтесь. Поможем автору вопроса!