Форма 6-НДФЛ

PA-PA

msv написал:

Мне особенно вот это в ноте нравится:
However, report Income Tax Declaration (from 6-NDFL) does not support processing of 'L' option and displays results that are different from report Income Tax (form 2-NDFL)...
Коллеги, у меня у одного возникает вопрос - зачем было изобретать велосипед заново? В чем был смысл отказа от той же логики что и в 2-НДФЛ? Какой то хитрый архитектурный ход.

С арх точки зрения это легко объясняется. Каждый класс должен заниматься своим делом.
TAXRUN – возвращать деньгу, TAXAG – классифицировать деньгу но налоговому агенту.
L-обработка в классе TAXRUN – это «трик», угадал-не угадал. А в классе TAXAG – проблема решается изолированно.

PA-PA

PaY.roll написал(а):

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

Еще одна нота

2314110 - 6-NDFL: non-relevant organization data at T7RU9A splitting

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

Выше указанные ошибки устранены после установки пилотной ноты 2315741 - 6-NDFL: cumulative updates 05.2016

Объясните, пожалуйста, где и откуда информации по этим нотам?
Не вижу её ни через старый портал, ни через новый. Напрямую по ссылке нота не открывается.

Может быть не видна, потому что нота пилотная?

RoustR

PA-PA написал(а):

С арх точки зрения это легко объясняется. Каждый класс должен заниматься своим делом.
TAXRUN – возвращать деньгу, TAXAG – классифицировать деньгу но налоговому агенту.
L-обработка в классе TAXRUN – это «трик», угадал-не угадал. А в классе TAXAG – проблема решается изолированно.

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

Кроме того, L-обработка это не только отнесение денег к налоговому агенту. TAXRUN производит фильтрацию денег по критериям запуска программы. Он должен знать о существовании L-опции чтобы производить фильтрацию правильно. L-обработка в классе TAXRUN – это не «трик».

Брат Мигель

Хотел бы спросить у разработчиков сего отчета про атрибуты класса CL_HRPAYRU_PAYFACTX.
Это что? :shock:

CV_WCODE_PAIDINCOME Constant Protected Type PRUPY_S_WAGES-WCODE '6ND00010'
CV_WCODE_PAIDTAX Constant Protected Type PRUPY_S_WAGES-WCODE '6ND00011'

И вот этот фокус не понял.
CONSTANTS: gc_ndfl_amounts_for_period TYPE p99sd_wafor-fidaq-soufi VALUE 'FOR_PERIOD_PAYFACTX'.

Хотел пошутить, но получилось только ..... .
Если без ругани то: "зачем так?".

diman1989

Подскажите пожалуйста.6НДФЛ. Сотрудник получил в одной орг. (ОКТМО1) единице доход. Потом его перевели в другую орг. единицу (ОКТМО2). Во второй орг единице его пересчитали. Необходимо, чтобы пересчитанный доход лёг в ОКТМО2, а сейчас ложится в ОКТМО1.

2 НДФЛ впилили ENH в класс CL_HRPAYRU_PLTAXRUN_CE методы COLLECT_OUTWAGE_CE и GET_GPVAL (суть в том, что переопределяем GPVAL по последнему перерасчету и кладет сумму туда, ОКТМО2). в 6 НДФЛ попробовали подобные ENH впилить в CL_HRPAYRU_PLTAXRUN_CS, но не прокатывает.
Полезли в кишки, где он грид собирает в ФМ HR_RU_DAQ_NDFL_AMOUNTS, вызывает CL_HRPAYRU_PLTAXRUN_CS->GET_WAGEOBJECTS, где проверяет чтобы у нашего платежа должна быть категория TAXAGENT. Если поставить на СЭ ОКТМО1, то платеж учитывается. Если ОКТМО2 то платеж не учитывается.
У него три категории для ОКТМО2 :
->{O:294*\CLASS=CL_HRPAYRU_CONTRACT_CS}
->{O:381*\CLASS=CL_HRPAYRU_PAYFACTX}
->{O:412*\CLASS=CL_HRPAYRU_INTAXRTE_4WORK}

И четыре категории для ОКТМО1 :
->{O:294*\CLASS=CL_HRPAYRU_CONTRACT_CS}
->{O:379*\CLASS=CL_HRPAYRU_TAXAGENT}
->{O:381*\CLASS=CL_HRPAYRU_PAYFACTX}
->{O:412*\CLASS=CL_HRPAYRU_INTAXRTE_4WORK}

RoustR

Нет, нет, на этапе ФМ HR_RU_DAQ_NDFL_AMOUNT уже поздно что-либо делать. Нужно на этапе сбора данных работать, аналогично 2НДФЛ.

В 6НДФЛ на этапе сбора данных работает класс CL_HRPAYRU_PLTAXRUN_CS_PRR, метод collect_outwage_ce. В самом начале организуется цикло по расчетам (LOOP AT it_results ASSIGNING <lo_result>.). <lo_result> - это будет текущий расчет (для-период).
Далее едет код

