Здравствуйте, коллеги!
Помогите, пожалуйста, разобраться в тонкостях работы данных инфо-типов (или подскажите где об этом подробно написано).
Проблема следующая:
При копировании записи 0296 ИТ или при ограничении одной из нескольких записей 0296 ИТ связанных с одним и тем же распоряжением - 0295 (через GRNUM), соответствующая запись из 0295-го ИТ удаляется в результате проверки в CL_HRPA_INFOTYPE_0296.
Как быть если нужно изменить данные в 0296 (добавили Z-поле, которое до определенного момента должно быть пустым), и при этом избежать перерасчетов ? Как правильным образом осуществлять ведение данных ИТ (при изменении статуса в 0296 запись в 0295 также может пропасть) ?

Спасибо.

Если для разовой загрузки нового Z-поля, то в настройках инфотипа отключить релеватность для обратного расчета ЗП, загрузить инфу, вернуть настройку инфотипа в исходное состояние.
Если для ежедневной работы, то это не очень удачная идея. ИТ 0296 должен влиять на обратные расчеты.

Как альтернативный вариант:
- не трогать настройки инто-типов 296/295
- сохранить для определенной популяции ИТ 0003 просто как табличку
- загрузить ИТ 295/206 определенной популяции
- восстановить ИТ 3 для определенной популяции из ранее забекапленной таблички

При условии, что пользователи точно не работают в системе и не могут своими действиями изменить ИТ 3.

calm
ну это вопрос организационный, можно на не рабочие часы например запланировать.

Конечно.

Коллеги, большое спасибо за советы!


Да нужна разовая загрузка Z-поля. Вопрос как может себя повести ИТ0295, он не любит когда меняют 296й ? Тут срабатывает проверка в классе CL_HRPA_INFOTYPE_0296_99RU. И при изменении какого либо поля в 0296 удаляется связанный с ним 0295 (независимо от влияния на обратный расчет).

Да нужна разовая загрузка Z-поля. Вопрос как может себя повести ИТ0295, он не любит когда меняют 296й ? Тут срабатывает проверка в классе CL_HRPA_INFOTYPE_0296_99RU. И при изменении какого либо поля в 0296 удаляется связанный с ним 0295 (независимо от влияния на обратный расчет)
Может эта нота поможет.
2369497 - Renewal: infotypes 0295 and 0296 issues.

Спасибо! Судя по описанию изменений - это действительно то, что нужно. В скором времени будем устанавливать эту ноту.
Обнаружили еще одну особенность:
Копируя 0296ИТ заказчик меняет номер счета кредитора, но при формировании ОНД прогона в таблицу REGUH записывается старый счет кредитора.
Первый выход: ограничивать 0296й и 0295й инфо-типы и создавать новые.
Второй выход ломать стандарт, сейчас выбор записи 0296го происходит следующим образом (программа HRUCDTA0_CE, include PCDTMRU9_CE, Form: read_lifnr):

Т.е. выбирается первая запись для данного табельного, с данным grnum (но стандарт позволяет заводить несколько записей 296го с одинаковым grnum, есть даже настройка GV_COPY_GRNUM). Таким образом при прогоне может выбираться неактуальная запись 296го.

Коллеги, добрый день.
Столкнулись с такой проблемой. У нас есть ТН с записями в 295/296 ИТ, затем человека увольняют, записи ограничивают. Принимают его же на другой ТН, и ТН связывают. На новом ТН заводят записи в 295/296 ИТ.
Но после изменения/сохранения 0001 ИТ, например перевод, записи 295/296 на новом ТН удаляются, и на него копируются все записи со старого ТН.
При этом галка в T582a "скопировать инфо-тип" не стоит.
В таблице T588Z Дин. мероприятия тоже ничего подходящего нет.
В чем может быть ошибка? Может кто-то сталкивался с похожей ситуацией?

Поищите z-реализации бади HRPAD00INFTY.

Мы так поняли, что причина в таблице V_T582G, для 295/296 стоит группировка RUER. и хоть в таблице V_T582A галка не стоит, по группировке происходит копирование информации.
Подскажите, какую группировку можно поставить вместо RUER? и можно ли "безболезненно" удалить строки для 295/296 в таблице V_T582G

Интересно решилась ли проблема с выбором неактуальных записей? Нота или патч?