Замечен один неприятный косяк с формой, если новый отчет отказывается генерировать карту решений ошибки в журнале вида "Component Type for Component 1 (DTENM) Not Specified", нужно создать элемент данных PRU_REPORT_FIELD_SOLMAP типа STRING в пакете PC33 (из ноты 2065598 - HCM-RU: DDIC objects for note 2061483) и все заработает.

Кто-нибудь уже думал как и чем допиливать стандартный САПовский отчет RPCPAYRU_6NDFL по формированию 6-НДФЛ в части заполнения "Раздела 2", если все расчеты по отпускным и увольнениям проходят межрасчетными выплатами, а не внециклическими расчетами?

Определенно просто собственной реализации BADI HRPAYRU_PAYFACTX будет не достаточно, тут похоже нужно брать глубже и перерабатывать CL_HRPAYRU_REPORT_CONTROL_CS предварительно переопределив его на свой класс в T7RURPTCST00.

Если есть уже проверенные решения или идеи прошу поделиться (

На мой взгляд, такая задача не имеет полноценного решения. У вас, вероятно, храниться только выплата, то есть сумма выданная сотруднику. Как из этой суммы восстановить размер дохода и размер налога, чтобы затем показать их в 6НДФЛ? Налоговая довольно легко сопоставит данные 6НДФЛ с фактическим поступлением налогов. Ошибка всплывет сразу же.

Если касаться попытки реализации, то да, одним HRPAYRU_PAYFACTX эту задачу не решить. Чуть выше я уже озвучивал вариант, который бы я попытался использовать - сгенерировать результаты расчетов межрасчетов "на лету" на этапе считывания. На сколько я могу судить на данный момент, таким способом модификаций в одном месте можно решить задачу целиком. Если делать что-то другое, то скорее всего потребуется модификации в большой куче разным мест.
Это только один из способов, вариант объектно-ориентированного подхода (ООП). Сап дает и другие способы - можно делать модификации, можно делать расширения (ENHANCEMENT).

ЗЫ. Кстати, класс CL_HRPAYRU_REPORT_CONTROL_CS особо перерабатывать смысла нет. Он лишь задает общий порядок обработки, там нет ничего, что требовало бы переработки для этой задачи. Разве что, если оставаться в рамках ООП, то можно заменить класс обработчика CL_HRPAYRU_PLTAXRUN_CS_PRR на свой. Вот в CL_HRPAYRU_PLTAXRUN_CS_PRR уже есть детальная обработка.

Коллеги,
поделитесь, что у кого в ракурсе V_T549S?
В частности интересует "Дата платежа".
У нас к примеру это 10-число каждого месяца в течении года.

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

А что мешает сразу настроить V_T549S с учетом проверки на "рабочий" день?

По большому счету ничего не мешает.
"Исторически" как то так сложилось)

Еще есть вопрос про 6 НДФЛ.
У нас возможны ситуации, когда у сотрудника за месяц возможен налог по ставке 13% и 35%.
ALV выводит такие записи корректно, отдельными строками.
Когда же выгружаю в XML, то внутри самого файла нет ни какого признака, к какой процентной ставке относится тот или иной доход.
Коллеги, на сколько это корректно, на ваш взгляд?

На мой взгляд, для ставки 13% должен быть своя часть раздела 1(010-040) и раздел 2 соответственно. Для 35% свои.
Иначе теряется смысл заполнения поля 010.

А чем XML проверить можно?

Проверял в "Налогоплательщике". Но дело в том, что там ни каких ошибок не выдает.
Заполнил вручную 6НДФЛ по двум ставкам налога, чтобы доходы были разнесены по ставкам.
Выгрузил xml на комп, и повторно его загрузил в налогоплательщик.
В итоге все суммы записываются "подряд" в разделе 2.

Тут подумал, получается и не в САПе вовсе дело...
Но все равно не могу понять, для чего указывать на разных листах ставки налога, и при этом не разделять между собой эти самые доходы в разделе 2.

По смыслу, разделяться должны.
Есть письмо налоговой N БС-4-11/591@ от 20.01.2016, в котором вводятся контрольные соотношения по форме 6НДФЛ. В частности там есть такое проверочное соотношения

Если это условие не выполняется, то считается что занижена сумма исчисленного налога. В этом случае налоговому органу следует

Если доходы по разным ставкам смешивать, то выполнить это соотношения нельзя.

Письмо уже утратило силу, но в новом письме от 10 марта 2016 г. N БС-4-11/3852@ есть условие (строка 020 - строка 030) / 100 * строка 010 = строка 040,
Проверка выполнится корректно, так как при повторной загрузке со строками 020-040 ничего не происходит.
Видимо ни как не проверяют строки 130, 140 для каждой ставки, относительно 020, 070.

С другой стороны, нет проверки, и нет претензий, а дальше пусть сами разбираются

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

Подскажите: как вы добились того, чтобы внециклические расчеты выводились отдельными строками в раздел 2? У меня настройки "по стандарту", всё выводится помесячно, отпуска, бонусы и т.д. - игнорируются.

И еще вопрос: вы переопределяете даты. А откуда вы их берете? Свой инфотип/таблица/другая система (FI например)? У нас даты, которые идут во второй раздел, существуют только на стороне FI.

Буду благодарен за помощь и подсказки в каком направлении копать.

gomer4ik
Но при этом, в приказе N ММВ-7-11/450@ написано буквально следующее:

И далее по тексту в описании xml формата есть табличка 4.10, в которой есть поле Ставка налога Ставка А N(2) О .
Так что ставка должна быть, я считаю.

to ROMP
Точно помню, у себя переопределил 6ND00001.
По датам есть BAdI стандартное HRPAYRU_B_PAYFACTX, на классе CL_HRPAYRU_IM_PAYFACTX. У класса есть метод DETERMINE_PAYMENT_FACT_MODE. Поставьте там точку остановки, и посмотрите что происходит.
Если даты есть в FI, то можно дергать их оттуда.

msv
Но ведь в 3.2 ни слова про Раздел 2, и разделение по ставкам для Раздел 2.