Спасибо за ответ, уважаемый RoustR, я не понял, почему вы считаете такую логику правильной.
Допускаю, что могут возникать проблемы из-за разделения САПом расчетов на виды A и B, но, согласно логики НДФЛ, для корректного вычисления суммы для перечисления все расчеты должны производиться накопительным итогом за расчетный налоговый период (за год), после чего вычисляются дельты для начислений/перечислений.

MADV - это сумма, полученная сотрудником на руки в межрасчетный период, например, перечисленная на счет сотрудника.

Давайте я попробую на цифрах.
Предположим, у сотрудника оклад 2000 рублей, 20 рабочих дней в месяце
1 расчет (отпуск 5 дней)
предположим среднедневной равен 100 рублям.
Начислено в/о 3000 - 500 рублей, налог - 65 рублей, для перечисления на счет сотрудника /559 - 435 рублей
2 расчет (аванс) - часть оклада за отработанный период.
предположим расчета аванса производится ровно в середине рабочего период, т.е. рабочее время по графику 10 дней, фактически отработанное время - 5 дней:
Начислено в/о 0020 - 500 рублей, для перечисления на счет сотрудника /559 - 500 рублей
3 расчет (увольнение) - полный расчет за фактически отработанное время, предположим - 10 дней
Начислено в/о 0020 - 1000 рублей, отпускные в/о 3000 - 500 рублей, налог 195 рублей, MADV (перечислено сотруднику на счет в межрасчетный период) - (435 + 500) рублей
в/о 0020 + в/о 3000 - в/о /322 - в/о MADV = 1000 + 500 - 195 - (435 + 500) = 370 рублей
итого для перечисления на счет сотрудника в/о /559 - 370 рублей
4 расчет (регулярный)
Начислено в/о 0020 - 1000 рублей, отпускные в/о 3000 - 500 рублей, налог 195 рублей,
>>> MADV (перечислено сотруднику на счет в межрасчетный период) - (435 + 500 + 370) рублей
в/о 0020 + в/о 3000 - в/о /322 - в/о MADV = 1000 + 500 - 195 - (435 + 500 + 370) = 0 рублей
итого для перечисления на счет сотрудника в/о /559 - 0 рублей

В нашем случае в регулярный расчет попадает только сумма перечисленная на счет сотрудника в момент увольнения, т.е 370 рублей
И получается вот что:
в/о 0020 - в/о /322 - в/о MADV = 1500 - 195 - 370 = 935 рублей
>>> Таким образом ранее выплаченная в межрасчете сумма попадает к выплате повторно <<<
Происходит это именно потому, что удаляются все другие межрасчеты, выполненные до увольнения.

Если посмотреть схему расчета RUO3, то видно, что старая логика работала корректно
IF RUDK НДФЛ с разбивкой по датам?
RURTR OC Импорт OC результ и классиф
ELSE
*** старая логика
LPBEG RCOC Через все внециклические рас
IMPRT O Импорт результатов в O* табл
PORT RUO1 GEN NOAB Перенос в/о из ORT в IT
PIT RUDM GEN NOAB OT -> IT
LPEND Конец цикла
*** старая логика
ENDIF Конец обработки НДФЛ по дата

функция LPBEG RCOC перебирала все внециклические расчеты и в MADV складывались все суммы перечисленные сотруднику на счет, т.е. (435 + 500 + 370)

Надеюсь, что написал понятно.

Забавно.

В системе, в которой я работаю сейчас, вызов RURTR OC не отменяется работу цикла LPBEG RCOC по межрасчетам. То есть, фрагмент схемы выглядит примерно так
Поэтому в этой схеме описанная проблема не стоит. Межрасчетные выплаты загружаются вне функции RURTR OC. Здесь собственная функциональность по выплатам. Не обращал внимание, что RURTR OC в стандарте еще и межрасчетные выплаты грузит. Тогда у SAPа здесь косяк.

Повторю, это было достаточно свежее изменение. Вот нашел ноту, которая должна исправлять эту проблему, судя по описанию - 3015700 - Wrong payments after OC leaving

Да, похоже на нашу проблему.
Спасибо вам большое за участие, попробуем установить ноту.

Добрый день! А кто-нибудь сталкивался с необходимостью отдельных проводок для сумм 13% и 15% НДФЛа? После установки ноты 3001043 в таблицу V_T51P1 были для индикатора T0 для видов оплат /32C и /32D новые позиции ВО /32E и /32F (НДФЛ: проводка 13% и 15% соответственно), однако какой-либо информации по их использованию/настройке найти не удалось, более того в результатах расчета их так же не наблюдаю.

Там ведь КБК разный будет, поэтому НДФЛ 13% и 15% необходимо проводить отдельно.

А как это реализовать? Может подскажите, где можно почитать/посмотреть?

Здравствуйте, столкнулись с очередной проблемой после активации признака TAXDT.
Проблема заключается в том, что при обратном расчете в периодах до включения признака TAXDT неверно определяется модификатор вида оплаты WTMOD (таблица RUDAT).
Если посмотреть код функции RUSI0, то там есть такой блок операторов:
IF lv_value EQ abap_true.
ot-v0znr = <l_wa_ity>-v0znr.
ELSE.
* вот такая строка, которая просто присваивает сплит по номеру записи, т.е. 01, 02 и тд
ot-cntr2 = sy-tabix.
IF aper-occat = cd_occat-maternity.
ot-cntr3 = ot-abznr.
ELSE.
ot-cntr3 = <l_wa_ity>-yearm+4(2).
ENDIF.
ENDIF.
Далее, в классе CL_HRPAYRU_ADJUST_RUDAT есть такого вида код:
READ TABLE it_orudat INTO ls_orudat WITH KEY cntr2 = ls_ot-cntr2.
И если в таблице ORUDAT на момент чтения есть запись со сплитом 01, то для обрабатываемого вида оплаты, например для больничного листа, берется тот модификатор, который уже присутствует в 01 сплите ORUDAT. Поэтому больничный за счет работодателя может иметь модификатор OTHE, SALA вместо достоверного SICK.
Если вы сталкивались с такой проблемой, как вы ее решили?
Заранее благодарю.

До появления подсистемы TAXDT функция RUSI0 у больничных в CNTR2 прописывал порядковый номер записи. TAXDT задействовал CNTR2 для своих целей, поэтому в коде RUSI0 появился приведенный код - если подсистема TAXDT активна, то CNTR2 не заполняем (оставляем на нужны TAXDT), в противном случае работаем как прежде. Не вижу в этом коде ничего предосудительного.

Далее упоминается CL_HRPAYRU_ADJUST_RUDAT, но не говорится в каком контексте он работает. Раз речь идет о обратном расчете, то вероятно речь идет о RURTR. Функция должна согласовать изменения дохода и определить новые даты для дельт. Где-то здесь нарушение логики работы, раз происходит обработка старого заполнения CNTR2 как ссылки на RUDAT. Там нужно смотреть.
Кроме того, в RURTR есть особая обработка больничных.
И еще один момент. Раз это больничные, то сюда может оказывать влияние подсистема ППФФС. Эта подсистема сама ведет вычисление дельт, и RURTR это учитывает. Вот пример из ее кода

Короче, вариантов, где что-то может пойти не так, масса. Разбираться нужно в конкретной системе.

Коллеги, кто-нибудь начал работать в направлении: с 2023г. порог 5 млн.рублей определяется по всем выплатам ФЛ, т.е. с совокупности баз указанных в подпунктах 2-9 пункта 2.1 статьи 210 НК РФ? Как можно объединить в SAP HR базы из разных систем? Поделитесь, пожалуйста идеями.