cancel
Showing results for 
Search instead for 
Did you mean: 

Infotype framework datos fiscales (CL_HRPA_INFOTYPE_0062/CL_HRPADES_IRPF_INFOTYPE)

antoine_foucault
Active Contributor
0 Kudos

Buenas tardes Gurus,

Acudo una vez mas a vuestra sabiduría sabia.

Me pregunto si alguien de vosotros usan esta clase para manejar datos del infotipo de datos fiscales.

Me iba bien hasta hoy porque teníamos la versión del 19.08.2010, ahora hemos nivelado parches hasta el 72 (604) y se ha actualizado la clase con con nuevas implementaciones de metodos

SAP_HRCES6040072SAPK-60472INSAPHRCES

Sub component SAP_HRCES of SAP_HR

EA-HR6040072SAPK-60472INEAHR

SAP R/3 Enterprise Extension HR

EA-HRCES6040072SAPK-60472INEAHRCES

Sub component EA-HRCES of EA-HR

Ahora tengo un problema en el método CHECK_TAX_MOD_VALID_IN_PROVN; pero revisando la lógica no me cuadra el código ABAP:

Según veo en la línea 16 se lee la parametrización en la tabla T5E20 (en mi caso la estructura acaba con datos Provincia 07, Inicio/Fin, Modificador 99); correcto; despues viene el IF problematico que pregunta por si la estructura tiene valor; y si tiene valor se genera un mensaje de error Línea 42/43...  la generacion del mensaje en si genera el dump porque las variables sy (msgid/msgty/msgvx) estan sin informar - no se puede geenrar un mensaje sin tipo.

Anál.errores

    Only message types A, E, I, W, S, and X are allowed.

Parece que hay una mezcla entre los IF porque si entras por el IF (T5E20 sin datos) y el campo Modificador de impuestos (IRPF) del infotipo 0062 tiene valor, luego fuerza de nuevo la asignación del modificador de impuestos - que acabaria en blanco porque T5E20 no tiene valor??


  METHOD check_tax_mod_valid_in_provn .

* Verificar provincia contra Modificador de impuestos (IRPF)

    DATA lt_field_list TYPE hr_fieldlist_tab.

    DATA ls_t5e20 TYPE t5e20.

    DATA ls_p0062 TYPE p0062.

    ls_p0062 = mo_hrpades_irpf_infotype->get_p0062( ).

* Provincias

    ls_t5e20 = cl_hr_t5e20=>read( provn = ls_p0062-provn

                                 date  = ls_p0062-begda ).

    IF ls_t5e20 IS INITIAL.                                        MI PROBLEMA EMPIZA AQUI

      IF ls_p0062-codau <> space AND ls_p0062-codau <> ls_t5e20-regfi.

        REFRESH lt_field_list.

        APPEND 'CODAU' TO lt_field_list.

* El código geográfico correspondiente al empleado es &

        MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

         WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 INTO me->g_msg_txt.

        CALL METHOD me->add_message

          EXPORTING

            message_handler = io_message_handler

            p_field_list    = lt_field_list[]

          CHANGING

            p_is_ok         = ev_is_ok.

      ELSE.

        ls_p0062-codau = ls_t5e20-regfi.                    SIGUE POR AQUI... forzar codau con un regi initial?

        mo_hrpades_irpf_infotype->set_p0062( is_p0062 = ls_p0062 ).

      ENDIF.

    ELSE.

      REFRESH lt_field_list.

      APPEND 'CODAU' TO lt_field_list.

* No existe entrada en & para & & & &

      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno                      y mi dump se genera aqui porque mi ls_t5e20 tiene datos...

         WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 INTO me->g_msg_txt.

      me->add_message(

        EXPORTING

          message_handler = io_message_handler

          p_field_list    = lt_field_list[]

        CHANGING

          p_is_ok         = ev_is_ok ).

    ENDIF.

  ENDMETHOD.                    "check_tax_mod_valid_in_provn

Mi pila ABAP es la siguiente (orden de ejecución de los procesos/metodos); todo muy estándar (salvo el programa claro) y no tengo redefiniciones de metodos raras en el programa.


EVENTSTART-OF-SELECTIONZHR_PY_ES_EI20
METHODIF_HRPA_MASTERDATA_BL~INSERTCL_HRPA_MASTERDATA_BL=========CP
METHODIF_HRPA_INFTY_BL~INSERTCL_HRPA_INFTY_NNNN============CP
METHODGENERIC_INSERT_COMPUTATIONSCL_HRPA_INFTY_NNNN============CP
METHODSPECIFIC_INSERT_COMPUTATIONSCL_HRPA_INFOTYPE_0062=========CP
METHODGENERIC_COMPUTATIONSCL_HRPA_INFOTYPE_0062=========CP
METHODCHECK_TAX_MOD_VALID_IN_PROVNCL_HRPA_INFOTYPE_0062=========CP



Algunos de vosotros gurus, habéis encontrado el mismo problema? Que os parece mi planteamiento? Merece que me ponga en contacto con la santa sede en Torre Laguna (aka service.sap.com/message) ?

