Тексты экранов можно вбить переводами в se38 перенос через SLXT.

P_APPL Субприложение
P_APSRV Сервер приложений
P_INSTL Данные организации
P_LFNAME Логический файл
P_MAP Сгенерировать карту решений
P_MON Ид. периода
P_PATH Путь выгрузки
P_PRSRV Сервер презентации
P_RIMNS Налоговая инспекция-получатель
P_SOORT Тип организации
P_VARI Формат
P_YEAR Год

FRM Электронный формат
S01 Период
S02 Данные юридического лица
S03 Параметры вывода
S04 Внециклический прогон
T01 6-НДФЛ
T02 Отчет - карта решений
T03 Выгрузка XML
T04 Ставка
T05 Просмотр XML

Не успел поправить свой пост -

SE51 при попытке перевода говорит что "Empty object list; Message no. TL565"

В общем не дает почему-то перевод выполнить никак в подэкранах 1000, 500, 501, 502.

Через SE38 в программе RPCPAYRU_6NDFL переводы выполнились нормально.

Да, и у меня почему-то отсутствуют тексты TEXT-S01, S02, S03 и т.д. Ноты все вкатились нормально.

Посмотрел отчет RPUPAYRU_NOTE_2268978 из пререквизитной ноты - там эти тексты должны были создаться, форма 71, почему не создались не понятно.

Текстовые ID пересоздал, перевод сделал, все ок.
Единственно что сейчас нет текстов для TABSTRIP_T1 и перевод тоже не делается - какой там текст вообще должен быть на закладках?

Пардон, протупил - теперь всё ок.

Коллеги, подскажите как настроить счетчик получателей дохода. Сейчас он всегда равен 1.

Ничего не настраивал. Счетчик уже работал.
Может чего в DAQ полях крутили для RECNU?

Да, ошибся при настройке - был установлен флаг КлючРаздела.

Коллеги, добрый день.

Есть две ситуации. Первая (корректная):
1) в кластере идет строка с расчетом аванса (причина 0101) и строка с основным расчетом.
В 6-ндфл по суммам выводится всё как надо: 1-я строка аванс, 2-я строка "зп"-"аванс".

Вторая (некорректная)
1) в кластере идет строка с расчетом аванса (причина 0101), затем идет строка с межрасчетом увольнения (причина 0105) и строка с основным расчетом.
В 6-ндфл по суммам выводится: 1-я строка аванс, 2-я строка межрасчет увольнение (и в сумму включен аванс - ошибка), 3-я строка "зп"-"аванс"-"межрасчет увольнение" (получается минусовой из-за аванса, который в межрасчете увольнение).

Кто-нибудь сталкивался с такой ситуацией? Как системе дать понять что из межжрасчета увольнения надо вычитать аванс?

Да, я эту проблему здесь описывал.

Ошибка там в следующем. Собираются данные, есть межрасчеты, есть регулярный расчет. Регулярный расчет содержит в себе те же данные, что и межрасчеты, поэтому организуется вычитание таких сумм из данных регулярного расчета.
Но межрасчет типа B в этом отношении такой же, как и регулярный расчет. Из него тоже нужно вычитать предыдущие межрасчеты. Это не происходило. В итоге межрасчет типа B показывается весь как есть, по регулярному расчету подбивается баланс, и возникает минусовая строка.

ROMP
В стандарте межрасчет увольнение это внецикл типа В, то есть он видит межрасчет аванса. В стандарте увольнение соответстует категории 14 и индикатору О4 в T51P1. Настройте перенос налога через T51P1-О4 в межрасчет увольнение, и потом этот код в настройку отчета тоже. Коды и индикаторы у вас могут отличаться, нужно смотреть по обстоятельствам.

RoustR, msv, благодарю за ответ.

RoustR, я посмотрел, ноты в доступе нет. У меня вопрос, вы пишите:

Верно я понимаю, что нота, про которую шла речь - помогла? Или у вас эта проблема до сих пор актуальна? Или вы как-то по другому её решили?

msv, у меня проблемы не только с налогом, а с исходными суммами (аванса, зп и межрасчета увольнения). У меня есть настройки в ракурсе T51P1 (видимо исторические), там все межрасчеты "скидываются" на ВО MADV. Но нам не подходит этот путь, так как в MADV сидит сумма net, а 6-ндфл выводится сумма гросс. Или я что-то не так понял из вашего предложения?

ROMP
Вопрос скорее про внециклы, чем про 6-НДФЛ, но все же.
Посмотрите на T51P1 в 000, как настроены индикаторы O2 и OC к примеру. O2 это маппинг для авансовой выплаты, OC - это маппинг для переноса из аванса в регулярный расчет.
Для O2 в стандарте работает такой маппинг:
/322 -> /O22
0020 -> O001
итд..
В результате в кластере в RT для записи рачета аванса будут лежать ВО /O22 для налога и O001 для оклада. Это позволяет отделить виды оплат расчитанные во внецикле от таковых в регулярном расчете.
Далее посмотритет на индикатор OC, он отрабатывает в момент регулярного рачета, для маппинга ВО которые лежат во внециклических результатах расчета для текущего расчетного периода. (В схеме ищите цикл RCOC, это если стандарт, там же пять строк выше него обработка результатов для типа В - то есть для нашего увольнения, классы обработки 62 и 75.)
Для OC маппинг такой в стандарте:
/O22 -> /I22
То есть в регулятном расчете у нас будет лежать ВО /322 с полной суммой налога за весь месяц, а в /I22 - налог что был уплачен во внецикле. Далее включая их оба в отчет в соответствующие коды можно получить желаемый результат.
Базируясь на том же принципе можно настроить и проброс ВО на разные коды через индикатор O4 и в межрасчет увольнения, и затем из всех этих межрасчетов в регулярный расчет.
Тут нужно просто маппинг продумать наиболее подходящий, ну и настроить соответственно.

Я обнаружил эту ошибку, выставлял сообщение об ошибке, ждал какое-то время, потом сделал сам с помощью расширения. Когда ноту дали, я ее уже не ставил, времени пока нет. Судя по тексту исправлений, нота должна помочь.

Если ноту не видите, напишите в САП что хотите тестировать, пусть дадут доступ.

msv, там дело не в этом. САП не использует этот механизм в 6НДФЛ. Он явно вычитает суммы межрасчетов из регулярного расчета. Обработка стартует из ФМ HR_RU_DAQ_NDFL_AMOUNTS, вызов процедуры post_process_wages. post_process_wages в свою очередь перебирает объекты класса cl_hrpayru_payfactx, и вызывает у них метод post_process_wages, где собственно все и происходит.
Вот пример кода из cl_hrpayru_payfactx-post_process_wages
этот кусок кода обрабатывает запись межрасчета, уменьшая сумму регулярного расчета.

Нота, которую я привел, как раз и модифицирует методы GET_REGULAR_RUN_TO_REDUCE и POST_PROCESS_WAGES. Там появляется дополнительный цикл, аналогичный существующему, который выполняет ту же операцию для межрасчета B.