Code:

    get_associated_pyres( exporting it_results = it_results
                                    is_curr_evp = <lo_result>->period
                          importing et_pyres_follower = lt_pyres_follower
                                    eo_pyres_actual   = lo_pyres_actual ).

lo_pyres_actual - это будет ссылка на расчет, в котором периоде это произошло (в-период).

Далее идет обработка сумм и в итоге, вызов me->raise_payroll_evt и генерация события RAISE EVENT if_hrpayru_report_control_cs~check_wage. Обратите внимание, как много параметров при этом передается

Code:

              me->raise_payroll_evt(
                                EXPORTING
                                  i_pernr        = <lo_result>->pernr
                            is_wpbp_check  = <ls_wpbp_check>-wpbp_check
                                  is_evp         = <lo_result>->period
                                  is_rt            = <ls_rt>
                                  irefs_inter      = lrefs_inter
                                  irefs_nat        = lrefs_nat
                                  irefs_versc      = lrefs_versc
                                  irefs_inter_pers = lrefs_inter_person
                                  irefs_natio_pers = lrefs_natio_person
                                  ireft_rgdir      = lreft_rgdir
                                  it_pyres_follower = lt_pyres_follower
                                  io_pyres_actual   = lo_pyres_actual
                                CHANGING
                                  cs_outwage     = ls_outwage ).

Все эти irefs* формируются относительно для-периода, но там есть и lo_pyres_actual - нужный нам в-период.

Событие check_wage получают все подписанные объекты. За определение ОКТМО отвечает CL_HRPAYRU_TAXAGENT, у него есть метод CHECK_WAGE, который получит все эти параметры. Вот тут и нужно действовать - нужно определяться ОКТМО не по irefs*, а по расчету lo_pyres_actual. Модификация заключается в том, чтобы, например, прочитать данные wpbp из lo_pyres_actual, а дальше определять ОКТМО по нему.

diman1989

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

Нет, нет, на этапе ФМ HR_RU_DAQ_NDFL_AMOUNT уже поздно что-либо делать. Нужно на этапе сбора данных работать, аналогично 2НДФЛ.

Спасибо, что откликнулись. Насколько я понял, сделал так:

Code:

  METHOD check_wage.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1) Класс CL_HRPAYRU_TAXAGENT, Метод CHECK_WAGE, Начало                                                                                               A
*$*$-Start: (1)---------------------------------------------------------------------------------$*$*
ENHANCEMENT 1  ZEI_NDFL6_2.    "active version
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(2) Класс CL_HRPAYRU_TAXAGENT, Метод CHECK_WAGE, Начало, Расширение ZEI_NDFL6_2, Начало                                                               A
*
  DATA ls_wpbp like is_wpbp.

  loop at io_pyres_actual->inter-wpbp into ls_wpbp.
    "import ниже в методе get_effective_wpbp
    export ls_wpbp from ls_wpbp to memory id 'WPBP'.
    "exit.
   " is_wpbp = ls_wpbp.
  endloop.

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(3) Класс CL_HRPAYRU_TAXAGENT, Метод CHECK_WAGE, Начало, Расширение ZEI_NDFL6_2, Выход                                                                A
ENDENHANCEMENT.
*$*$-End:   (1)---------------------------------------------------------------------------------$*$*

*   Personnel assignment check
    IF i_pernr <> a_pernr_wageobj.
      RETURN.
    ENDIF.

    DATA: ls_effective_wpbp TYPE pc205.
    ls_effective_wpbp = get_effective_wpbp(
      is_current_wpbp  = is_wpbp
      it_complete_wpbp = is_inter-wpbp[]
      is_evp           = is_evp ).

и имортирую в методе get_effective_wpbp

Code:

METHOD get_effective_wpbp.
    r_result = is_current_wpbp.

    IF is_evp-occat = if_hrpayru_oc_categories=>cd_occat-advance_on_date OR
       is_evp-occat = if_hrpayru_oc_categories=>cd_occat-advance_procent.
      DATA: lt_sort_wpbp TYPE hrpay99_wpbp.
      lt_sort_wpbp[] = it_complete_wpbp[]. SORT: lt_sort_wpbp BY endda DESCENDING.
      READ TABLE lt_sort_wpbp[] INTO r_result INDEX 1.
      IF sy-subrc <> 0.
        r_result = is_current_wpbp.
      ENDIF.
    ENDIF.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1) Класс CL_HRPAYRU_TAXAGENT, Метод GET_EFFECTIVE_WPBP, Выход                                                                                        A
