Добрый день,

При перерасчете прошлых периодов измененный вид оплаты "Для периода" необходимо рассчитывать с учетом всех видов оплат "В периоде".
К примеру, вид оплаты изменен в сентябре для августа. Сумма августовского ВО определяется с учетом видов сентября.
Ложится он должен для августа, для корректного расчета средней.

Возможно ли такое реализовать???

Уточните, пожалуйста: есть ВО1 который вычисляется как ВО1 = ВО2 + ВО3 (условно)
В расчете августа в августе этих ВО нет. Но ВО2 и ВО3 ввели, допустим, в ИТ15 на 31.08 в сентябре (сумма пусть будет 100)
ВО1, ВО2 - для-период
ВО3 - в-период
Вопрос:
чему равны ВО в каждом расчете
08.2014 09.2014 ВО1 = ? ; ВО2 = ? ; ВО3 = ?
09.2014 09.2014 ВО1 = ? ; ВО2 = ? ; ВО3 = ?

Если вариант такой:
08.2014 09.2014 ВО1 = ВО2 + ВО3 = 200 ; ВО2 = 100 ; ВО3 = 0
09.2014 09.2014 ВО1 = 0 ; ВО2 = 0 ; ВО3 = 100

то я бы в расчете сделал копию ВО3, скажем ВО4, но с настройкой для-период и вычислял ВО1 как ВО2 + ВО4.

Можете написать постановку задачи подробнее?

К примеру,

в сентябре для августа была введена мед.страховка(ВО1) суммой 200.

В сентябре для сентября есть отпуск длительный суммой 1500000(ВО2).

Так как сумма отпуска большая(к примеру больше 1400000), то сумма мед. страховки будет 200. В противном случае должна быть 230.

Сумма мед. страховки должна лечь для августа в сентябре, но рассчитывается с учетом видов оплат сентября. При этом надо учитывать все виды оплат сентября.

Такой механизм использует сам САП при расчете, например, отпуска будущего периода. Функция RUAVE запускает отдельное моделирование расчета, затем зачитывает его результат, и использует этот результат в своей работе.
Можете сделать что-то подобное. Когда необходимо посчитать ваш ВО, запускаете моделирование следующего месяца, получаете результат таблицу RT следующего месяца, складываете его в ORT или в AIT, а дальше обычными правилами реализуете свой функционал. При моделировании следующего месяца предусматриваете специальный флажок, который будет отмечать этот специальный прогон моделирования, и с помощью которого в этом режиме пропустите расчет своего ВО. Тем самым избежите рекурсию при расчете своего ВО.

Детали можно посмотреть в программе HRUCALC0, сделайте поиск по использованию ФМ HR_PAYROLL. Это ФМ для выполнения моделирования расчета, он используется в функции RUAVE.

Тогда вопрос с перерасчетами) Что будет, если отпуск пересчитается. Допустим, отпуск 09.2014 пересчитался в 10.2014 и сумма стала ниже/выше порогового значения. При этом перерасчет 08.2014 не инициируется. Если мед.страховка - это сумма удержания, причем при этом перерасчету оно не подлежит, то да, такое решение подойдет. Если же надо каким-то образом учитывать его перерасчет, то надо предусматривать инициацию перерасчета (например при перерасчете отпуска выводить сообщение о необходимости принудительного перерасчета)

Здравствуйте дамы и господа.
Надеюсь на вашу помощь.

Сотруднику 26.01.2022 во внецикле выплачены отпускные по отпуску будущего периода: с 07.02.2022 по 20.02.2022.
В феврале сотрудник приносит листок нетрудоспособности: с 27.01.2022 по 07.02.2022.
Возникает пересечение отпуска и больничного 07.02.2022.
На основании заявления сотрудника, день отпуска 07.02.2022 переносится на будущие периоды.
При регулярном расчете в феврале происходит перерасчет отпускных за январь, в котором сумма должна уменьшиться на сумму за
один день и эта разность должна быть перенесена через GRT в февральский расчет. Там что-то переносится, но пока не уверен,
что правильно, проблема заключается в другом.
В февральском расчете функция PAB обрабатывая запись таблицы AB 0100 с 08.02.2022 по 20.02.2022, создает вид оплаты
(хотя в ИТ2001 для это отсутствия указано, что оно расчитано ранее), которое в дальнейшем расчитывается в RUAVE, увеличивая
совокупный доход (в частности /120).
Т.е. оплата по отпуску происходит повторно.
Я понимаю, что перспективы нашей работы туманные, но жить нужно, может быть кто-то сталкивался с такой проблемой и может подсказать
что делать.

Заранее благодарен.

Уточню. Запись отпуска в Ит2001 теперь как заполнена?
Из текста сложилось впечатление, что отпуск считается дважды. IMHO, так быть не должно. Если поле BONDT у отпуска осталось заполнено, то оно должно попасть в расчет января, несмотря на begda февраля.
Если запись была модифицирована так, что поле BONDT получилось пустым, то отпуск должен попасть в февраль.

Здравствуйте дорогой RoustR, спасибо, что так оперативно откликнулись.
Вот теекущие реквизиты отсутствия:
begda - 08.02.2022
endda - 20.02.2022
P2001-OCRSN - 0103
P2001-BONDT - 26.01.2022
Вы поняли правильно, отсутствие оплачивается дважды.

Там должно работать так.

В расчете января.
К моменту PAB в AB должны быть записи будущего периода. Основанием для обработки должна быть дата BONDT, которая относится к текущему расчетному периоду. PAB производит оценку это отсутствия и генерирует ВО отпуска. У ВО должно быть заполнено поле NUM.

В расчете февраля.
В принципе все тоже самое, только после PAB в у ВО отпуска NUM будет равен 0. Эти записи обычно до RUAVE не доходят, так как там по пути есть правило, которое удаляет пустые записи.

Ключевым в такой обработке будет правило, которые работает в PAB и указывается в оценке отсутствия (V_T554C). По стандарту это RUO9. Там идет сравнение дат P2001-BONDT и APER-BEGDA. В этом примере в январе в результате сравнения ничего не происходит, запись ВО отпуска остается. В феврале в обработке запись обнуляется операций SUBWTI*.

RoustR, спасибо Вам огромное, посмотрю правило и послежу за NUM.
Здоровья Вам и всего наилучшего, из того что осталось.

Проблема обнаружена.
Связана она с тем, что с этого года мы стали вести планируемые отпуска.
При обработке отсутствия 0100 в правиле RUO9 в операторе TABLE 2001 выполняется следующий код
FORM READ-ATAB-NATIO HRUCALC0 PCBURRU0

поскольку при вызове скрипта в него не передается вид отсутствия (AWART или SUBTY), он возвращает первое найденное отсутствие, в нашем случае - это планируемый отпуск, у которого не заполнено BONDT.
Еще раз благодарю уважаемого RoustR-а.