Прошу поделиться опытом. Только сейчас включаем TAXDT. Как раз, чтобы перейти на саповское решение по прогрессиному НДФЛ.
При увольнении накануне выходных неверно определяется срок перечисления налога (игнорируются праздничные дни).
Например, увольнение рассчитали 20.02.21.
В RUDAT один модификатор SALA дата получения дохода=20.02.21, срок перечисления налога=22.02.21.
Срок перечисления налога должен быть 24.02.21, так как 22 и 23 - праздничные дни. В графике рабочего времени это отражено.

Неужели эта ошибка осталась в коробочном решении? Оно же используется уже более 4 лет...

В каком графике? Там работа идет с производственным календарем RU. Индивидуальный график сотрудник не имеет никакого значения
Причем это не связано с функциональностью RUDAT. В варианте обработке, когда даты получения доходов нужно было определять в 6НДФЛ была точно такая же ситуация.


В этом коробочном решении прямо в коде прописан календарь RU. Регионы с иным календарем праздников должны брать напильник.

У нас календарь RU. 22.02.2021 - в этом календаре рабочий понедельник.
А Правительство РФ сделало его выходным. Получается при увольнении сегодня 20.02.2021 срок перечисления должен быть следующий рабочий день 24.02.2021. А SAP определяет 22.02.2021.
Это же неверно?

Когда-то в 2018 разбирал соответствующие методы, определяющие даты для RUDAT, обнаружил там вызов функции ядра, которая определяла является ли дата рабочим днем. Поскольку это был не абап, понять принцип работы было затруднительно, но мне показалось, что этот фм анализирует недельный график рабочего времени и календарь праздничных дней. Вне зависимости от того стоял ли в конкретном календарном дне однодневный рабочий график или однодневный график выходного дня, система определяла его как рабочий день, вероятно на основе графика за период (недельного графика). Может быть вы разбирались более подробно и можете сказать какие необходимо сделать настройки в графике рабочего времени, чтобы система определила 22.02.2021 как выходной день.
Спасибо.

Вы не можете заполнить производственный календарь в соответствии с законодательным изменением?

Производственный календарь (ПК) - это отдельная сущность. ПК никак не связан с графиками сотрудника в ИТ0007, для него не применимо понятие однодневного графика или графика работы на период (недельный график). Это просто календарный год, где указанны выходные и праздничные дни.
Ведется в SPRO отдельно (настройка, по моему, даже мандантонезависимая). Заходим в spro - Управление временными данными - Графики рабочего времени - Определение классов праздников.
Заходим, выбираем "производственный календарь", находим RU, открываем, заходим в особые правила и прописываем переносы выходных дней.
Затем для проверки заходим в режим календаря и проверяем, что 20.02.2021 - это рабочий день, а 22.02.2021 - выходной.

Реализация определения срока уплаты налога.
Определение дат дохода реализован через BADI, базовый класс реализации BADI - CL_HRPAYRU_IM_PAYDATES. в нем есть метод GET_NEXT_BUSINESS_DAY, который собственно и реализует определение следующего рабочего дня. На данный момент реализация строиться на использовании класса производственного календаря - cl_timecalendar_generic, где реализуется интерфейс IF_TIMECALENDAR.
Здесь есть метод IF_TIMECALENDAR~MOVE_DAYS, где происходит сдвиг.
Если копать глубже, то действительно можно найти вызовы фукнции, реализованных не на ABAP. Но лично у меня никогда не было необходимости копать так глубоко.

Ну, все же 22.02 действительно не совсем прям безусловный выходной:

из чего следует, что у тех сотрудников, у кого согласно их графику работы суббота был выходным, то выходным станет понедельник (а суббота, соответственно, рабочей, причем по понедельнику - именно поэтому суббота для 5-ти дневного графика была сокращенная на 1 час - потому как понедельник был предпраздничным днем.
Вторым выводом из всего этого следует, что у тех, у кого суббота была по их графику рабочей, она никуда не переносится, а понедельник также остается привычно рабочим-предпразднично-укороченным.

Теперь к теме: если у вас было бы 2 сотрудника, работающих один по 5-ти дневному, а второй - по 6-тидневному графику, и вы бы их обоих уволили 20.02. Получается, у "5-тидневного" сотрудника следующий рабочий день ожидался бы 24-го, а у "6-ти дневного" - 22-го. Это все в строгом соответствии с законом (ТК РФ).
Так а срок перечисления налога был бы у них обоих одинакоый (какой) или разный?
(я не в курсе как по закону, если что ).

На мой взгляд, срок уплаты налога никак не связан с графиком работы сотрудника. Он скорее всего связан с графиком работы подразделения, которое производит расчет заработной платы, и банка, куда происходит перечисление налоговых платежей. Что с того, что у сотрудника по его графику следующий день рабочий, он ведь не сам перечисляет налог. Бухгалтерия не работает, банк не работает.
Вот и в SAP этот механизм вообще не связан с графиком работы конкретного сотрудника. Все завязано по ПК, который не только не связан с сотрудником, он даже не связан с организаций. Сам по себе. Все организации в системе используют один единый календарь.

Коллеги, добрый день. Активировали функцию , но почему то в RUDAT переопределяются даты межрасчетных выплат в актуальном расчете и соответственно не корректно формируется 6 НДФЛ. Может кто сталкивался с такой ситуацией.

Межрасчетные выплаты были сделаны до активации? То есть, в межрасчетах в RUDAT поле LGTAX не заполнено, а в выполняемом расчете оно заполнено?
Если так, то причина в этом. RURTR не сопоставляет такие записи RUDAT, считает их разными. Поэтому отнесения доходов, которые прошли в межрасчет, на фактические даты не происходит.

Как раз есть межрасчет 108 с заполненной датой в rudat 15.02, а при окончательном расчете даты подменяются по этим видам оплат на 01.03.

Коллеги, прошу помочь,
активировали TAXDT с 2021 года и только сейчас в марте обнаружили проблему, а именно, перерасчеты прошлых периодов 2021 года в справку 2-НДФЛ попадают в периоды где эти перерасчеты возникли. то есть фактически справка работает по принципу "для периода". Например, начислили больничный в марте за январь, так этот больничный отразится в доходе за январь. Или пересчитали оклад также в марте за январь и измененения в справки будет январем. В RUDAT для ретрорасчетов фактическая дата стоит актуальная для этого прошлого периода (31.01.21). BAdI: определение дат платежей - пока не правили, возможно упустили какую-то настройку.
Бизнес такой подход категорически не устраивает, но как поправить не очень понятно.

Да, так и есть. Функциональность RUDAT работает по дате дохода. Если в марте пересчитали оклад января, то это изменение будет относится к январю. Типа, это соответствует налоговому кодексу. В обратную сторону тоже примеры есть. Например, если в расчет декабря попадет отпуск следующего года, то в 2НДФЛ этот отпуск будет отражен в следующем году.
Я понимаю, что картина этой области мира по принципу в-период была значительно проще, но кто-то вчитался в букву налогового кодекса и сказал, что правильно - для-период.

Технически за определения дат дохода в расчете отвечает операция RUDAT=I, которая создает сплит CNTR2 на RUDAT. В этот момент срабатывает BADI определения дат дохода в режиме в для-период (посмотрите вызов oprudat_core_i в операции RUDAT).
Для обратного расчет происходит тоже самое - первоначально работает определение сплита RUDAT=I, которое формирует даты дохода заново (то есть, не те даты, которые были фактически в первоначальном расчете). Но далее работает функции RURTR, которая сопоставляет данные текущего и прошлого расчетов - вычленяет из нового расчета доходы, которые прошли раньше, сажает их на старые даты (формирует новые записи в RUDAT с фактическими датами). Если произошло изменение сумм дохода, то эти дельты сажаются на новые даты. В этот момент работает метод is_for_period_calc BADI hrpayru_b_paydates, который определяет как будут формироваться даты (в-период/для-период) (см. процедуру check_retro_method). Конечное поведение зависет еще знака суммы дельты - положительные будет формировать новые доходы, отрицательные относится к старым доходам.

Здравствуйте. Уважаемый RoustR, большое спасибо за помощь.
При тестировании нового функционала (TAXDT активирован) столкнулись со следующей проблемой, касающейся функции RURTR с параметром вызова OC (схема RUO3).
В расчетном периода два внециклических расчета:
- 16.02.2021 расчет аванса (категория внецикла 09 - Ежемесячный аванс (рассчитанный на дату))
- 23.02.2021 увольнение (категория внецикла 14 - Уход из компании)
Производим регулярный расчет за 02.2021 и видим сумму к перечислению равную сумме аванса.
Находим в инклюде PCMASRU1_RURTR в подпрограмме get_old_results_rcoc следующий код:
* adjust by last paid OC category -> previous results should not be included
SORT lt_loop_rgdir[] BY seqnr.
DATA lv_rgdir_lines TYPE i.
lv_rgdir_lines = lines( lt_loop_rgdir[] ).
IF lv_rgdir_lines GT 0.
READ TABLE lt_loop_rgdir[] INTO ls_loop_rgdir INDEX lv_rgdir_lines.
IF ls_loop_rgdir-occat = cd_occat-leaving.
DELETE lt_loop_rgdir[] WHERE seqnr LT ls_loop_rgdir-seqnr.
ENDIF.
ENDIF.
Оператор DELETE удаляет все внециклы до внецикла с 14 категорией, те, в нашем случае удаляется расчет аванса.
Таким образом, в регулярном расчете в вид оплаты MADV (Выплаты в межрасч.период) попадает только сумма перечисления от 23.02.2021, а сумма аванса выплачивается повторно.

Подскажите пожалуйста, что мы делаем неправильно?
Заранее благодарю.

1. По поводу приведенного кода отбора межрасчета. На мой взгляд, он верный. Причем, такая обработка межрасчета 0105 появилась относительно недавно. До этого приходилось самому добавлять такую обработку, подламывая стандартный код.
Дело в том, что межрасчета 0105 - это полный расчет. Он содержит в себе данные всех предшествующих межрасчетов. Поэтому для распределения доходов по датам фактических выплат достаточно обработать последний межрасчет увольнения, и последующие межрасчеты, если они есть. Другими словами, можно игнорировать другие межрасчеты, которые произошли до последнего расчета увольнения.
Это было условие "можно", теперь почему это "нужно". Реализация обработки в RURTR такова, что если межрасчеты до увольнения не игнорировать, то события выплат обрабатывались дважды: сначала в составе собственного межрасчета, затем в составе межрасчета увольнения. Это приводило к артефактам обработки. Еще хуже была ситуация, если бы выполнен два последовательных межрасчета увольнения (уволили, сделали 0105, выплатили. Затем оказалось что-то упустили, ввели что-то еще, сделали новый 0105, выплатили). Такая последовательность обрабатывалась с ошибкой.
Отсечение всех межрасчетов до последнего увольнения решает эту проблему.

2. Никогда не работал с ВО М* напрямую. MADV - это межрасчетная выплата? Тогда вопрос не понятен. RURTR не занимает анализом именно выплат и никак не определяет сумму выплаты текущего дохода. RURTR занимается вопросом отнесения доходов по дате выплаты. Он работает только с ВО, которые имеют отношение к расчету НДФЛ - оклад, отпускные, больничные и т.п. С выплатами (деньги, которые получил сотрудник) RURTR не работает.
Если бы вопрос был задан по поводу, например, ВО оклада, то вариант ответам мог бы быть. САП исходит из того, что с аванса НДФЛ не уплачивается. По этой причине RURTR OC не учитывает межрасчет аванса в свой работе.
Если были выполнены межрасчеты авансы и потом увольнения, то
- в межрасчет аванса какие-то даты будут, но они не имеют особого смысла, так как потом не учитываются.
- в межрасчет увольнения формируются новые даты, относительно самого межрасчета увольнения. RURTR OС по авансу корректировку дат не производит.
- последующий рег. расчет делает анализ по межрасчету увольнения, восстанавливая даты, которые были зафиксированы в 0105. Анализ предшествующих межрасечтов здесь не требуется.