Muchas gracias de ante mano por vuestra ayuda.

Accepted Solutions (1)

Accepted Solutions (1)

antoine_foucault
Active Contributor
0 Kudos

Buenas tardes Gurus,

Al final parece que los cambios están en una nota liberada Note 1927845 PA: Infotype framework corrections for Spain - III. El inconveniente es que al no tener un sistema a nivel EHP7 no podemos aplicar las corrects instructions contenidas que corrigen entre otros este fallo [lo raro es que parece que hay un desfase de nivel entre el nivel de parche en la nota y la realidad (porque la maquina súper ese nivel) ]. En fin, tenemos que esperar a la próxima subida de parches para que se apliquen las correcciones.

Al final he aplicado una solución temporal que consiste en hacer una copia de la clase y modificar el método que daba problemas. Esta solución requiere que se modifique un poco el customizing estándar bajo la sección infotipos "desacoplado" en la SPRO (gestión de personal/gestión de personal/adaptación de las superficies/infotype/...) y listo.

Claro, cuando las correcciones estarán en el sistema retrocederé estos cambios para volver a usar la clase estándar.

Gracias a SAP y a los compañeros de la OSS por la ayuda.

Cierre el post.

Saludos,

Antoine

Answers (3)

Answers (3)

antoine_foucault
Active Contributor
0 Kudos

Gracias Guillermo. Ahora abrir una nota OSS con baja prioridad.

Un saludo.

GuillermoB
Product and Topic Expert
Product and Topic Expert
0 Kudos

Buenos días Antoine,

Me han informado que la actualización para ese método se entregará para EhP4 en el próximo Support Package que está siendo cerrado actualmente. Disculpa las molestias.

Saludos,

Guillermo

antoine_foucault
Active Contributor
0 Kudos

Hola Guillermo Ballesteros


Gracias por tu mensaje de seguimiento.


Tengo un pregunta adicional sobre el tratamiento de datos en la clase CL_HRPA_INFOTYPE_0062 porque una usuario me ha informado que uno de los reports (de cliente) que usa le esta indicando datos que no son correctos - este report usa el campo PORDB de la estructura P0062.


¿Es possible que haya también un fallo sobre la actualización del campo P0062-PORDB desde el campo Q0062-PORCL vía la lógica decoplada?


He revisado la clase estándar de arriba a bajo y nada sobre este campo que en el legacy se materializa en la lógica ubicada en la subrutina SET_PORDB. Tan poco he visto nada respecto a notas de correcciones


¿Como este campo es un campo de explotación exclusiva de cliente quizás desde desarrollo no se ha tenido en cuenta?


Como aun no hemos subido de parches para recuperar las correcciones de la nota 1927845 PA: Infotype framework corrections for Spain - III; y que tampoco se podrá liberar correcciones vía una nota para nuestro nivel de EHP, he añadido lógica adicional en la copia de la clase CL_HRPA_INFOTYPE_0062 para poder actualizar este dato con el valor almacenado en mo_hrpades_irpf_infotype->ms_q0062-porcl replicando así el comportamiento del legacy.


¿me recomiendas de abrir una petición OSS?


Muchas gracias de ante mano.

Antoine









GuillermoB
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hola

Creo que tienes razón, y parece que esta lógica del antiguo framework no habría sido traspasada al New ITF.

En la clase se ve por ejemplo el código que actualiza el PORNM:


  IF expatriate = abap_true.
    ms_p0062-pornm = ms_p0062-pora4.
    MESSAGE w238(5e) RAISING indic_irpf_manually.
  ELSE.
    IF ms_p0062-pora4 < ms_q0062-porcl AND ms_p0062-motiv IS INITIAL.
      ms_p0062-pornm = ms_q0062-porcl.
    ELSE.
      ms_p0062-pornm = ms_p0062-pora4.
    ENDIF.
  ENDIF.

Pero después ya no parece actualizarse el PORDB. No me parece que vaya a haber ningún cambio a la operativa habitual para esto, por lo que posiblemente sea necesario añadirlo.


Ahora mismo los ajustes en este framework tienen baja prioridad, viendo que has podido resolverlo temporalmente y que es un uso exclusivo de cliente (por el momento), creo que lo mejor es que reportéis un mensaje low para que este tema quede pendiente de tratarse cuando sea posible y no caiga en el olvido. Si te parece podrías remitir esto mismo que has indicado en el hilo, ya que está bastante bien descrito el problema.

Gracias y saludos,

Guillermo

antoine_foucault
Active Contributor
0 Kudos

Hola de nuevo,

Al final, mi cliente me indico que necesitaba una solución rápida así que no he podido esperar y he abierto una consulta a los compis de la OSS con el mismo detalle de mi anterior post.

De momento me dijó (gracias) que parece que sea un problema de sincronización y que lo estaba(n) investigando. He solicitado que internamente mi cliente revise sincronizaciones post-parches de la maquina. Actualizare este mensaje con la solución final.

Buen finde a todos.

Saludos,

Antoine