*$*$-Start: (1)---------------------------------------------------------------------------------$*$*
ENHANCEMENT 2  ZEI_NDFL6_2.    "active version
*
  "export в CL_HRPAYRU_TAXAGENT->CHECK_WAGE
  if sy-cprog = 'RPCPAYRU_6NDFL'.
    DATA r_result_temp like r_result.

    CLEAR  r_result_temp.
    import ls_wpbp to r_result_temp from memory id 'WPBP'.
    IF r_result_temp is NOT INITIAL .
      r_result = r_result_temp.
    ENDIF.
    free memory id 'WPBP'.
  endif.
ENDENHANCEMENT.
*$*$-End:   (1)---------------------------------------------------------------------------------$*$*
  ENDMETHOD.

Но теперь он отнес этот платеж в головное юр лицо... Сейчас буду дальше копать, может я что то недопонял?

PA-PA

Брат Мигель написал:

Хотел бы спросить у разработчиков сего отчета про атрибуты класса CL_HRPAYRU_PAYFACTX.
Это что? :shock:

CV_WCODE_PAIDINCOME Constant Protected Type PRUPY_S_WAGES-WCODE '6ND00010'
CV_WCODE_PAIDTAX Constant Protected Type PRUPY_S_WAGES-WCODE '6ND00011'

И вот этот фокус не понял.
CONSTANTS: gc_ndfl_amounts_for_period TYPE p99sd_wafor-fidaq-soufi VALUE 'FOR_PERIOD_PAYFACTX'.

Хотел пошутить, но получилось только ..... .
Если без ругани то: "зачем так?".

Я не являюсь разработчико данного отчета, но на первый вопрос могу ответить.
Это два кода доходов (фактический доход и подоходный налог с него), которые обрабатываются в части 2 формы 6-НДФЛ. Это единственные два кода, по которым необходимо возвращать деньги с учетом с оффсайклов.
Класс TAXRUN собирает деньги по регулярным и оффсаклам по всех доходам.
Класс PAYFACT оставляет деньги из оффсайклов только по двум кодам, указанным в атрибутах.
По второму вопросу не скажу, этого в классе нет, а запускать код сканер не так быстро.

PA-PA

Перед тем как менять класс и после того как он изменен (и много раз в процессе изменения, после каждой активации) советую запускать unit test runner (Ctrl+Shift+F10).
Конкретно для класса CL_HRPAYRU_TAXAGENT SAP написал более 1300 тестового кода (4 тестовых класса и 20 тестовых методов), который проверяет менее чем 900 строк продуктивного кода. Поэтому после энхансментов можно легко сломать стандартный код.

Брат Мигель

PA-PA написал(а):

Брат Мигель написал:

Хотел бы спросить у разработчиков .....

Я не являюсь разработчико данного отчета, но на первый вопрос могу ответить.
Это два кода доходов (фактический доход и подоходный налог с него), которые обрабатываются в части 2 формы 6-НДФЛ. Это единственные два кода, по которым необходимо возвращать деньги с учетом с оффсайклов.
Класс TAXRUN собирает деньги по регулярным и оффсаклам по всех доходам.
Класс PAYFACT оставляет деньги из оффсайклов только по двум кодам, указанным в атрибутах.
По второму вопросу не скажу, этого в классе нет, а запускать код сканер не так быстро.

Да я ругаюсь, что начали хардкодить.

.

Брат Мигель

Коллеги, привет.
Кто в курсе?
Где в программе из регулярного расчета вычитаются межрасчеты?

RoustR

Метод CL_HRPAYRU_PAYFACTX-POST_PROCESS_WAGES.
Работает это уже на этапе работы DAQ-формы, стартует из ФМ HR_RU_DAQ_NDFL_AMOUNTS, процедура post_process_wages.

Брат Мигель

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

Метод CL_HRPAYRU_PAYFACTX-POST_PROCESS_WAGES.
Работает это уже на этапе работы DAQ-формы, стартует из ФМ HR_RU_DAQ_NDFL_AMOUNTS, процедура post_process_wages.

Коллега, спасибо!
Наткнулся на проблему.
идет пересчет предыдущего месяца межрасчетом увольнения.
в методе GET_REGULAR_RUN_TO_REDUCE класса CL_HRPAYRU_PAYFACTX в цикле не может найти нужную строку.

Code:

    LOOP AT it_all_wages ASSIGNING <ls_wages_full_info> WHERE fpper EQ is_reducing_wage-per
                                                          AND objid NE is_reducing_wage-objid
                                                          AND wcode EQ is_reducing_wage-wcode.

нужного fpper не оказалось.
и все коллапс.

Брат Мигель

Похоже, что АБАПерам было скучно просто сделать на классах.
Не хватало чего-то ..., ну и вот

: irefs_wpbp->*-begda

RoustR

Вполне нормальная строка. Раз начинаем работать с ссылками (кстати, использование классов зачастую приводит к использованию ссылок), то появляются такие конструкции. Есть операция получение ссылки, ->* обратная операция, из ссылки получить структуру.
Да, конструкцию типа irefs_wpbp->*-begda первой раз самому написать сложно, но с чтением проблем вроде не возникает.

Форма 6-НДФЛ

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