Честно говоря, странно, что суммы задвоились, а не занулились. Вы в отладке когда-нибудь смотрели, как обработка расчетов происходит? Если да, то вот такой порядок следования расчетов ничего не напоминает?

Это классический пример обработки перерасчета, за исключением того, что все это происходит в одном месяце. А раз это перерасчет, и при условии того, что расчеты по ЮЛ1 одинаковые, то они должны аннигилировать друг друга (расчет с P идет с "-", расчет A с "+", итог 0).

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

ЗЫ. Внимание, фразу "удалил средний расчет" не следует воспринимать как прямое указание. В общем случае нужно удалить все расчеты по ЕР2 и сделать заново уже без пересчета. В частных случаях можно обойтись удалением именно среднего расчета без выполнения перерасчета, но нужно хорошо понимать, когда это допустимо.

Про расчеты и перерасчеты понятно. Отладка показала что метод READ_CLUSTER_PERSON считывает для данного периода три результата и присваивает всем SRTZA = A. Тогда как программа HRULNDFL и ее метод READ_CLUSTER первому результату присваивает SRTZA =P, а в итоге оставляет только два последних результата. HRULNDFL работает корректно, то есть ничего не задваивает.

У нас переход между ЮЛ обычное дело и перерасчеты из текущего за предыдущее тоже. Обычно проблем не было. Возможно проблема именно в перерасчетах внутри одного месяца.
Вся остальная отчетность работает корректно.
Посмотрел в копии системы за 2016 год - проблема уже была и там.

Да, именно в этом. Особенность этого случая скорее всего в том, что между расчетами по ЕР1 и ЕР2 изменили данные по сотруднику за первую половину месяца. В противном случае было бы только 2 результата расчета. То есть, здесь простая ситуация обратного расчета, просто она произошла в одном месяце.

Добрый день,
может кто сталкивался.
Сотрудник сперва работал по договору ГПХ, далее принялся на основное место работы.
у сотрудника 2 табельных номера.
в отчете 2 НДФЛ выводится 2 справки, а должны объединиться в одну.
Как можно настроить?

активирован СЕ

ТН связаны между собой?

Нет, не связаны.
а их надо связать через GROUPING в кластере расчета или объединить объектом СР?

Ну, в любом случае начать нужно с объединения по CP. Как иначе система узнает, что это одно физ.лицо? Возможно, этого уже будет достаточно.

Ну, в любом случае начать нужно с объединения по CP. Как иначе система узнает, что это одно физ.лицо? Возможно, этого уже будет достаточно.

Коллеги, добрый день!
Есть несколько вопросов по 2-НДФЛ, буду благодарна за любые наводки по ним.

1. Возникла необходимость строить справку 2-НДФЛ по последнему оргприсвоению сотрудника в периоде. То есть точное разбиение справки по ОП в рамках одного периода не нужно.
Насколько я понимаю, это решается только через корректировку расчёта налогов (не делить базы по wpbp). А можно ли на уровне отчёта повлиять (без абапа)?

2. Если сотрудник был присвоен одному ОП с 1 января, затем 1 марта задним числом поменяли ОП с 1 января, пересчитали. В актуальных расчётах в марте (за январь, февраль и март) в wpbp лежит новое ОП, а в V0 всё равно сохраняется дополнительной строкой информация о старом ОП (ссылка на соответствующий объект T7RU9A), и справка строится за первые два месяца всё равно по старому ОП. Можно ли как-то отключить учёт оргприсвоений прошлых расчётов?

3. "Растворение" отрицательных сумм - это только "подлом" отчёта, или есть предусмотренный z-include или BAdI, где можно это провернуть?

1. Нашла метод постобработки класса CL_EX_HRPAYRU_NDFL, пока вижу возможность только через него скинуть все суммы на конец периода.
2. Параметр G_NO_EXT_RECIP по описанию должен был подойти (игнорировать присвоение налоговым в V0), но не сработало.
3. = п.1, видимо.

Добрый день!
Обозначенное Вами место по коду отчета HRULNDFL обозначено комментарием "**...BADI: Postprocessing PY results before outputting". Пункт 3 чаще всего реализовывают именно в этом месте, направление верное.
По первым двум пунктам с подобным требованием отражения сложно согласиться. При использовании таких подходов на практике породите несоответствия с бухгалтерским учетом и фактическими перечислениями налога по конкретным ОКТМО/КПП.

-DoKa-, спасибо!
Вы правы, нужно ещё подумать над оргприсвоением перерасчётов.

Добрый день!
Подскажите пожалуйста ФМ, который определяет OBJID в 2НДФЛ для определения КПП и остальных налоговых реквизитов для 2НДФЛ.

Проблема возникает при присвоении к одной оргединице разных РП/ПП в разных периодах одного года. Соответственно в t7ru9a есть записи для одного OBJID с разными реквизитами в разных периодах одного года.
Но при формировании 2НДФЛ в поле EXTID заполняется непонятный третий код оргединицы OBJID, на который нет ссылки в результатах расчета.

По стандарту код OBJID для этих целей должен вернуть признак 33OKT.

Коллеги, добрый день!
Просветите пожалуйста, что за решение с использованием сплита V0 для учета доходов в 2НДФЛ? Как понять, установлено ли оно в системе, и как его можно использовать?