Форма 6-НДФЛ

RoustR

ROMP написал:

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

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

По первой части вопроса. Не факт что внециклические расчеты игнорируются. Там вся фишка в том, что данные группируются по датам. Если даты по внециклическим расчетам будут совпадать с датами регулярного расчета, то они схлопнутся. Поэтому первая часть вопроса плавно переходит во вторую часть.

По датам. Мы у себя данные по проводках сохраняем в Z-таблицах. Дату фактической выдачи сохраняем в таблице BT. Все эти сведения нужны для формирования отчета 1НДФЛ. САП на него забил, пришлось делать самим. Зато сейчас все данные для 6НДФЛ есть. Прикручивается через Badi HRPAYRU_B_PAYFACTX.

ROMP

Всем доброго дня!
gomer4ik, RoustR, благодарю за информацию!
Скажите, а в Badi HRPAYRU_B_PAYFACTX как вы класс реализовали?
Можете привести основные методы с вашей реализацией, чтобы не изобретать велосипед?

Спасибо.

gomer4ik

Когда создавал внедрение через SE18, скопировал полностью класс в свой Z*. Дорабатывал метод указанный ранее. Производственный календарь RU заменил на свой (может вам это и не нужно). Пригодился метод GET_NEXT_BUSINESS_DAY для межрасчетов.

mr_try

Коллеги, форма 6-НДФЛ формирует ошибку типа

