Добрый день, коллеги!
Подскажите, может кто-то сталкивался с подобной ситуацией. Если да, то как решали?

Пример:
1. Посчитана регулярка января.
2. В феврале пользователь проводит межрасчет типа В с целью доначислить премию, доплату и рк\сн за январь, не дожидаясь регулярки февраля.
Межрасчет типа В пересчитывает январь. Дельты доначисления за январь прилетают через RUCDT с сохранением сплитов С2 (дата получения дохода январь).
3. Затем проводится регулярка февраля.
В регулярку февраля отрабатывает RURTR OC. Берет ORT из межрасчета типа B. Берет февральскую IT и RT.
ORT (/120 и ptimary_wt) запоминает в old_data.
Собирает таблицу дельт, при этом уменьшая текущие суммы по /120 и primary_wt на суммы из межрасчета типа B.
Потом old_data и собранные дельты выкидывает в текущую IT и RT.

В итоге на выходе имеем:
/120 со сплитом С2 февраля (заниженный на дельту из межрасчета типа В)
/120 со сплитом С2 января (на сумму дельты из межрасчета типа В)

Это дело приходит на вход в RUTAX.
RUTAX по умолчанию сортирует IT сначала по дате получения дохода.

Т.е. первым в обработку пойдет /120 с январским RUDAT.
От него посчитается вычет на ребенка.

В итоге имеем, что и январский вычет на ребенка и февральский вычет на ребенка имеют сплит С2 января и в 6-НДФЛ оба вычет уйдут в январь.

Помогите советом, что-то я уперся))

Приветствую!
Как понимаю, пересчитываете в межрасчете В доход SALA?
У вас дата получения дохода при положительной дельте определяется по какому правилу?
Насколько помню, должно быть по "в периоду", тогда у дохода будет дата получения февраль, и вычет распределиться верно.

Если у вас по "для периоду", то надо проверить, каким образом у вас настроена передача дельт в межрасчете типа В в итоговый расчет, какие суммы в RT/RURT сохраняются.

Посмотрите, ещё эти ноты. Вдруг, поможет:
1960480
1980303 (для СЕ)
2127306

Влезу в тему...
У меня ситуация обратная, есть межрасчет с причиной 0104 типа B. Далее выполняется регулярка и в регулярке не видно выплаты из 0104. Посмотрел RURTR OC, а там DELETE lt_loop_rgdir WHERE occat = cd_occat-advance_on_corr.
Т.е. удаляется из анализа межрасчет с причиной 0104. Коллеги, у вас также? Как тогда анализировать межрасчет 0104?

Приветствую!

У нас нет такого действия:
DELETE lt_loop_rgdir WHERE occat = cd_occat-advance_on_corr.

А какой у вас патч стоит?

Екатерина

один из последних. 608B3 + все последние ноты.
Это как раз появилось в последних нотах, которые связаны с ФЗ-263

Смотрела на "свежей" системе, но 604-й.

В версии 6.08 интересующая вас строка есть. Изменения поставляются по ноте 3273021 - Additional changes to personal income tax calculation in off-cycles according to 263-FZ . Для 6.04 действительно такого фрагмента не вижу, скорее всего по причине отсутствия в 6.04 логики FSSCS.

Пока сам подлатал RURTR.
Сап ответил:
По Вашему запросу будет выпущена Нота с необходимыми корректурами.
К сожалению, на данный момент планируемая дата выпуска Ноты не определена. Мы сообщим Вам о выпуске Ноты при первой возможности.

Тоже пришлось анализировать ситуацию с межрасчетом 0104. И тоже пришел к выводу, что 0104 нужно исключать из обработки RURTR OC, то есть воспроизвести действия, которое сделал SAP

Но отключение должно только для согласования доходов текущего расчета и межрасчетов. RURTR OC еще загружает межрасчетные выплаты и суммы удержаний НДФЛ. Для этих действий обрабокта 0104 должна сохранится.

Почему 0104 нужно пропустить для согласования доходов текущего расчета и межрасчетов?
0104 - это чистый перерасчет прошлых периодов, расчета текущего периода в нем нет. Когда 0104 делает расчет прошлого периода, то все дельты попадут в расчет текущего периода. Затем, когда будет выполняться рег.расчет, то дельты прошлых периодов будут согласованы в RURTR в своих периодах, а затем повторно в RURTR OC текущего периода. И это будет ошибкой.

Пример.
2023 год, когда с аванс выплачивается НДФЛ.
на 15.01.2023 провели аванс с ВО оклад на 10тыс руб (дата получения 15.01)
на 20.01.2023 провели 0104, где был пересчитан ВО за 12.2022 оклад на 12 тыс. руб (дата получения 20.01)

Теперь делаем рег.расчет 01.2023.
Там повторяется изменение оклада на 12.2022. RURTR согласует это изменение на дату 20.01 (данные возьмутся из RURT межрасчета 0104). Тут все Ок.
Далее делаем собственно расчет за 01.2023. Сумма оклад пусть будет 30тыс.
Если RURTR OC загрузит 0104, то он согласует (перенесет на фактические даты) оклад на 10тыс (аванс на 15.01) и на 12 тыс (0104 на 20.01). То есть, новый доход будет только на 8 тыс. Но это неправильно, новый доход здесь 30-10=20тыс.
Если 0104 не загружать, то результат будет правильным. Перерасчет оклада 12.2022 будет согласован RURTR именно в 12.2022, а в 01.2023 повторной обработки не будет.

Повторю, обработка 0104 для целей загрузки межрасчетных выплат и удержанного НДФЛ (ВО/P22) должны остаться.

Правда похожая проблема будет и у 0105, а для него такое решение работать не будет.

Да, все так с 0104. Пока я решил так - убрать только ВО с доходом:
IF ls_loop_rgdir-occat = cd_occat-advance_on_corr.
LOOP AT lt_ort ASSIGNING <ls_ort>.
lo_t512w_reader->read_wage_type( EXPORTING iv_begda = aper-endda
iv_endda = aper-endda
iv_molga = calcmolga
iv_lgart = <ls_ort>-lgart
IMPORTING es_t512w = DATA(zzls_t512w) ).
IF lo_t512w_reader->is_accumulation_class_set( is_t512w = zzls_t512w iv_cumul = lc_01_cumul ).
DELETE TABLE lt_ort FROM <ls_ort>.
ENDIF.
ENDLOOP.
ENDIF.

Соответственно, в обработку попадут базы с датами дохода(они должны у нас через grt передаться в текущий период)+налоги и межвыплаты.
С МР 0105 такой ситуации нет кстати. Во всяком случае при включенном FSSCS. Т.к. таблица RT начинает перезаписываться актуальным расчетом.

с 0104 много проблем. Например, если после него есть другой межрасчет типа B. Как заявка для ФСС 0108. Тогда дельты из 0104 и предыдущего регулярного расчета теряются для обработки. Получается актуальным расчет 0108, а предыдущий 0104. Но у них одинаковые RURTR, т.к. 0108 не пересчитывает предыдущие периоды, а только копирует RURT. Поэтому RURTR не увидит разницы.

Добрый день!
Похоже, что по описываемой Вами проблеме все-таки выпустили ноты. 3278940 - Incorrect transfer sum after off-cycle run with Advance on Correction Accounting reason и 3300732 - Prerequisite objects for SAP Note 3278940.

Да, мне вчера ответил SAP на мой тикет, что эту ноту сделали