Началась самая замечательная пора в проектной деятельности — запуск проекта в промышленную эксплуатацию. Это когда ты год или два мучаешься, выпытываешь у заказчика, чего же он хочет, понимаешь, что он ничего не хочет, а тебе надо. Надо проект сдать и вовремя. И ты как бы не виноват, что заказчик не хочет.
Сегодня меня научили работать с еще двумя интересными програмками — RPUP1D00, RPUP2D00. Обе нужны для того, чтобы почистить кластеры временных данных. Это бывает нужно, когда сделали миграцию, например, запустили оценку, а она, зараза, пошла считать с даты приема сотрудника (ну забыли мы ИТ0003 поправить). И споткнулась на первой же ошибке с настройками, дальше не идет. И будет маячить ошибкой в PT_ERL00. Чистим кластер, запускаем заново оценку и вуаля.
Спасибо Ex за это!
Узнал очередную мелкую новость. Если в PPOME делаешь связь S -> P, то есть человека мышой перенес на штатку, то это еще не означает, что в PA создастся запись в ИТ0001 с нужной даты и прописанными S, C, O. Чтобы такое исправить, есть программка RHINTE30, которая анализирует подобные казусы и сама выправляет ИТ0001 по человеку. Рекомендую 😉
Чтобы не было проблем с датами при переносе, всегда устанавливайте контрольную дату в PPOME: Видео SAP HCM для начинающих. Создание штатной позиции
Загружаем зп в систему через таблицу T558B и схему Ru30. Случилось так, что человек в одном месяце был уволен и принят обратно. Один табельный номер. Как правильно положить суммы в загрузку?
С помощью отладчика выяснил следующее. В драйвере расчета до запуска схемы идет проверка на строчку PGM TRN. Если такая строчка найдена, то система игнорирует состояние управляющей записи и грузит все периоды, которые есть в T558B. Но, для корректности загрузки она внутри себя строит таблицу APER, в которой по WPBP сама собирает периоды расчета. Если человек принят повторно в месяце, то мы должны разделить расчет заработной платы на два с помощью отдельного мероприятия — повторный прием. Признак разделения устанавливается в таблице T530. Система по этому признаку наш месяц поделила на два периода расчета с одним годом и месяцем, но разными датами начала и окончания (begda-endda).
Следующим шагом система читает t558b и сравнивает периоды в ней с периодами в APER. Если не сошлись, то выдает ошибку «Расчетный период 12 в T558B не совпадает с основными данными» (период расчета может быть любой). Поэтому в T558b должно быть два периода — уволенный сотрудник (без видов оплаты), вновь принятый (с видами начислений/удержаний). Если работник уволен, а потом повторно принят с разрывом в несколько месяцев, то в таблице T558b должны быть периоды, когда работник не работал.
В HRUCALC0 смотреть здесь:
Include RPCHRT09_FILL_APER
*———————————————————————-*
* new: to this point «K11K127822*
*———————————————————————-*
WHEN ‘TRN’. «tranfer old payroll results
PERFORM check_payty_t558b.
IF NOT rueckrab IS INITIAL.
PERFORM fill_aper_for_regular_payroll «QNZ note 331016
USING fa_datum. «QNZ note 331016
PERFORM check_aper_versus_t558b.
ENDIF.
PERFORM insert_bonus_runs_from_t558b.
А еще апельсины можно загружать с помощью IDOC: LSMW и IDOC инструкция для начинающих
Случилась ситуация, что потребовалось вручную найти все таблицы, которые PU30 прописывает в запрос при копировании. Затем найти нужный вид оплаты и руками его положить в запрос, чтобы ничего не потерять.
Если кому-то понадобиться, то при копировании вида оплаты PU30 в запрос положила следующие таблицы
T511
T512T
T512W
T512Z
T51AV_2W
T52D7
T52DZ
T591B
А вот здесь хранятся следы того, что вы накопировали Протокол копирования видов оплаты