Как с ней бороться? Классам налогов класс ABAP прописан. Суммы в отчёте формируются, но ставка в поле RATEV не выводится.
В форме create_wage_output метод io_taxrun->get_wageobjects( не находит ВО, по которым в дальнейшем находится ставка. К сожалению, причину далее найти не могу. Кто-то сталкивался с такой проблемой?

msv

Коды 6ND* настроены по стандарту? Там ВО /3* внутри? В кластере в RT в ВО /3* значение ставки есть?

mr_try

msv написал:

Коды 6ND* настроены по стандарту? Там ВО /3* внутри? В кластере в RT в ВО /3* значение ставки есть?

Вот тут то вот и вопрос. Ставка в DAQ не связана ни с одним 6ND*, только структура данных - P33_NDFL_TAXRATE. Если я правильно понимаю, то данные в это поле должны подтягиваться от налогового класса, обрабатываемого ВО (Например, Если ВО /320, то НК 13 и ставка 13%)
Кто сталкивался с такой проблемой?

RoustR

mr_try
Такая ошибка появляется, когда в настройке отчета указывается ВО налога, который появился "не по правилам". Например, у меня есть ВО НДФЛ, который вычисляется вне САП, в САП зарплате он проходит как есть. Если его указать в 6НДФЛ, то для него невозможно определить налоговые характеристики, в том числе ставку налога. 6-НДФЛ на такой ВО ругается именно так.

За эту работу отвечает класс CL_HRPAYRU_INTAXRTE_CONTROL, которые в себе содержит коллекцию объектов классов, наследованных от CL_HRPAYRU_INTAXRTE. Точный список этой коллекции зависит от ТН (от налоговой схемы ТН), список возможных классов приведен в таблице T77PAYRU_TAX_CLS.
Когда происходит обработка ВО из результата расчета происходит событие raise_payroll_evt, которое в итоге вызовет метод CL_HRPAYRU_INTAXRTE_CONTROL-ON_CHECK_WAGE. Здесь перебираются все экземпляры коллекции вызовом check_wage. Какой-то класс из коллекции должен оценить (классифицировать) полученный ВО. Если ни один экземпляры коллекции ВО не оценит, будет сгенерирована описанная ошибка.
Если речь идет об обычном ТН (налоговый класс 13), то классификацию следует ожидать от класса CL_HRPAYRU_INTAXRTE_4WORK.

Я допиливал CL_HRPAYRU_INTAXRTE_4WORK для своих внесистемных ВО.

RoustR

В create_wage_output в коде

Code:

  io_taxrun->get_wageobjects(
    EXPORTING
      i_pernr   = im_daq-pernr
      i_objid   = is_wages-objid
      i_cat     = cl_hrpayru_intaxrte_control=>c_alias
    CHANGING
      c_objects = lt_wageobjs[]
  ).
  DATA: lo_intaxrte TYPE REF TO cl_hrpayru_intaxrte,
        ls_rate     TYPE cl_hrpayru_intaxrte=>ty_s_rate.
  DATA: ls_error LIKE LINE OF ch_tab_error.
  LOOP AT lt_wageobjs[] ASSIGNING <ls_wageobj>.
    TRY.
        lo_intaxrte ?= <ls_wageobj>-wageobj.
        ls_rate = lo_intaxrte->get_rate_w_anyk( <ls_wageobj>-anyk ).
      CATCH cx_sy_move_cast_error.
        CONTINUE.
    ENDTRY.
  ENDLOOP.
  if ls_rate-proc is INITIAL.
    message w006(hrpadru_ndfl) with is_wages-wcode is_wages-PER into sy-msgv4.  "have payment without classification by % wage code &2 period &3
    CALL FUNCTION 'HR_99S_APPEND_ERROR_LIST'
      EXPORTING
        pernr        = im_daq-pernr
        arbgb        = sy-msgid
        msgty        = sy-msgty
        msgno        = sy-msgno
        msgv1        = sy-msgv1
        msgv2        = sy-msgv2
      CHANGING
        ch_tab_error = ch_tab_error[].
  endif.

лишь итог работы.
Получили обработчик INTAXRTE (класс CL_HRPAYRU_INTAXRTE_CONTROL), в нем перебрали коллекцию, о которых я говорил, с поиском что кто-то его оценил. Если оценки нет, то ошибка.

hilena

Подскажите, у всех корректно отображаются текстовые элементы программы RPCPAYRU_6NDFL?
У нас их нет на языке оригинала.
Ставили 6-НДФЛ нотами.

gomer4ik

hilena написала:

Подскажите, у всех корректно отображаются текстовые элементы программы RPCPAYRU_6NDFL?
У нас их нет на языке оригинала.
Ставили 6-НДФЛ нотами.

Было такое после нот, поставили пакет, стало "ок"

hilena

Спасибо!

AnubisNo

Вышла нота 2295281 - Form 6-NDFL is not
compatible with customizing of form 2-NDFL
которая решает проблему разбиения по признаку 33OKT

RoustR

Form 6-NDFL is not compatible with customizing of form 2-NDFL
Раз уж заголовок ноты так звучит, для информации. 2-НДФЛ и 6-НДФЛ несовместимы между собой еще в одном моменте. 2-НДФЛ умеет обрабатывать "Тип обработки" = 'L' (В-период в посл. орг. присвоение) из настройки T7RUN*, а 6-НДФЛ - нет. Это важно при смене атрибута ЮрЛицо и пересчете "задним числом".

Еще есть нота 2297545 - 6-NDFL: wrong income tax after leaving company, но я ее пока в общем доступе не вижу. Если кому-то это важно. Если сотрудник был уволен и принят повторно в одном месяце, то в отчете формируется лишняя минусовая строка по расчету увольнения. Затем на ту же сумму искажается (увеличивается) результат по регулярному расчету.

AnubisNo

RoustR написал(а):

Form 6-NDFL is not compatible with customizing of form 2-NDFL
Раз уж заголовок ноты так звучит, для информации. 2-НДФЛ и 6-НДФЛ несовместимы между собой еще в одном моменте. 2-НДФЛ умеет обрабатывать "Тип обработки" = 'L' (В-период в посл. орг. присвоение) из настройки T7RUN*, а 6-НДФЛ - нет. Это важно при смене атрибута ЮрЛицо и пересчете "задним числом".

Еще есть нота 2297545 - 6-NDFL: wrong income tax after leaving company, но я ее пока в общем доступе не вижу. Если кому-то это важно. Если сотрудник был уволен и принят повторно в одном месяце, то в отчете формируется лишняя минусовая строка по расчету увольнения. Затем на ту же сумму искажается (увеличивается) результат по регулярному расчету.

Да,в 6-НДФЛ есть проблема по межрасчетам. Писали в САП, ждем информацию

gomer4ik

AnubisNo написал(а):

Вышла нота 2295281 - Form 6-NDFL is not
compatible with customizing of form 2-NDFL
которая решает проблему разбиения по признаку 33OKT

Не знаю, как у остальных, но у меня эта нота исправила все КПП на одно. Написал об этом новый мессадж. ждёмс.

P.S. На мой взгляд проблема в методе GET_AGENT_FROM_33OKT класса CL_HRPAYRU_TAXAGENT после считывания 33OKT и в ведущих пробелах.

Форма 6-НДФЛ

Кто сейчас на конференции